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 D47DEC433EF for ; Thu, 17 Mar 2022 20:38:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 628008D0003; Thu, 17 Mar 2022 16:38:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D8A58D0001; Thu, 17 Mar 2022 16:38:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 478BB8D0003; Thu, 17 Mar 2022 16:38:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 3B2E98D0001 for ; Thu, 17 Mar 2022 16:38:57 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 317F361CB8 for ; Thu, 17 Mar 2022 20:38:57 +0000 (UTC) X-FDA: 79255042314.13.B518AAE Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf11.hostedemail.com (Postfix) with ESMTP id 92B5E40008 for ; Thu, 17 Mar 2022 20:38:56 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id q19so3543919pgm.6 for ; Thu, 17 Mar 2022 13:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XXPxc8xF2CJlGObdw/eC6baiwA/XpPKEd/Jy1SJ3ol8=; b=N4ZQLI8tGuL3HO7LWthMx63lUi8bBwKx4ejXuWr+Hzv7vwlGzlxOUjoKPnvOZtq6LC 31S3SSnT23US3dSeCl6I85ttzhDYlywg0PL1/sUs2kkuMe2MyUurbXzOrpAxeVqZ8lQc cnLaBIH8VKhUDUqZhHwYk1sh0Nrx1leIl+rjGh1uYlbRS0RVXSiQf88LVt1YKLteXs1t kIVkVDOgTu/Zn6yPssRCO23eCMwYwz0NSeZYOxu5OoUPZWgtmVKovnId9+FtBfkCe0Fs FjQxP05od8Q1gogWspX2xQ1vEgZ8DXY9+9/oMckgpGGK8kBLYpi0NDX9/yle3+1Ci1p9 XmNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XXPxc8xF2CJlGObdw/eC6baiwA/XpPKEd/Jy1SJ3ol8=; b=Bzv5iQrnK+WOi3nyp6Rm9XzIsOZct3XfBp1G77kfkAFJIa3446HGOclPHScluSqKn4 GbFOdP/ihnfTuSL7Guc3MIYXHnHNkINydyAW/ZxXoHaC3owp7wdQ+KptPNjwRXG0lQye B6v6PzRa8ZR6ewxKRE9NzkWudaVXA7DKbfKt488bGehz+cPXGwSZkrMPCZmxGnTBw49U jFzOpS6s6NQNcKMjYnOWmm4Kwy2dBeaM4pmFHEJYtl3EY2L6pPWKCAOKSD4Fje0qc15B 7iFfQeX5tFJB/jU7dEwQLdVdSacjIsuMDxTXWqb2zj5bBugKhgxiUMmk5zRe/bDinrGq DNYw== X-Gm-Message-State: AOAM531ColmICDnPxuPBiKdgBo5g8A5HxuskGSQXeLY3lg4wKQhZSJ+9 lgPwatoz2PkERhfXwzPNM/A= X-Google-Smtp-Source: ABdhPJyK0tJFmlDmVUuHFtogfArqh+PaJZQTl6s/30PTRARFfwstTpt/Vf5VhxkHqx+dRGRiPhVYhg== X-Received: by 2002:aa7:92cf:0:b0:4fa:3b47:7408 with SMTP id k15-20020aa792cf000000b004fa3b477408mr5232524pfa.72.1647549535202; Thu, 17 Mar 2022 13:38:55 -0700 (PDT) Received: from smtpclient.apple ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id a38-20020a056a001d2600b004f70d5e92basm7673990pfx.34.2022.03.17.13.38.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Mar 2022 13:38:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: [PATCH V2,2/2] mm: madvise: skip unmapped vma holes passed to process_madvise From: Nadav Amit In-Reply-To: Date: Thu, 17 Mar 2022 13:38:52 -0700 Cc: Minchan Kim , Andrew Morton , Charan Teja Kalla , Vlastimil Babka , David Rientjes , Stephen Rothwell , =?utf-8?Q?Edgar_Arriaga_Garc=C3=ADa?= , Michal Hocko , linux-mm , LKML , "# 5 . 10+" Content-Transfer-Encoding: quoted-printable Message-Id: References: <4f091776142f2ebf7b94018146de72318474e686.1647008754.git.quic_charante@quicinc.com> <20220315164807.7a9cf1694ee2db8709a8597c@linux-foundation.org> <5428f192-1537-fa03-8e9c-4a8322772546@quicinc.com> <20220316142906.e41e39d2315e35ef43f4aad6@linux-foundation.org> To: Suren Baghdasaryan X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 92B5E40008 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=N4ZQLI8t; spf=pass (imf11.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspam-User: X-Stat-Signature: j5kua98xazdna8pe6fdw4zbs8u46jpfm X-HE-Tag: 1647549536-331521 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Mar 17, 2022, at 9:53 AM, Suren Baghdasaryan = wrote: >=20 > On Thu, Mar 17, 2022 at 9:28 AM Minchan Kim = wrote: >>=20 >> On Wed, Mar 16, 2022 at 02:29:06PM -0700, Andrew Morton wrote: >>> On Wed, 16 Mar 2022 19:49:38 +0530 Charan Teja Kalla = wrote: >>>=20 >>>>> IMO, it's worth to note in man page. >>>>>=20 >>>>=20 >>>> Or the current patch for just ENOMEM is sufficient here and we just = have >>>> to update the man page? >>>=20 >>> I think the "On success, process_madvise() returns the number of = bytes >>> advised" behaviour sounds useful. But madvise() doesn't do that. >>>=20 >>> RETURN VALUE >>> On success, madvise() returns zero. On error, it returns -1 = and errno >>> is set to indicate the error. >>>=20 >>> So why is it desirable in the case of process_madvise()? >>=20 >> Since process_madvise deal with multiple ranges and could fail at one = of >> them in the middle or pocessing, people could decide where the call >> failed and then make a strategy whether they will abort at the point = or >> continue to hint next addresses. Here, problem of the strategy is API >> doesn't return any error vaule if it has processed any bytes so they >> would have limitation to decide a policy. That's the limitation for >> every vector IO syscalls, unfortunately. >>=20 >>>=20 >>>=20 >>>=20 >>> And why was process_madvise() designed this way? Or was it >>> always simply an error in the manpage? >=20 > Taking a closer look, indeed manpage seems to be wrong. > https://elixir.bootlin.com/linux/v5.17-rc8/source/mm/madvise.c#L1154 > indicates that in the presence of unmapped holes madvise will skip > them but will return ENOMEM and that's what process_madvise is > ultimately returning in this case. So, the manpage claim of "This > return value may be less than the total number of requested bytes, if > an error occurred after some iovec elements were already processed." > does not reflect the reality in our case because the return value will > be -ENOMEM. After the desired behavior is finalized I'll modify the > manpage accordingly. Since process_madvise() might be used in sort of non-cooperative mode, I think that the caller cannot guarantee that it knows exactly the memory layout of the process whose memory it madvise=E2=80=99s. I know = that MADV_DONTNEED for instance is not supported (at least today) by process_madvise(), but if it were, the caller may want which exact memory was madvise'd even if the target process ran some other memory layout changing syscalls (e.g., munmap()). IOW, skipping holes and just returning the total number of madvise=E2=80=99= d bytes might not be enough.