linux-kernel - Re: [PATCH -next] mm/filemap: fix that first page is not mark accessed in filemap

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 10 Jun 2022 15:36:33 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Yu Kuai <yukuai3@...wei.com>, kent.overstreet@...il.com
Cc:     akpm@...ux-foundation.org, axboe@...nel.dk,
        linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, yi.zhang@...wei.com
Subject: Re: [PATCH -next] mm/filemap: fix that first page is not mark
 accessed in filemap_read()

On Fri, Jun 10, 2022 at 03:34:11PM +0100, Matthew Wilcox wrote:
> On Mon, Jun 06, 2022 at 09:10:03AM +0800, Yu Kuai wrote:
> > On 2022/06/03 2:30, Matthew Wilcox wrote:
> > > On Thu, Jun 02, 2022 at 04:21:29PM +0800, Yu Kuai wrote:
> > > > In filemap_read(), 'ra->prev_pos' is set to 'iocb->ki_pos + copied',
> > > > while it should be 'iocb->ki_ops'.
> > > 
> > > Can you walk me through your reasoning which leads you to believe that
> > > it should be ki_pos instead of ki_pos + copied?  As I understand it,
> > > prev_pos is the end of the previous read, not the beginning of the
> > > previous read.
> > 
> > Hi, Matthew
> > 
> > The main reason is the following judgement in flemap_read():
> > 
> > if (iocb->ki_pos >> PAGE_SHIFT !=	-> current page
> >     ra->prev_pos >> PAGE_SHIFT)		-> previous page
> >         folio_mark_accessed(fbatch.folios[0]);
> > 
> > Which means if current page is the same as previous page, don't mark
> > page accessed. However, prev_pos is set to 'ki_pos + copied' during last
> > read, which will cause 'prev_pos >> PAGE_SHIFT' to be current page
> > instead of previous page.
> > 
> > I was thinking that if prev_pos is set to the begining of the previous
> > read, 'prev_pos >> PAGE_SHIFT' will be previous page as expected. Set to
> > the end of previous read is ok, however, I think the caculation of
> > previous page should be '(prev_pos - 1) >> PAGE_SHIFT' instead.
> 
> OK, I think Kent broke this in 723ef24b9b37 ("mm/filemap/c: break
> generic_file_buffered_read up into multiple functions").  Before:
> 
> -       prev_index = ra->prev_pos >> PAGE_SHIFT;
> -       prev_offset = ra->prev_pos & (PAGE_SIZE-1);
> ...
> -               if (prev_index != index || offset != prev_offset)
> -                       mark_page_accessed(page);
> 
> After:
> +       if (iocb->ki_pos >> PAGE_SHIFT != ra->prev_pos >> PAGE_SHIFT)
> +               mark_page_accessed(page);
> 
> So surely this should have been:
> 
> +       if (iocb->ki_pos != ra->prev_pos)
> +               mark_page_accessed(page);
> 
> Kent, do you recall why you changed it the way you did?

Oh, and if this is the right diagnosis, then this is the fix for the
current tree:

+++ b/mm/filemap.c
@@ -2673,8 +2673,7 @@ ssize_t filemap_read(struct kiocb *iocb, struct iov_iter *iter,
                 * When a sequential read accesses a page several times, only
                 * mark it as accessed the first time.
                 */
-               if (iocb->ki_pos >> PAGE_SHIFT !=
-                   ra->prev_pos >> PAGE_SHIFT)
+               if (iocb->ki_pos != ra->prev_pos)
                        folio_mark_accessed(fbatch.folios[0]);

                for (i = 0; i < folio_batch_count(&fbatch); i++) {