From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9BCA9C433EF for ; Wed, 16 Mar 2022 01:43:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 084288D0003; Tue, 15 Mar 2022 21:43:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00DB28D0001; Tue, 15 Mar 2022 21:43:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA17D8D0003; Tue, 15 Mar 2022 21:43:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id C5A688D0001 for ; Tue, 15 Mar 2022 21:43:46 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 93BE523083 for ; Wed, 16 Mar 2022 01:43:46 +0000 (UTC) X-FDA: 79248552852.09.E2F7FD7 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf01.hostedemail.com (Postfix) with ESMTP id 18BC840007 for ; Wed, 16 Mar 2022 01:43:45 +0000 (UTC) Received: by mail-pj1-f54.google.com with SMTP id mz9-20020a17090b378900b001c657559290so1064531pjb.2 for ; Tue, 15 Mar 2022 18:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PgvEKtSkgtyBAX5y2qY434FN26syvKAAoFPbq7kCQ0I=; b=DIALkPivSyq9o3R0w9gglPAyk4v5XPNfDqzZMum4gZ6ww2O2cgjqv9srrtxbAxguFF 3qt97DcBfWPgAXp4HlqCVwX4FuEa0DG4GfHsv3VeACObzc0fc6BJ7CmLCl5Vd/937hf8 gwdzjofm7ybbBDIU/eXAA8cK5Hr5mpOlgUfogjEifS84GHzXsQGZwkkCcYoX7hCjgFk/ 3XEvhlPwUEAj2fEZ1A7ZWPm95SMh0H2o5XFQ/bbUjv+EP6J52KGnjom7TEqNPcqv18da fWv4C3nnd+k3YIODlQNYBRgtWLadPbhzxmAafV1rYnvxzEcddb8wHcKvPieges1K+dTN egww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=PgvEKtSkgtyBAX5y2qY434FN26syvKAAoFPbq7kCQ0I=; b=zS0UcyuCse3E7ZWmq6vk8AjGkpc28/1HiHjw2HNXys9SZ3mC+WwFgljXwo0+C07UkC o+yZaS6UV2jJonY7EBdwbiaP5ZnGjgNG8FLnGwJHWgqOGjT0Csd9pwUiT2txCLrofEyt 2WV027fCyOkFj8tYwvGiZdAsn6eorx1kOYmJvCBKssdWEC1lX0GphJ/tQ0ONAglLtkQk sSXVVYJ+fJqbQfZawLfpc4ObRTRN0nBH2iK7L+A/pfU+SdtT7dPPDTjeVTcYoPyH77y1 Vpa8QFZx/oDBnS4htM6cLx2OJ6ap6fRz65v9CLVzO9u4hFZHpDhcFdHZDsgqzkaQ/AbU Sb9A== X-Gm-Message-State: AOAM531+iYVgP1zFE+AaXpCJ67/bKknX0HPnOZGBdpmaZ2E3bvXN23ig hIgcKGEjxh3onrGYOW69g8Y= X-Google-Smtp-Source: ABdhPJx9tEkgSAWUDAlpuD2nqDFRS1YJVTNjt+TipDUs5PQk7tjBfQxgL2ZWLnCucLYyGwdDfYbFYQ== X-Received: by 2002:a17:90b:1812:b0:1bf:2395:8d53 with SMTP id lw18-20020a17090b181200b001bf23958d53mr7669109pjb.178.1647395024992; Tue, 15 Mar 2022 18:43:44 -0700 (PDT) Received: from google.com ([2620:15c:211:201:7484:dc22:fe49:91cb]) by smtp.gmail.com with ESMTPSA id g15-20020a056a0023cf00b004e17e11cb17sm423778pfc.111.2022.03.15.18.43.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Mar 2022 18:43:44 -0700 (PDT) Date: Tue, 15 Mar 2022 18:43:42 -0700 From: Minchan Kim To: Andrew Morton Cc: Charan Teja Kalla , surenb@google.com, vbabka@suse.cz, rientjes@google.com, sfr@canb.auug.org.au, edgararriaga@google.com, nadav.amit@gmail.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "# 5 . 10+" Subject: Re: [PATCH V2,2/2] mm: madvise: skip unmapped vma holes passed to process_madvise Message-ID: References: <4f091776142f2ebf7b94018146de72318474e686.1647008754.git.quic_charante@quicinc.com> <20220315164807.7a9cf1694ee2db8709a8597c@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220315164807.7a9cf1694ee2db8709a8597c@linux-foundation.org> X-Rspamd-Queue-Id: 18BC840007 X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=DIALkPiv; spf=pass (imf01.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Stat-Signature: 4ir43zxrrc8zap3ksc69kzue99x59a84 X-Rspamd-Server: rspam07 X-HE-Tag: 1647395025-34985 X-Bogosity: Ham, tests=bogofilter, spamicity=0.064133, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Mar 15, 2022 at 04:48:07PM -0700, Andrew Morton wrote: > On Tue, 15 Mar 2022 15:58:28 -0700 Minchan Kim wrote: > > > On Fri, Mar 11, 2022 at 08:59:06PM +0530, Charan Teja Kalla wrote: > > > The process_madvise() system call is expected to skip holes in vma > > > passed through 'struct iovec' vector list. But do_madvise, which > > > process_madvise() calls for each vma, returns ENOMEM in case of unmapped > > > holes, despite the VMA is processed. > > > Thus process_madvise() should treat ENOMEM as expected and consider the > > > VMA passed to as processed and continue processing other vma's in the > > > vector list. Returning -ENOMEM to user, despite the VMA is processed, > > > will be unable to figure out where to start the next madvise. > > > Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") > > > Cc: # 5.10+ > > > > Hmm, not sure whether it's stable material since it changes semantic of > > API. It would be better to change the semantic from 5.19 with man page > > update to specify the change. > > It's a very desirable change and it makes the code match the manpage > and it's cc:stable. I think we should just absorb any transitory > damage which this causes people. I doubt if there will be much - if > anyone was affected by this they would have already told us that it's > broken? process_madvise fails to return exact processed bytes at several cases if it encounters the error, such as, -EINVAL, -EINTR, -ENOMEM in the middle of processing vmas. And now we are trying to make exception for change for only hole? IMO, it's worth to note in man page. In addition, this change returns positive processes bytes even though it didn't process anything if it couldn't find any vma for the first iteration in madvise_walk_vmas.