[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220923001846.GX3600936@dread.disaster.area>
Date: Fri, 23 Sep 2022 10:18:46 +1000
From: Dave Chinner <david@...morbit.com>
To: Jason Gunthorpe <jgg@...dia.com>
Cc: Dan Williams <dan.j.williams@...el.com>, akpm@...ux-foundation.org,
Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
"Darrick J. Wong" <djwong@...nel.org>,
Christoph Hellwig <hch@....de>,
John Hubbard <jhubbard@...dia.com>,
linux-fsdevel@...r.kernel.org, nvdimm@...ts.linux.dev,
linux-xfs@...r.kernel.org, linux-mm@...ck.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH v2 05/18] xfs: Add xfs_break_layouts() to the inode
eviction path
On Wed, Sep 21, 2022 at 07:28:51PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 22, 2022 at 08:14:16AM +1000, Dave Chinner wrote:
>
> > Where are these DAX page pins that don't require the pin holder to
> > also hold active references to the filesystem objects coming from?
>
> O_DIRECT and things like it.
O_DIRECT IO to a file holds a reference to a struct file which holds
an active reference to the struct inode. Hence you can't reclaim an
inode while an O_DIRECT IO is in progress to it.
Similarly, file-backed pages pinned from user vmas have the inode
pinned by the VMA having a reference to the struct file passed to
them when they are instantiated. Hence anything using mmap() to pin
file-backed pages (i.e. applications using FSDAX access from
userspace) should also have a reference to the inode that prevents
the inode from being reclaimed.
So I'm at a loss to understand what "things like it" might actually
mean. Can you actually describe a situation where we actually permit
(even temporarily) these use-after-free scenarios?
Cheers,
Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists