i_nlink fixes, part 1

Please, pull from
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ i_nlink

Shortlog:
Al Viro (8):
sysv: i_nlink races in rename()
ufs: i_nlink races in rename()
minix: i_nlink races in rename()
nilfs2: i_nlink races in rename()
exofs: i_nlink races in rename()
fix reiserfs mkdir() breakage
udf: fix i_nlink limit
hfs: fix rename() over non-empty directory

Diffstat:

 fs/exofs/namei.c    |    8 ++------
 fs/hfs/dir.c        |   50 +++++++++++++-------------------------------------
 fs/minix/namei.c    |    8 ++------
 fs/nilfs2/namei.c   |    8 +-------
 fs/reiserfs/namei.c |    2 +-
 fs/sysv/namei.c     |    8 ++------
 fs/udf/namei.c      |   11 +++++------
 fs/ufs/namei.c      |    9 ++-------
 8 files changed, 28 insertions(+), 76 deletions(-)

Al, you _really_ need to improve your chagelogs.

What _are_ the races? You don't explain. And the patch in no way makes it obvious either.

Now, compare it to the explanation for the ext2 case in commit e8a80c6f769d and ask yourself: why didn't you? Yes, I can read _that_ commit, and I know what's going on, but a few weeks from now (or for anybody else that only reads the commits for the one filesystem they care about), that single line is going to be totally useless.

Maybe it doesn't need to be as extensive, but dang it, it needs to be more than "fix races" with no explanation at all.

Saying just "fix race" may be fine if the patch itself is totally self-explanatory (add a missing lock or whatever), but even then I'd prefer something more.

I realize that you are really used to RCS, which made it a pain to write any kind of explanation at all, but come on.

Linus