hfsplus: fix link corruption

HFS implements hardlink by using indirect catalog entries that refer to a hidden
directly.  The link target is cached in the dev field in the HFS+ specific
inode, which is also used for the device number for device files, and inside
for passing the nlink value of the indirect node from hfsplus_cat_write_inode
to a helper function.  Now if we happen to write out the indirect node while
hfsplus_link is creating the catalog entry we'll get a link pointing to the
linkid of the current nlink value.  This can easily be reproduced by a large
enough loop of local git-clone operations.

Stop abusing the dev field in the HFS+ inode for short term storage by
refactoring the way the permission structure in the catalog entry is
set up, and rename the dev field to linkid to avoid any confusion.

While we're at it also prevent creating hard links to special files, as
the HFS+ dev and linkid share the same space in the on-disk structure.

Signed-off-by: Christoph Hellwig <hch@tuxera.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/fs/hfsplus/catalog.c b/fs/hfsplus/catalog.c
index 48979c4e8fa5..9d1594b0a07a 100644
--- a/fs/hfsplus/catalog.c
+++ b/fs/hfsplus/catalog.c
@@ -134,7 +134,7 @@ static int hfsplus_cat_build_record(hfsplus_cat_entry *entry, u32 cnid, struct i
                         file->user_info.fdCreator = cpu_to_be32(HFSP_HFSPLUS_CREATOR);
                         file->user_info.fdFlags = cpu_to_be16(0x100);
                         file->create_date = HFSPLUS_I(sbi->hidden_dir)->create_date;
-                        file->permissions.dev = cpu_to_be32(HFSPLUS_I(inode)->dev);
+                        file->permissions.dev = cpu_to_be32(HFSPLUS_I(inode)->linkid);
                 }
                 return sizeof(*file);
         }