fh_lock()/fh_unlock(). Hell, it does call notify_change() with ATTR_SIZE,
so unless i_sem was taken by caller we would be in big trouble, wouldn't
we? Old rules were "if you call it to truncate a file, grab i_sem".
> The hpfs/namei.c one definitely needs the removal of the up/down, though.
> Altghough for the life of me I don't see why the filesystem _does_ that at
> all, since it should have been done by the upper layers already, no?
<looking> oh, crap.
OK, here's the story:
* HPFS can run out of space trying to remove entry from directory.
Joys of badly implemented B-Trees. So as a last-ditch we try to truncate
victim in hope that it will give us some space. _If_ there is nobody else
who'd have access to it. Thus the truncate() attempt.
* my flame re grep(1) applies to myself - first deadlock in there
had been created by new locking rules patch (in fs/namei.c).
* Dave's patch had added one more level of the same. Happy, happy,
Looking at that stuff, I'd suggest to
a) kill that branch in hpfs_unlink().
b) remove fh_lock()/fh_unlock() in nfsd/vfs.c::nfsd_setattr() (Trond?)
c) add ATTR_SXID that would do s[ug]id removal - under ->i_sem and switch
the callers to it.
Comments? If you don't see any problems with this variant I'll do it.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/