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: <20230602175547.dba09bb3ef7eb0bc508b3a5a@linux-foundation.org>
Date:   Fri, 2 Jun 2023 17:55:47 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Mike Kravetz <mike.kravetz@...cle.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org,
        Matthew Wilcox <willy@...radead.org>,
        Ackerley Tng <ackerleytng@...gle.com>,
        Sidhartha Kumar <sidhartha.kumar@...cle.com>,
        Muchun Song <songmuchun@...edance.com>, vannapurve@...gle.com,
        erdemaktas@...gle.com, stable <stable@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 0/1] RESEND fix page_cache_next/prev_miss off by one
 error

On Fri,  2 Jun 2023 15:57:46 -0700 Mike Kravetz <mike.kravetz@...cle.com> wrote:

> In commits d0ce0e47b323 and 91a2fb956ad99, hugetlb code was changed to
> use page_cache_next_miss to determine if a page was present in the page
> cache.  However, the current implementation of page_cache_next_miss will
> always return the passed index if max_scan is 1 as in the hugetlb code.
> As a result, hugetlb code will always thing a page is present in the
> cache, even if that is not the case.
> 
> The patch which follows addresses the issue by changing the implementation
> of page_cache_next_miss and for consistency page_cache_prev_miss.  Since
> such a patch also impacts the readahead code, I would suggest using the
> patch by Sidhartha Kumar [1] to fix the issue in 6.3 and this patch moving
> forward.

Well this is tricky.

This patch applies cleanly to 6.3, so if we add cc:stable to this
patch, it will get backported, against your suggestion.

Sidhartha's patch [1] (which you recommend for -stable) is quite
different from this patch.  And Sidhartha's patch has no route to being
tested in linux-next nor to being merged by Linus.

So problems.  The preferable approach is to just backport this patch
into -stable in the usual fashion.  What are the risks in doing this?

> If we would rather not modify page_cache_next/prev_miss, then a new
> interface as suggested by Ackerley Tng [2] could also be used.
> 
> Comments on the best way to fix moving forward would be appreciated.
> 
> [1] https://lore.kernel.org/linux-mm/20230505185301.534259-1-sidhartha.kumar@oracle.com/
> [2] https://lore.kernel.org/linux-mm/98624c2f481966492b4eb8272aef747790229b73.1683069252.git.ackerleytng@google.com/
> 
> Mike Kravetz (1):
>   page cache: fix page_cache_next/prev_miss off by one
> 
>  mm/filemap.c | 26 ++++++++++++++++----------
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ