linux-kernel - Re: [GIT PULL] SLAB include file dependency fixes + kmemtrace updates

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090407053039.GA22854@localhost>
Date:	Tue, 7 Apr 2009 13:30:39 +0800
From:	Wu Fengguang <fengguang.wu@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Avan Anishchuk <matimatik@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
Subject: Re: [GIT PULL] SLAB include file dependency fixes + kmemtrace
	updates

On Tue, Apr 07, 2009 at 12:45:37PM +0800, Linus Torvalds wrote:
> 
> 
> On Mon, 6 Apr 2009, Linus Torvalds wrote:
> > 
> > It bisected past them. I'm getting worried that it's timing-related, 
> > because nothing that remains looks even remotely interesting for that Mac 
> > mini, but right now:
> > 
> >  - bad: 56fcef75117a153f298b3fe54af31053f53997dd
> >  - good: bb233fdfc7b7cefe45bfa2e8d1b24e79c60a48e5
> > 
> > and there's not a whole lot of commits in between.
> 
> It's c3b1b1cbf002e65a3cabd479e68b5f35886a26db: 'ramfs: add support for 
> "mode=" mount option'.
> 
> And I checked. Reverting it at the tip fixes it. So no random timing 
> fluctuations.
> 
> So that commit causes some random SLAB corruption, that then (depending 
> apparently on luck) may or may not crash in some odd random places later.
> 
> Wu?

Maybe this bug?

Thanks,
Fengguang
---
ramfs: fix double freeing s_fs_info

On a failed ramfs mount, s_fs_info will be freed twice in ramfs_fill_super()
and ramfs_kill_sb(). Fix it by saving s_fs_info only on success.

Signed-off-by: Wu Fengguang <fengguang.wu@...el.com>
---
diff --git a/fs/ramfs/inode.c b/fs/ramfs/inode.c
index a404fb8..7dbb433 100644
--- a/fs/ramfs/inode.c
+++ b/fs/ramfs/inode.c
@@ -225,7 +225,6 @@ static int ramfs_fill_super(struct super_block * sb, void * data, int silent)
 		err = -ENOMEM;
 		goto fail;
 	}
-	sb->s_fs_info = fsi;
 
 	err = ramfs_parse_options(data, &fsi->mount_opts);
 	if (err)
@@ -249,6 +248,7 @@ static int ramfs_fill_super(struct super_block * sb, void * data, int silent)
 		goto fail;
 	}
 	sb->s_root = root;
+	sb->s_fs_info = fsi;
 	return 0;
 fail:
 	kfree(fsi);
--
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/