Dave Chinner wrote: > 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? Jason mentioned a scenario here: https://lore.kernel.org/all/YyuoE8BgImRXVkkO@xxxxxxxxxx/ Multi-thread process where thread1 does open(O_DIRECT)+mmap()+read() and thread2 does memunmap()+close() while the read() is inflight. Sounds plausible to me, but I have not tried to trigger it with a focus test.
