Summary:
* new functions: page_readlink() and page_follow_link(). If you
have ->readlink() that places the symlink contents into pagecache at
offset 0 - put those as ->readlink() and ->follow_link() and be done with
that. In that case stack footprint of lookup_dentry()=>do_follow_link()=>
->follow_link()=>lookup_dentry() is 104 bytes on x86. Compared to ~1Kb in
the worst cases in 2.3.30-pre2...
* if you are using the above with block_read_full_page() _and_
you support link creation - use block_symlink() to write the link contents
(see minix_symlink() for example of usage).
* if you have symlink contents in-core and it's not going to go
away (autofs, /proc/self, /proc/ide/hda, etc.) - let your ->follow_link()
and ->readlink() call vfs_readlink() and vfs_follow_link(). The thing will
not be cached (no need to do that), but it will save you some bothering
with details. See fs/autofs/symlink.c for example of that.
Remaining problems:
* UMSDOS symlinks over DMSDOS. Currently broken (UMSDOS over
normal msdosfs should be OK).
* UFS still creates only slow symlinks (bug shared with the main
tree). It's unrelated to this patch, but related to symlinks ;-) To be
fixed RSN.
* QNX symlinks are still broken (fix is trivial, but I'ld rather
wait for qnx4_get_block()).
* Any bugs I haven't catch ;-)
As far as I'm concerned it's damn close to final variant. Unless there are
unknown bugs it can go into the main tree as is. The problem being to make
sure that there is no such bugs, indeed.
Please, help with testing. It seems to be safe on ext2 and NFS, but the
rest of filesystems needs good testing. Things to test: symlink creation,
reading and following through. I'm reasonably sure in normal UNIX-like
filesystems, but things EFS/HPFS/ISOFS/NCPFS may be trickier. I think that
they are OK, but...
The thing definitely builds (minus usual troublemakers - NTFS, HFS, AFFS
and QNX4). So there... Patch is too large for l-k and fsdevel, so I'm
putting it on ftp.math.psu.edu/pub/viro/as-patch-22. Bug/success reports
are more than welcome.
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/