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  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 <>
To:     Souptick Joarder <>, Jan Kara <>
CC:     Tony Luck <>, <>,
        Rob Springer <>,
        Todd Poynor <>, <>,
        Greg KH <>,
        Jens Wiklander <>,
        Andrew Morton <>,
        "David S. Miller" <>, <>,
        Ira Weiny <>,
        Jérôme Glisse <>,
        <>, <>,
        "open list:ANDROID DRIVERS" <>,
        <>, Linux-MM <>,
        <>, <>,
Subject: Re: [RFC] mm/gup.c: Updated return value of

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.

John Hubbard

Powered by blists - more mailing lists