linux-kernel - Re: [PATCH v3 2/5] fat: allocate persistent inode numbers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKYAXd9EzKH_x1GaXvSZ7pRebfOcwQqNp6-oEnc2z2evuNo23g@mail.gmail.com>
Date:	Mon, 24 Sep 2012 13:58:24 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	akpm@...ux-foundation.org, bfields@...ldses.org,
	viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org,
	Namjae Jeon <namjae.jeon@...sung.com>,
	Ravishankar N <ravi.n1@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v3 2/5] fat: allocate persistent inode numbers

2012/9/24, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>:
> Namjae Jeon <linkinjeon@...il.com> writes:
>
>>> I think we don't need this. Because FH and ino is not necessary to have
>>> relation.
>>>
>>> Can we re-introduce ->encode_fh() handler, and export i_pos again?  With
>>> this, I think we can get i_pos correctly. Otherwise, ino may not contain
>>> all bits of i_pos.
>> I already tried to fix this issue using encode_fh without stable ino
>> before.
>> But I reached conclusion that we should use stable inode number.
>>
>> e.g. If we rebuild inode number using i_pos of fh, inode number is
>> changed by i_unique.
>> And It is not match with inode number of FH on NFS client. So estale
>> error will happen.
>
> What is problem if i_ino + i_generation is not match? I think, even if
> those didn't match, i_pos in FH should resolve issue, no?
No, It can not resolve issue.
in NFS file handle, there is a reference to the current inode number.
So, if by eviction that is changed - that it will results in "file id
changed" error.
even though using the i_pos we can reconstruct and get the INODE on
the Server, but the NFS handle is no more valid. As the inode number
is also changed, iunique() for the file will result in different
number this time.

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