Re: 2.6.4-rc1 oops on HPFS filesystem file rename

[viro@parcelfarce.linux.theplanet.co.uk]

On Sun, Feb 29, 2004 at 01:14:25PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> Unless there are complaints and bug reports, it will go to Linus in a couple
> of days.

Oh, lovely - there's a deadlock (both in new and old code) too.  The trouble
being, we can get ->write_inode() *triggered* in the middle of btree
rebalancing.  Which leads to deadlock, since we really need the exclusion
there (and would be very unhappy if search for directory entry would happen
in the middle of that fun).

Fix is to switch the allocations done in that area to GFP_NOFS.  However,
there's an extra PITA caused by inode allocations - we'll need to take
the inode allocation in hpfs_create() et.al. outside of lock on parent.

Potential inode allocation in ->write_inode() (done if parent inode is
not in core - that can happen, unfortunately) is not a problem if we
replace the "parent can change" semaphore to rwsem and hold it for
read here.  There's no risk of down_read()/somebody does down_write()/the
first task gets recursive down_read() deadlock in that case, since all
down_write() can happen only if parent inode is already in-core.

Sigh...  Gotta love that code - deadlocks had been there since _way_ back...

Additional patch later today...