Messages in this thread | | | Date | Fri, 20 Feb 2004 17:47:04 +0000 | From | Jamie Lokier <> | Subject | Re: explicit dcache <-> user-space cache coherency, sys_mark_dir_clean(), O_CLEAN |
| |
Linus Torvalds wrote to Ingo Molnar; > Your version is also not multi-threaded: you can never allow more than one > thread doing the "sys_mark_dir_clean()".
It's fine as long as each thread has its own dirfd. The "clean bit" applies to an fd. Or did I miss something obvious?
> The problem is that you'd still need other system calls
Here's a thought. It's a bit ugly, but it offers O_CLEAN-like functionality without extra system calls for each operation:
fchdir(dirfd);
That means change to dirfd in the current process (or thread if CLONE_FS), and when the "clean bit" is set on dirfd, then any creation of a name _with no directory component_ will abort.
For example, these operations all create names which will check dirfd's clean bit, and abort if it's set:
open("file1", O_CREAT|O_TRUNC|O_RDWR, 0666); link("file1", "file2"); symlink("file1","file3"); rename("file1", "file4"); link("subdir/file1", "file2"); symlink("subdir/file1","file3"); rename("subdir/file1", "file4");
These operations don't check any clean bits:
open("/tmp/file1", O_CREAT|O_TRUNC|O_RDWR, 0666); open("./file1", O_CREAT|O_TRUNC|O_RDWR, 0666); link("file1", "subdir/file2"); symlink("file1","subdir/file3"); rename("file1", "subdir/file4");
If dirfd is closed, then of course the current directory stays the same, but there is no clean bit to check any more. chdir() also implies no clean bit to check.
In other words the notion of current directory is extended to be (inode, fd). fd can be NULL, or an fd whose clean bit must be checked before allowing name creation for "/"-less paths.
(As you know I prefer to use dnotify on dirfd to represent the "clean bit", but that's the subject of another mail).
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |