Re: Bug fixes in -mm that should go into 2.6.16

Re: Bug fixes in -mm that should go into 2.6.16

[Jan Kara]

> Adrian Bunk <bunk@stusta.de> wrote:
> >
> > Hi Andrew,
> > 
> > the following two patches in -mm should IMHO go into 2.6.16:
> >   fix-oops-in-invalidate_dquots.patch
> 
> Maybe.  I worry about the intrusiveness versus probability-of-oops.
  Yes, I guess the oops is not very probable - at least the bug was
there unnoticed for several months...
  BTW Recently I found out in discussion with Neil Brown that probably
there is a similar problem with umount. The problem is that an inode in
both generic_delete_inode() and generic_forget_inode() is removed from
i_sb_list and i_list. Then I_FREEING is set and inode_lock released. Now
if umount is called, I did not find anything that protects
invalidate_inodes() from missing those pending inodes. So it could
happen that we succeed with unmounting the filesystem but there are
still some live inodes... So we should either leave those inodes in some
superblock list where invalidate_inodes() can reach them or we should
implement some other measure that blocks umount from proceeding before
all those pending inodes are really processed (one idea was some
active_inode counter in the superblock). And if we solve this problem
for umount, then quota can possibly use similar approach for handling
the problem with invalidate_dquots().
  Any ideas?

								Honza

-- 
Jan Kara <jack@suse.cz>
SuSE CR Labs

Re: Bug fixes in -mm that should go into 2.6.16

[Andrew Morton]

Jan Kara <jack@suse.cz> wrote:
>
> > Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > Hi Andrew,
> > > 
> > > the following two patches in -mm should IMHO go into 2.6.16:
> > >   fix-oops-in-invalidate_dquots.patch
> > 
> > Maybe.  I worry about the intrusiveness versus probability-of-oops.
>   Yes, I guess the oops is not very probable - at least the bug was
> there unnoticed for several months...
>   BTW Recently I found out in discussion with Neil Brown that probably
> there is a similar problem with umount. The problem is that an inode in
> both generic_delete_inode() and generic_forget_inode() is removed from
> i_sb_list and i_list. Then I_FREEING is set and inode_lock released. Now
> if umount is called, I did not find anything that protects
> invalidate_inodes() from missing those pending inodes. So it could
> happen that we succeed with unmounting the filesystem but there are
> still some live inodes... So we should either leave those inodes in some
> superblock list where invalidate_inodes() can reach them or we should
> implement some other measure that blocks umount from proceeding before
> all those pending inodes are really processed (one idea was some
> active_inode counter in the superblock). And if we solve this problem
> for umount, then quota can possibly use similar approach for handling
> the problem with invalidate_dquots().
>   Any ideas?

Could be - I guess the first step would be seeing if it can be triggered.

One option might be to take sb->s_umount for reading while those inodes are
adrift.