Re: [PATCH v5 7/8] fat (exportfs): rebuild directory-inode iffat_dget() fails

[Namjae Jeon]

2012/12/4, OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>:
> Namjae Jeon <linkinjeon@xxxxxxxxx> writes:
>
>> 2012/12/3, OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>:
>>> Namjae Jeon <linkinjeon@xxxxxxxxx> writes:
>>>
>>>> From: Namjae Jeon <namjae.jeon@xxxxxxxxxxx>
>>>>
>>>> This patch enables rebuilding of directory inodes which are not present
>>>> in the cache.This is done by traversing the disk clusters to find the
>>>> directory entry of the parent directory and using its i_pos to build
>>>> the
>>>> inode.
>>>> Do this only if the "nostale_ro" nfs mount option is specified.
>>>
>>> This became much better than before. However, we have to consolidate the
>>> code with fat_search_long() finally.
>>>
>>> E.g. this version is having the issue already fixed. If there is
>>> corruption in fat cluster-chain, it lead to infinite
>>> loop. fat_get_cluster() checks infinite loop by limit.
>> since, the focus this time was for NFS functionality for FAT (removing
>> ESTALE error). The changes were made in that context.
>>
>> Later, we can make the changes as part of code reorganizing which can
>> be controlled via. Separate patches which do not have any impact on
>> default functionality and verification can be carried out in that
>> scope.
>
> Right. But non-production code shouldn't go into linus tree. I meant, we
> can test this patch series, but not yet production quality.
Is there any other thing which seems potential issue than offsetof()?
if yes, which problem didn't lead to production quality do you think ?

+#define FAT_FID_SIZE_WITHOUT_PARENT (offsetof(struct fat_fid, \
+					      parent_i_pos_hi)/4)
Since this expression does not result proper integer value, so will it
be correct to directly put the value like
+#define FAT_FID_SIZE_WITHOUT_PARENT 3

Thanks!
> --
> OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/