linux-kernel - Re: + task_struct-make-journal_info-conditional.patch added to -mm tree

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]

Date:	Fri, 04 Dec 2009 09:31:06 +0000
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
	linux-kernel@...r.kernel.org, mm-commits@...r.kernel.org,
	chris.mason@...cle.com, konishi.ryusuke@....ntt.co.jp,
	tytso@....edu
Subject: Re: + task_struct-make-journal_info-conditional.patch added to -mm
 tree

Hi,

On Fri, 2009-12-04 at 08:17 +0300, Alexey Dobriyan wrote:
> On Fri, Dec 04, 2009 at 12:58:06PM +0900, Hiroshi Shimamoto wrote:
> > Alexey Dobriyan wrote:
> > > On Thu, Dec 03, 2009 at 02:40:57PM -0800, akpm@...ux-foundation.org wrote:
> > >> --- a/include/linux/sched.h~task_struct-make-journal_info-conditional
> > >> +++ a/include/linux/sched.h
> > >> @@ -1452,8 +1452,10 @@ struct task_struct {
> > >>  	gfp_t lockdep_reclaim_gfp;
> > >>  #endif
> > >>  
> > >> +#ifdef CONFIG_FS_JOURNAL_INFO
> > >>  /* journalling filesystem info */
> > >>  	void *journal_info;
> > >> +#endif
> > > 
> > > This will prevent using e.g. ext3 on CONFIG_EXT3_FS=n kernels.
> > 
> > I'm sorry, I'm not sure what you're mentioning.
> 
> With this patch admin must decide in advance if he will ever use ext3.
> EXT3_FS=n kernels won't be able to get ext3 support without reboot
> even as module, because task_struct will be different.
> 
> Which is a regression compared to current state.
> 
> The biggest example of such behaviour is ipv6 module, but it should not
> be spread more.

I agree. If we want to be rid of this then I think we should simply pass
the journal info as a parameter through the relevant filesystems (is
there any reason why we do things this way? I couldn't think of one) and
thus avoid the use of this field in the first place,

Steve.


--
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/