linux-kernel - Re: [RFC] mm/gup.c: Updated return value of {get|pin}_user_pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 7 May 2020 11:44:23 -0700
From:   John Hubbard <jhubbard@...dia.com>
To:     Souptick Joarder <jrdr.linux@...il.com>, Jan Kara <jack@...e.cz>
CC:     Tony Luck <tony.luck@...el.com>, <fenghua.yu@...el.com>,
        Rob Springer <rspringer@...gle.com>,
        Todd Poynor <toddpoynor@...gle.com>, <benchan@...omium.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jens Wiklander <jens.wiklander@...aro.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <santosh.shilimkar@...cle.com>,
        "David S. Miller" <davem@...emloft.net>, <kuba@...nel.org>,
        Ira Weiny <ira.weiny@...el.com>,
        Jérôme Glisse <jglisse@...hat.com>,
        <inux-ia64@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        "open list:ANDROID DRIVERS" <devel@...verdev.osuosl.org>,
        <tee-dev@...ts.linaro.org>, Linux-MM <linux-mm@...ck.org>,
        <netdev@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
        <rds-devel@....oracle.com>
Subject: Re: [RFC] mm/gup.c: Updated return value of
 {get|pin}_user_pages_fast()

On 2020-05-07 03:32, Souptick Joarder wrote:
...
>> OK, so no real problem with any of these callers. I still don't see a
>> justification for the churn you suggest... Auditting all those code sites
>> is going to be pretty tedious.
> 
> I try to audit all 42 callers of {get|pin}_user_pages_fast() and
> figure out these 5 callers
> which need to be updated and I think, other callers of
> {get|pin}_user_pages_fast() will not be
> effected.
> 
> But I didn't go through other variants of gup/pup except
> {get|pin}_user_pages_fast().


I feel the need to apologize for suggesting that a change to -EINVAL
would help. :)

If you change what the return value means, but only apply it the
gup/pup _fast() variants of this API set, that would make
the API significantly *worse*.

Also, no one has been able to come up with a scenario in which the call
sites actually have a problem handling return values of zero. In fact,
on the contrary: there are call site where returning 0 after being
requested to pin zero pages, helps simplify the code. For example, if
they're just doing math such as "if(nr_expected != nr_pages_pinned) ...".


This looks like a complete dead end, sorry.

thanks,
-- 
John Hubbard
NVIDIA