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] [thread-next>] [day] [month] [year] [list]
Message-ID: <222e01e6-bb00-51ee-a94c-089b43cbaf42@nvidia.com>
Date:   Thu, 3 Feb 2022 12:44:57 -0800
From:   John Hubbard <jhubbard@...dia.com>
To:     Jason Gunthorpe <jgg@...dia.com>
Cc:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>, Peter Xu <peterx@...hat.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        David Hildenbrand <david@...hat.com>, Jan Kara <jack@...e.cz>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: Weird code with change "mm/gup: clean up follow_pfn_pte()
 slightly"

On 2/3/22 05:01, Jason Gunthorpe wrote:
...
>>> In the new branch if (pages), you set page = ERR_PTR(-EFAULT) and goto
>>> out. However, at the label out, the value of page is not used, but the
>>> return uses the variables i and ret.
>>
>> Yes, I think that the complaint is accurate. The intent of this code is
>> to return either number of pages so far (i) or ret (which should be zero
>> in this case), because we are just stopping early, rather than calling
>> this an actual error.
> 
> IIRC GUP shouldn't return 0, it should return an error code, not zero.
> 
> Jason

Errors work for single pages, but GUP is a multi-page API call. If it
returned an error part way through the list of pages, then callers would
have no way of knowing how many pages to release.

With that in mind, the API returns the number of pages that were
successfully pinned, if that number is > 0 (or even 0, in some cases),
even when an error has been encountered.

__get_user_pages()'s kerneldoc documentation covers it. And I see now
that it needs tweaking to include the FOLL_PIN case, but anyway:

  * Returns either number of pages pinned (which may be less than the
  * number requested), or an error. Details about the return value:
  *
  * -- If nr_pages is 0, returns 0.
  * -- If nr_pages is >0, but no pages were pinned, returns -errno.
  * -- If nr_pages is >0, and some pages were pinned, returns the number of
  *    pages pinned. Again, this may be less than nr_pages.
  * -- 0 return value is possible when the fault would need to be retried.
  *
  * The caller is responsible for releasing returned @pages, via put_page().


thanks,
-- 
John Hubbard
NVIDIA

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ