Re: [PATCH] xfs: avoid lockdep false positives in xfs_trans_alloc

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

 



On Tue, Oct 2, 2018 at 1:32 AM Dave Chinner <david@xxxxxxxxxxxxx> wrote:
>
> On Mon, Oct 01, 2018 at 10:56:25AM +0300, Amir Goldstein wrote:
[...]
> > So while the statement "it's not a deadlock" may still be true, I am not
> > yet convinced that the claim that there are no dirty pages to write when
> > filesystem is frozen is sufficient to back that claim.
> >
> > Are you sure there was no deadlock lurking in there while fs is past
> > SB_FREEZE_FS and kswapd shrinker races with another process
> > releasing the last reference to an(other) inode?
>
> The inodes being released by the shrinkers should be clean, and
> hence releasing them does not require post-release transactions to
> be run.
>
> It does concern me that the overlay dcache shrinker is dropping the
> last reference to an XFS inode and it does not get put on the LRU
> for the correct superblock inode cache shrinker to free it. That
> implies that the overlay dcache shrinker is dropping the last
> reference to an unlinked inode.
>

Yes, there is nothing that prevents overlayfs (or ecryptfs) to end up
with the last reference on an underlying unlinked inode.
It will require an action of unlink from underlying layer, which is not
normal user behavior, but it is possible.

> AFAIA, the dcache shrinker should never be freeing the last
> reference to an unlinked inode - it should always be done from the
> context that unlinked the inode or the context that closed the final
> fd on that inode. i.e. a task context, not a shrinker or kswapd. Can
> you confirm what the state of the inode being dropped in that
> lockdep trace is?
>

Given that the stress tests runs fsstress in parallel (same seed) on
overlay and underlying lower fs, I would say that it is very likely to
trip on shrinker putting an overlay dentry/inode holding the last reference
to an unlinked underlying fs inode.

How concerned are you about this? Is it inherently hard to deal with
this situation in XFS? pardon my ignorance, but can't memory shrinker
trigger oom killer indirectly causing to release deleted inodes?
Not sure in which context those files/inodes get released?

Thanks,
Amir.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux