linux-kernel - Re: [PATCH 0/3] ARM 4Kstacks: introduction

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 19 Oct 2011 15:54:18 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Tim Bird <tim.bird@...sony.com>
Cc:	Joe Perches <joe@...ches.com>, Russell King <rmk@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Arnd Bergmann <arnd@...db.de>,
	Andi Kleen <andi@...stfloor.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] ARM 4Kstacks: introduction

On Tue, Oct 18, 2011 at 05:26:44PM -0700, Tim Bird wrote:
> On 10/18/2011 05:14 PM, Joe Perches wrote:
> > On Tue, 2011-10-18 at 16:27 -0700, Tim Bird wrote:
> >> I'm about to submit a set of patches (really pretty small)
> >> to add 4K stack support to ARM (defaulted to 'N').
> > 
> > When 4k stacks went away, I thought it safe enough
> > to submit vsnprintf recursion using %pV.
> > 
> > I believe the current vsnprintf max recursion is 3.
> > Each recursion uses at least 300 bytes of stack.
> > 
> > That might be some additional issue for 4k stacks.
> 
> Interesting.  Thanks very much for the heads up.
> I don't know how prevalent %pV is, but I'll take a
> look tomorrow and see if I think this would be an
> issue.  One option would be to turn off recursion
> in the 4K stacks case (but I don't know how badly
> this would mangle the code).

Badly.

For example, every single message emitted by XFS uses %pV to add
consistent message prefixes to the messages. See __xfs_printk().

And a quick grep shows this same technique is used in ext3, ext4,
NILFS, FAT and other filesystems, as well as netdev_printk,
dev_printk, the libata code and more. IOWs, you'd basically break
messages from most subsystems and drivers in the kernel...

> I'm not sure I'm willing to advocate eliminating
> all occurrences of high stack usage in the kernel.
> It seems like this would generate a lot of friction
> for getting this mainlined.  As long as I can document
> the trouble that people might get in when they
> turn this on, I think that would be very good.

"You can't use block based storage because the storage stack doesn't
fit in 4k."

> Even inside Sony, usage of 4K stacks is limited
> to some very special cases, where memory is exceedingly
> tight (we have one system with 4M of RAM).  And we
> don't mind lopping off features or coding around
> problem areas to support our special case.

Sounds to me like it's less overhead simply to maintain the patches
for the systems that need it than it is to put it in mainline,
document all the stuff that doesn't work and then, of course, have
to triage all the problems people report because they haven't read
the documentation.... :/

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/