[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yg82oSHmodFHMHHI@mit.edu>
Date: Fri, 18 Feb 2022 01:03:13 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Matthew Wilcox <willy@...radead.org>
Cc: Lee Jones <lee.jones@...aro.org>, linux-ext4@...r.kernel.org,
Christoph Hellwig <hch@....de>,
Dave Chinner <dchinner@...hat.com>,
Goldwyn Rodrigues <rgoldwyn@...e.com>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Bob Peterson <rpeterso@...hat.com>,
Damien Le Moal <damien.lemoal@....com>,
Andreas Gruenbacher <agruenba@...hat.com>,
Ritesh Harjani <riteshh@...ux.ibm.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Johannes Thumshirn <jth@...nel.org>, linux-xfs@...r.kernel.org,
linux-fsdevel@...r.kernel.org, cluster-devel@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [REPORT] kernel BUG at fs/ext4/inode.c:2620 - page_buffers()
On Fri, Feb 18, 2022 at 04:24:20AM +0000, Matthew Wilcox wrote:
> On Thu, Feb 17, 2022 at 09:54:30PM -0500, Theodore Ts'o wrote:
> > process_vm_writev() uses [un]pin_user_pages_remote() which is the same
> > interface uses for RDMA. But it's not clear this is ever supposed to
> > work for memory which is mmap'ed region backed by a file.
> > pin_user_pages_remote() appears to assume that it is an anonymous
> > region, since the get_user_pages functions in mm/gup.c don't call
> > read_page() to read data into any pages that might not be mmaped in.
>
> ... it doesn't end up calling handle_mm_fault() in faultin_page()?
Ah yes, sorry, I missed that. This is what happens when a syzbot bug
is thrown to a file system developer, who then has to wade theough
mm code for which he is not understand....
- Ted
Powered by blists - more mailing lists