[PATCH] FUSE depends on BLOCK
From: Randy Dunlap <[EMAIL PROTECTED]> Should FUSE depend on BLOCK? Without that and with BLOCK=n, I get: inode.c:(.text+0x3acc5): undefined reference to `sb_set_blocksize' inode.c:(.text+0x3a393): undefined reference to `get_sb_bdev' fs/built-in.o:(.data+0xd718): undefined reference to `kill_block_super Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- fs/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2619-rc5mm2.orig/fs/Kconfig +++ linux-2619-rc5mm2/fs/Kconfig @@ -622,6 +622,7 @@ config AUTOFS4_FS config FUSE_FS tristate "Filesystem in Userspace support" + depends on BLOCK help With FUSE it is possible to implement a fully functional filesystem in a userspace program. --- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -mm] cachefiles uses PROC_FS
From: Randy Dunlap <[EMAIL PROTECTED]> CACHEFILES uses PROC_FS, so make it a Kconfig depends. fs/cachefiles/cf-main.c:77: error: 'proc_root_fs' undeclared (first use in this function) Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- fs/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-2619-rc5mm2.orig/fs/Kconfig +++ linux-2619-rc5mm2/fs/Kconfig @@ -655,6 +655,7 @@ config FSCACHE config CACHEFILES tristate "Filesystem caching on files" + depends on PROC_FS select FSCACHE help This permits use of a mounted filesystem as a cache for other --- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ext3: htree entry integrity checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Dilger wrote: > On Nov 16, 2006 11:50 -0500, Jeff Mahoney wrote: >> Currently, if a corrupted directory entry with rec_len=0 is encountered, >> we still trust that the data is valid. This can cause an infinite loop >> in htree_dirblock_to_tree() since the iteration loop will never make any >> progress. > > Actually, I think Eric Sandeen was working on similar fixes already, and > instead of doing a per-item check each time we look at the entry it does > a full-block check the first time it is read (as ext2 does). > >> This fixes the problem described at: >> http://projects.info-pull.com/mokb/MOKB-10-11-2006.html > > Would also be good to CC linux-ext4, where the ext3 maintainers live. Ok, thanks. If that's already in -mm, I'll use that one. - -Jeff - -- Jeff Mahoney SUSE Labs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFXQIwLPWxlyuTD7IRApH7AJ9+/SFmd9bf8E741wvxw/6vdrUrdwCeJNEG eHZMo5RWUrLW5iDEqehjRlI= =lGRM -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ext3: htree entry integrity checking
Andreas Dilger wrote: > On Nov 16, 2006 11:50 -0500, Jeff Mahoney wrote: >> Currently, if a corrupted directory entry with rec_len=0 is encountered, >> we still trust that the data is valid. This can cause an infinite loop >> in htree_dirblock_to_tree() since the iteration loop will never make any >> progress. > > Actually, I think Eric Sandeen was working on similar fixes already, and > instead of doing a per-item check each time we look at the entry it does > a full-block check the first time it is read (as ext2 does). > >> This fixes the problem described at: >> http://projects.info-pull.com/mokb/MOKB-10-11-2006.html > > Would also be good to CC linux-ext4, where the ext3 maintainers live. > Hmm, maybe we need to update MAINTAINERS with the new list address? This should already be fixed, in some fashion, in -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc5/2.6.19-rc5-mm2/broken-out/handle-ext3-directory-corruption-better.patch I have been looking at doing a check only when the block is first read, but other things have come up & taken some time, and that is a bit on the back burner now... -Eric - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ext3: htree entry integrity checking
On Nov 16, 2006 11:50 -0500, Jeff Mahoney wrote: > Currently, if a corrupted directory entry with rec_len=0 is encountered, > we still trust that the data is valid. This can cause an infinite loop > in htree_dirblock_to_tree() since the iteration loop will never make any > progress. Actually, I think Eric Sandeen was working on similar fixes already, and instead of doing a per-item check each time we look at the entry it does a full-block check the first time it is read (as ext2 does). > This fixes the problem described at: > http://projects.info-pull.com/mokb/MOKB-10-11-2006.html Would also be good to CC linux-ext4, where the ext3 maintainers live. Hmm, maybe we need to update MAINTAINERS with the new list address? Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CVE-2006-3468
Matthew Wilcox wrote: >> On Thu, Nov 16, 2006 at 10:21:32PM +0100, Majkls wrote: >> > Hello, I would like to solve this bug. Have anybody some backtrace or some working exploit? > >> >> >> Sure you have the right CVE? That bug seems to have been fixed long >> ago: >> >> http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=2ccb48ebb4de139eef4fcefd5f2bb823cb0d81b9 Thanks. I did not know about it. So there is a question. How are the advisories on secunia updated. They are still reporting that this bug is not fixed. http://secunia.com/advisories/21369/ >> - >> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in >> the body of a message to [EMAIL PROTECTED] >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- Miloslav "Majkls" Semler - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: CVE-2006-3468
On Thu, Nov 16, 2006 at 10:21:32PM +0100, Majkls wrote: > Hello, > I would like to solve this bug. Have anybody some backtrace or some > working exploit? Sure you have the right CVE? That bug seems to have been fixed long ago: http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=2ccb48ebb4de139eef4fcefd5f2bb823cb0d81b9 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
CVE-2006-3468
Hello, I would like to solve this bug. Have anybody some backtrace or some working exploit? -- Miloslav "Majkls" Semler - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ext3: htree entry integrity checking
This patch adds integrity checking to two htree paths that are missing it.
Currently, if a corrupted directory entry with rec_len=0 is encountered,
we still trust that the data is valid. This can cause an infinite loop
in htree_dirblock_to_tree() since the iteration loop will never make any
progress.
I initially had written a ext3_check_htree_entry(), but saw that
ext3_dir_entry_2 is used for both htree and regular directory entries. Since
ext3_check_dir_entry() is used for checking ext3_dir_entry_2, I used that.
Can someone confirm that this is correct? There are other places where
de->rec_len == 0 is used by itself and I'd be fine doing that too, but I
figure more integrity checking isn't a bad thing.
This fixes the problem described at:
http://projects.info-pull.com/mokb/MOKB-10-11-2006.html
Signed-off-by: Jeff Mahoney <[EMAIL PROTECTED]>
diff -ruNpX ../dontdiff linux-2.6.18.orig/fs/ext3/namei.c
linux-2.6.18.orig.devel/fs/ext3/namei.c
--- linux-2.6.18.orig/fs/ext3/namei.c 2006-11-09 00:06:37.0 -0500
+++ linux-2.6.18.orig.devel/fs/ext3/namei.c 2006-11-12 20:15:19.0
-0500
@@ -551,6 +551,11 @@ static int htree_dirblock_to_tree(struct
dir->i_sb->s_blocksize -
EXT3_DIR_REC_LEN(0));
for (; de < top; de = ext3_next_entry(de)) {
+ if (!ext3_check_dir_entry(__FUNCTION__, dir, de, bh,
+ (char *)de - bh->b_data)) {
+ brelse(bh);
+ return ERR_BAD_DX_DIR;
+ }
ext3fs_dirhash(de->name, de->name_len, hinfo);
if ((hinfo->hash < start_hash) ||
((hinfo->hash == start_hash) &&
@@ -617,6 +622,11 @@ int ext3_htree_fill_tree(struct file *di
if (start_hash < 2 || (start_hash ==2 && start_minor_hash==0)) {
de = (struct ext3_dir_entry_2 *) frames[0].bh->b_data;
de = ext3_next_entry(de);
+ if (!ext3_check_dir_entry(__FUNCTION__, dir, de, frames[0].bh,
+ (char *)de - frames[0].bh->b_data)) {
+ err = ERR_BAD_DX_DIR;
+ goto errout;
+ }
if ((err = ext3_htree_store_dirent(dir_file, 2, 0, de)) != 0)
goto errout;
count++;
--
Jeff Mahoney
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
On Thu, 2006-11-16 at 14:06 +, Al Viro wrote:
> On Wed, Nov 15, 2006 at 11:42:38AM -0500, Jeff Layton wrote:
> > +{
> > + int rv;
> > +
> > + rv = idr_pre_get(&inode->i_sb->s_inode_ids, GFP_KERNEL);
> > + if (! rv)
> > + return -ENOMEM;
> > +
> > + lock_super(inode->i_sb);
>
> [EMAIL PROTECTED]
>
> Please, use something saner. Use of lock_super() for anything generic
> is wrong; using it for something that'd better be fast is even dumber...
>
Well, I considered the inode_lock here, but since all of this stuff is
per-sb, I thought s_lock would be a better choice. If that's not
suitable, what do you suggest? A new spinlock to protect the new sb
fields?
> > @@ -1025,6 +1055,7 @@ void generic_delete_inode(struct inode *
> > spin_lock(&inode_lock);
> > hlist_del_init(&inode->i_hash);
> > spin_unlock(&inode_lock);
> > + iunique_unregister(inode);
>
> Unconditional? Hitting every fs out there? With that kind of locking?
>
I'm not sure what condition I would base this on. That said, I don't
think the impact would be too bad here though. Presumably, those
filesystems that don't use iunique_register will have empty idr hashes
and would return quickly.
>
> > if (inode->i_data.nrpages)
> > truncate_inode_pages(&inode->i_data, 0);
> > clear_inode(inode);
> > diff --git a/fs/pipe.c b/fs/pipe.c
> > index b1626f2..d74ae65 100644
> > --- a/fs/pipe.c
> > +++ b/fs/pipe.c
> > @@ -845,6 +845,9 @@ static struct inode * get_pipe_inode(voi
> > if (!inode)
> > goto fail_inode;
> >
> > + if (iunique_register(inode, 0))
> > + goto fail_iput;
> > +
>
> Humm... I wonder what the overhead of that is going to be. There
> easily can be shitloads of pipes on the box, with all sorts of
> lifetimes. And we'd better be fast on that codepath...
IDR is supposedly quick for this sort of thing though I don't have any
numbers as of yet. Still, getting i_ino uniqueness isn't going to come
for free. There will be some performance impact regardless of what
scheme we use.
-- Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr)
On Wed, Nov 15, 2006 at 11:42:38AM -0500, Jeff Layton wrote:
> +{
> + int rv;
> +
> + rv = idr_pre_get(&inode->i_sb->s_inode_ids, GFP_KERNEL);
> + if (! rv)
> + return -ENOMEM;
> +
> + lock_super(inode->i_sb);
[EMAIL PROTECTED]
Please, use something saner. Use of lock_super() for anything generic
is wrong; using it for something that'd better be fast is even dumber...
> @@ -1025,6 +1055,7 @@ void generic_delete_inode(struct inode *
> spin_lock(&inode_lock);
> hlist_del_init(&inode->i_hash);
> spin_unlock(&inode_lock);
> + iunique_unregister(inode);
Unconditional? Hitting every fs out there? With that kind of locking?
> wake_up_inode(inode);
> BUG_ON(inode->i_state != I_CLEAR);
> destroy_inode(inode);
> @@ -1057,6 +1088,7 @@ static void generic_forget_inode(struct
> inode->i_state |= I_FREEING;
> inodes_stat.nr_inodes--;
> spin_unlock(&inode_lock);
> + iunique_unregister(inode);
Ditto.
> if (inode->i_data.nrpages)
> truncate_inode_pages(&inode->i_data, 0);
> clear_inode(inode);
> diff --git a/fs/pipe.c b/fs/pipe.c
> index b1626f2..d74ae65 100644
> --- a/fs/pipe.c
> +++ b/fs/pipe.c
> @@ -845,6 +845,9 @@ static struct inode * get_pipe_inode(voi
> if (!inode)
> goto fail_inode;
>
> + if (iunique_register(inode, 0))
> + goto fail_iput;
> +
Humm... I wonder what the overhead of that is going to be. There
easily can be shitloads of pipes on the box, with all sorts of
lifetimes. And we'd better be fast on that codepath...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
