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: <87oblc4u6f.fsf@devron.myhome.or.jp>
Date:	Tue, 11 Sep 2012 21:31:52 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Namjae Jeon <linkinjeon@...il.com>
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

Namjae Jeon <linkinjeon@...il.com> writes:

>> Since rename() will be disabled on stable ino patches, this will be
>> unfixable, so rather maybe it is worse.
> Currently with our patchset : only rename issue (could not find any
> correct approach to ignore this. If we do not update this immediately
> at i_pos change – it is just delaying the problem). And we can return
> EBUSY when rename is called while process is opening file with rename
> limitation. Without our patchset also - the rename issue can occur
> over NFS file access - when the inode is evicted from the SERVER
> cache.

Important difference is whether rename issue is unfixable or not.

> 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?)

I'm assuming the retry means - it restarts from building the NFS file
handle. I might be just wrong here though.

>> I'd like to be knowing the critical reason we have to replace it.
> I arrange to help your decision as the following.
>
> 1. lookup cache is enable at default in NFS. So estale error can be
> easily occurred in -mm.
> 2. If lookup cache is disable, there is rename issue and file lookup
> performance is dropped in -mm.
> 4. If we use our patches, there is rename issue. but we can use VFAT
> over NFS with lookup cache enable.
> 5. If we use read-only with our patches, there is no issue.

Again, I'm care about whether rename issue is unfixable or not. In
stable ino patches, it will never be fixable.


What do you think about this rename issue, Steven?
-- 
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/