Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 28, 2024 at 04:22:32AM +0000, Matthew Wilcox wrote:
> On Wed, Feb 28, 2024 at 03:00:36AM +0000, Matthew Wilcox wrote:
> > On Tue, Feb 27, 2024 at 09:22:26PM -0500, Kent Overstreet wrote:
> > > Which does raise the question of if we've ever attempted to define a
> > > lock ordering on folios. I suspect not, since folio lock doesn't even
> > > seem to have lockdep support.
> > 
> > We even wrote it down!
> > 
> >                 /*
> >                  * To avoid deadlocks between range_cyclic writeback and callers
> >                  * that hold pages in PageWriteback to aggregate I/O until
> >                  * the writeback iteration finishes, we do not loop back to the
> >                  * start of the file.  Doing so causes a page lock/page
> >                  * writeback access order inversion - we should only ever lock
> >                  * multiple pages in ascending page->index order, and looping
> >                  * back to the start of the file violates that rule and causes
> >                  * deadlocks.
> >                  */
> > 
> > (I'll take the AR to put this somewhere better like in the folio_lock()
> > kernel-doc)
> 
> Um.  I already did.
> 
>  * Context: May sleep.  If you need to acquire the locks of two or
>  * more folios, they must be in order of ascending index, if they are
>  * in the same address_space.  If they are in different address_spaces,
>  * acquire the lock of the folio which belongs to the address_space which
>  * has the lowest address in memory first.
> 
> Where should I have put this information that you would have found it,
> if not in the kernel-doc for folio_lock()?

I should have seen that :)

But even better would be if we could get lockdep to support folio locks,
then we could define a lockdep comparison function. Of course, there's
no place to stick a lockdep map, but I think technically lockdep could
do everything it needs to do without state in the lock itself, if only
that code didn't make my eyes bleed whenever I have to dig into it...




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux