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: <87r66hpqf1.fsf@devron.myhome.or.jp>
Date:	Thu, 16 Oct 2008 05:13:54 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	viro@...iv.linux.org.uk, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, bnaujok@....com
Subject: Re: [PATCH 6/6] vfs: add LOOKUP_RENAME_NEW intent

Christoph Hellwig <hch@...radead.org> writes:

> On Wed, Oct 15, 2008 at 10:58:11PM +0900, OGAWA Hirofumi wrote:
>> 
>> This adds LOOKUP_RENAME_NEW intent for lookup of rename destination.
>> 
>> LOOKUP_RENAME_NEW is going to be used like LOOKUP_CREATE. But since
>> the destination of rename() can be existing directory entry, so it has a
>> difference. Although that difference doesn't matter in my usage, this
>> tells it to user of this intent.
>
> Is this for handling CI rename properly?  Barry was looking into this,

Exactly, it is for some kind of CI rename workaround.

> but i told him to hold off for a while - the lookup code is changing
> quite a bit because Al is trying to sort out the lookup intent mess and
> we hopefully will stop passing the nameidata to ->lookup soon.

Umm.. however the intent for ->lookup() is useful for optimization in
some case?

> Also I think LOOKUP_RENAME_TARGET might be a little more descriptive
> than LOOKUP_RENAME_NEW.

It is the name which namei.c is using, anyway I don't care at all.
I'll take it.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>


[PATCH] vfs: add LOOKUP_RENAME_TARGET intent

This adds LOOKUP_RENAME_TARGET intent for lookup of rename destination.

LOOKUP_RENAME_TARGET is going to be used like LOOKUP_CREATE. But since
the destination of rename() can be existing directory entry, so it has a
difference. Although that difference doesn't matter in my usage, this
tells it to user of this intent.

Signed-off-by: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
---

 fs/namei.c            |    1 +
 include/linux/namei.h |    1 +
 2 files changed, 2 insertions(+)

diff -puN fs/namei.c~dcache-add-rename-intent fs/namei.c
--- linux-2.6/fs/namei.c~dcache-add-rename-intent	2008-10-15 20:35:24.000000000 +0900
+++ linux-2.6-hirofumi/fs/namei.c	2008-10-16 05:06:53.000000000 +0900
@@ -2660,6 +2660,7 @@ asmlinkage long sys_renameat(int olddfd,
 
 	oldnd.flags &= ~LOOKUP_PARENT;
 	newnd.flags &= ~LOOKUP_PARENT;
+	newnd.flags |= LOOKUP_RENAME_TARGET;
 
 	trap = lock_rename(new_dir, old_dir);
 
diff -puN include/linux/namei.h~dcache-add-rename-intent include/linux/namei.h
--- linux-2.6/include/linux/namei.h~dcache-add-rename-intent	2008-10-15 20:35:24.000000000 +0900
+++ linux-2.6-hirofumi/include/linux/namei.h	2008-10-16 05:07:15.000000000 +0900
@@ -53,6 +53,7 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LA
  */
 #define LOOKUP_OPEN		(0x0100)
 #define LOOKUP_CREATE		(0x0200)
+#define LOOKUP_RENAME_TARGET	(0x0400)
 
 extern int user_path_at(int, const char __user *, unsigned, struct path *);
 
_
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ