[ext2resize] Re: Deadlock help

[Andreas D. <ad...@cl...>]

On Oct 02, 2002  13:43 -0700, Robert Walsh wrote:
> [ Andreas: just for context - I was getting an oops while doing I/O on a
> filesystem that was being resized. ]
> 
> > Is this ext3?  Probably you have someone doing a journal_start()
> > while holding the superblock lock.  That's the wrong order.
> 
> That was it.  The resize code does a lock_super/unlock_super around the
> two resize entry points in ioctl.c and calls journal_start/journal_stop
> in several places while doing the resize.  This was causing the oops
> while doing I/O and resizing simultaneously.
> 
> Since I don't know when the superblock actually really needs to be
> locked, I err'd on the side of caution and put an
> unlock_super/lock_super around each call to journal_start and
> journal_stop.  This seemed to make the problem go away but it's a lot of
> locking/unlocking to be going on.
> 
> Is it really necessary for the resize code to hold onto the superblock
> locks for such a long length of time?  Would it be possible to minimize
> the amount of locking needed here?

The superblock lock is needed in a few places for resizing:
- to protect the s_gdb_count, s_groups_count, s_group_desc (for adding
  new groups only)
- the on-disk values s_*_blocks_count, s_*inodes_count (for all resizes)

The intention is that other processes cannot start using the new space
until it is completely set up.  We want to avoid a situation where a
file is allocated in the new space, and then we say "oops, there was a
problem, let's yank that new space back" == missing data.

I think this can be done fairly cleanly by ensuring everything is set up
before updating the superblock (in memory and on disk), and only holding
the lock over that update.  For extend-the-end resizing, we already have
to drop the lock for ext3_free_blocks(), because it gets the lock itself.


Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/