Port SquashFS to 2.6
Subsystems (3)
PATCH 1/1 Port SquashFS to 2.6
The following is a straight port of Phillip Lougher's SquashFS
(http://squashfs.sf.net). The port is based on squashfs 1.2 for 2.4.20.
The patch is on top of, and tested with, 2.6.0-test1-ac2. It applies cleanly on vanilla 2.6.0-test1 (since -ac2 is mostly bugfixes, there is not much point testing with vanilla, though).
There are four things that are different from the 2.4 version (is there "notes on porting filesystems from 2.4 to 2.6" somewhere, btw?).
- Hooks in init/do_mounts.c to mount things in initramfs seems to have removed (there is no mention of CRAMFS there anymore), so that part of the patch has been removed.
- 2.6 vfs calls dir_ops.readdir without BKL held, and expected to do that itself if needed. The attached port mimics what cramfs/inode.c does differently between 2.4 and 2.6.
- struct super_block in 2.6 vfs has removed the embedded union for filesystem private data. Filesystems are expected to use void *s_fs_info member in it to hang private data in kmalloc'ed memory if needed. The attached port again mimics what cramfs/inode.c does differently between 2.4 and 2.6.
- struct inode in 2.6 vfs has removed the embedded union for filesystem private data. Filesystems with private data now define its own xxx_inode_info struct that embeds struct inode. IOW, containment has become inside out. The attached port defines alloc_inode (and corresponding destroy_inode) members in the super_operations struct, mimicking what ext3/super.c does differently between 2.4 and 2.6.
fs/Kconfig +7 -0
@@ -1114,6 +1114,13 @@ If unsure, say N. +config SQUASHFS + tristate "SquashFs file system support" + help + Saying Y here includes support for SquashFs. + + If unsure, say N. + config VXFS_FS tristate "FreeVxFS file system support (VERITAS VxFS(TM) compatible)" help
fs/Makefile +1 -0
@@ -53,6 +53,7 @@ obj-$(CONFIG_JBD) += jbd/ obj-$(CONFIG_EXT2_FS) += ext2/ obj-$(CONFIG_CRAMFS) += cramfs/ +obj-$(CONFIG_SQUASHFS) += squashfs/ obj-$(CONFIG_RAMFS) += ramfs/ obj-$(CONFIG_HUGETLBFS) += hugetlbfs/ obj-$(CONFIG_CODA_FS) += coda/
fs/squashfs/Makefile +8 -0
@@ -0,0 +1,8 @@ +# +# Makefile for the linux squashfs routines. +# + +obj-$(CONFIG_SQUASHFS) += squashfs.o + +squashfs-objs := inode.o +
fs/squashfs/inode.c +1020 -0
1,020 lines not on this page · raw message
include/linux/squashfs_fs.h +304 -0
304 lines not on this page · raw message
include/linux/squashfs_fs_sb.h +41 -0
41 lines not on this page · raw message
lib/Kconfig +2 -2
@@ -17,8 +17,8 @@ # config ZLIB_INFLATE tristate - default y if CRAMFS=y || PPP_DEFLATE=y || JFFS2_FS=y || ZISOFS_FS=y || BINFMT_ZFLAT=y || CRYPTO_DEFLATE=y - default m if CRAMFS=m || PPP_DEFLATE=m || JFFS2_FS=m || ZISOFS_FS=m || BINFMT_ZFLAT=m || CRYPTO_DEFLATE=m + default y if CRAMFS=y || SQUASHFS=y || PPP_DEFLATE=y || JFFS2_FS=y || ZISOFS_FS=y || BINFMT_ZFLAT=y || CRYPTO_DEFLATE=y + default m if CRAMFS=m || SQUASHFS=m || PPP_DEFLATE=m || JFFS2_FS=m || ZISOFS_FS=m || BINFMT_ZFLAT=m || CRYPTO_DEFLATE=m config ZLIB_DEFLATE tristate
fs/squashfs/inode.c line 640
Quoted 13 lines · On Sat, 2003-07-19 at 18:59, [email protected] wrote:
fs/squashfs/inode.c +13
-0+static int squashfs_symlink_readpage (struct file *file,struct page *page) +{ +struct inode *inode = page->mapping->host; +struct squashfs_inode_info *sqi =SQUASH_I (inode); +int index = page->index <<PAGE_CACHE_SHIFT , length =0 , bytes; +int block = sqi->start_block; +int offset = sqi->offset; + +TRACE ("Entered squashfs_symlink_readpage, page index %d, start block %x, offset %x\n" , + page->index, sqi->start_block, sqi->offset); + +while (length < index) { +char buffer[PAGE_CACHE_SIZE ];
Hmm, isn't that 4K allocated on the stack? Ouch.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"DD" == David Dillow <[email protected]> writes:
Quoted 3 lines · DD> On Sat, 2003-07-19 at 18:59, [email protected] wrote:
fs/squashfs/inode.c line 640
Quoted 3 lines
...
fs/squashfs/inode.c +2
-0+while (length < index) { +char buffer[PAGE_CACHE_SIZE ];
DD> Hmm, isn't that 4K allocated on the stack? Ouch.
Ouch indeed. I was not looking for these things (I was just porting not fixing). Thank you for pointing it out. Have a couple of questions:
- Would it be an acceptable alternative here to use blocking kmalloc upon entry with matching kfree before leaving?
- I would imagine that the acceptable stack usage for functions would depend on where they are called and what they call. Coulc you suggest a rule-of-thumb number for address_space_operations.readpage (say, would 1kB be OK but not 3kB?)
- Would the same rule apply to 2.4 filesystem layer?
Quoted 8 lines · On Sat, 19 July 2003 22:40:22 -0700, [email protected] wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"DD" == David Dillow <[email protected]> writes:
DD> Hmm, isn't that 4K allocated on the stack? Ouch.
Ouch indeed. I was not looking for these things (I was just porting not fixing). Thank you for pointing it out. Have a couple of questions:
Quoted 8 lines
- Would it be an acceptable alternative here to use blocking kmalloc upon entry with matching kfree before leaving?
- I would imagine that the acceptable stack usage for functions would depend on where they are called and what they call. Coulc you suggest a rule-of-thumb number for address_space_operations.readpage (say, would 1kB be OK but not 3kB?)
As a rule of thumb, stay below 1k or you will get regular email from me. :)
Depending on where and what you do, a bit more could be ok, but this is hard to prove and also depends a bit on the architecture. s390 has giant stacks because function call overhead is huge, i386 will likely halve the kernel stack sometime during 2.7 and there is no point is hiding more easter eggs now - there is enough hidden already.
Jörn
Signature · 2 lines
"Security vulnerabilities are here to stay." -- Scott Culp, Manager of the Microsoft Security Response Center, 2001
Quoted 9 lines · [email protected] wrote:
Quoted 8 lines · On Sat, 19 July 2003 22:40:22 -0700, [email protected] wrote:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"DD" == David Dillow <[email protected]> writes:
DD> Hmm, isn't that 4K allocated on the stack? Ouch.
Ouch indeed. I was not looking for these things (I was just porting not fixing). Thank you for pointing it out. Have a couple of questions:
Thanks for sending the 2.6 patch, due to work pressure, I have had very little time to do these things recently. I am still, however, actively developing squashfs (a 1.3 with some improvements will be released soon), and I'd prefer to do code fixes myself.
Quoted 11 lines
Quoted 8 lines
- Would it be an acceptable alternative here to use blocking kmalloc upon entry with matching kfree before leaving?
- I would imagine that the acceptable stack usage for functions would depend on where they are called and what they call. Coulc you suggest a rule-of-thumb number for address_space_operations.readpage (say, would 1kB be OK but not 3kB?)
As a rule of thumb, stay below 1k or you will get regular email from me. :)
I tend to allocate (small) buffers on the stack, when their size does not seem to warrant either: a globally kmalloced buffer and consequent locking, or a locally kmalloced buffer kfreed on exit from the function, which seems wasteful. However, if 1K is the perceived wisdom on stack limits, then I will alter the code.
Phillip
Quoted 10 lines · On Sun, 20 July 2003 11:16:18 +0100, [email protected] wrote:
Quoted 3 lines · [email protected] wrote:
As a rule of thumb, stay below 1k or you will get regular email from me. :)
I tend to allocate (small) buffers on the stack, when their size does not seem to warrant either: a globally kmalloced buffer and consequent locking, or a locally kmalloced buffer kfreed on exit from the function, which seems wasteful. However, if 1K is the perceived wisdom on stack limits, then I will alter the code.
At least you should think twice before going above. Even with wli's stack reduction work applied, you still have close to 4k for kernel stack. But measuring the stack consumption of all the possible call chains in the kernel is still a hard problem, so you will have a hard time proving that any one bigger stack allocation is fine.
Jörn
Signature · 3 lines
When people work hard for you for a pat on the back, you've got to give them that pat. -- Robert Heinlein
fs/Kconfig line 1123
Quoted 7 lines · In article <[email protected]> you wrote:
fs/Kconfig +7
-0+config SQUASHFS + tristate "SquashFs file system support" + help + Saying Y here includes support for SquashFs. + + If unsure, say N. +
This is not a useful help.
Quoted 1 line
+ * Squashfs - a compressed read only filesystem for Linux
Please at least add this single sentence.
Greetings
Bernd
Signature · 2 lines
eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/