linux-kernel - Re: [PATCH v2 1/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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAKYAXd89CKZa9nV3pBiFgcpGsYzX1-iCB+UJ8bBvst88GnB4mg@mail.gmail.com>
Date:	Wed, 12 Sep 2012 23:12:56 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	"Steven J. Magnani" <steve@...idescorp.com>,
	Al Viro <viro@...iv.linux.org.uk>, akpm@...ux-foundation.org,
	bfields@...ldses.org, 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 v2 1/5] fat: allocate persistent inode numbers

2012/9/12 OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>:
> Namjae Jeon <linkinjeon@...il.com> writes:
>
>>>> I think that it is unfixable because we can not know i_pos of inode
>>>> changed by rename.
>>>> And even though we know it, there is no rebuild inode routine in -mm.
>>>> And It even can not fix in our patches.
>>>
>>>>> And are you tried https://lkml.org/lkml/2012/6/29/381 patches? It sounds
>>>>> like to improve performance by enabling lookupcache.
>>>> We checked this patches when facing estale issue in -mm.
>>>> But It is no use, these patches just retry system call one more when
>>>> estale error.
>>>
>>> What happens if client retried from lookup() after -ESTALE? (client NFS
>>> doesn't have the name of entry anymore?)
>> Need to rebuild inode routine because inode cache is already evicted on Server.
>>>
>>> I'm assuming the retry means - it restarts from building the NFS file
>>> handle. I might be just wrong here though.
>> As I remember, just retry in VFS of NFS client..I heard this patch is
>> needed for
>> a very specific set of circumstances where an entry goes stale once
>> between the lookup and the actual operation(s).
>> It is not related with current issues(inode cache eviction on server).
>
> Supposing, the server/client state is after cold boot, and client try to
> rename at first without any cache on client/server.
>
> Even if this state, does the server return ESTALE? If it doesn't return
> ESTALE, I can't understand why it is really unfixable.
Hi OGAWA.
Server will not return ESTALE in this case. because the client does
not have any information for files yet.
I mean NFS client does not have any old NFS FH(containing old inode
number) for this.

>
> If it returns ESTALE, why does it return? I'm assuming the previous code
> path is the cached FH path.
The main point for observation is the file handle-which is used for
all the NFS operation.
So for all the NFS operation(read/write....) which makes use of the
NFS file handle in between if there is a change in inode number
It will result in ESTALE.
Changing inode number on rename happened at NFS server by inode cache
eviction with memory pressure.

lookupcache is used at NFS client to reduce number of LOOKUP operations.
But , we can still get ESTALE if inode number at NFS Server change
after LOOKUP, although lookupcache is disable.

LOOKUP return NFS FH->[inode number changed at NFS Server] ->
But we still use old NFS FH returned from LOOKUP for any file
operation(write,read,etc..)
-> ESTALE will be returned.

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/