| 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
| ||
|
Date: Mon, 5 May 2008 15:06:23 +0200 From: Enrico Weigelt <weigelt@...ux.de> To: linux kernel list <linux-kernel@...r.kernel.org> Subject: Re: VFS + path walktrough * Enrico Weigelt <weigelt@...ux.de> wrote: > Lets say we open /a/b/c/d and /a is mounted w/ some network > filesystem (eg. 9P). Who exactly does the walktrough from b to d ? > The individual filesystem or VFS ? > > The point is: the 9P protocol can work with whole pathnames, so > the client doesn't have to do the walkthrough manually - this > can heavily reduce traffic and latency. I'd like the 9P fs driver > to directly use this, if VFS can send the whole pathname at once. I've digget somebit in the source and found out that it goes down to link_path_walk(). It seems to split the pathname into components and walk through them one by one. We could just add another call vector to struct file_operations, as replacement for link_path_walk() - if it's zero, the original function is used. This way an filesystem can do the walktrough by it's own, but doesn't need to. What do you think about this ? cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- 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