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:	Tue, 3 Aug 2010 06:59:41 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Xiaotian Feng <dfeng@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Roland McGrath <roland@...hat.com>
Subject: Re: [RFC PATCH V2] core_pattern: fix long parameters was truncated
 by core_pattern handler

On Mon, Aug 02, 2010 at 03:50:13PM +0200, Oleg Nesterov wrote:
> 
> Also. Not sure this really makes sense, but if we ever need to expand the
> string, perhaps it makes sense to remeber this fact so that the next time
> we start with len > CORENAME_MAX_SIZE. In any case, I think this needs a
> separate patch.
> 
> Oleg.

Yes, this is what I alluded to in my initial reply.  We need to keep an atomic
value to track the maximum number of times we've called expand_corename to help
prevent us having to call it repeatedly on every crash.  Something like this:

expand_corename(**corename, **out_end, **out_ptr)
{
	...
	*corename = krealloc(*corename,
			     CORENAME_MAX_SIZE*
			     atomic_inc_return(call_count),
			     GFP_KERNEL);
	...
}


do_coredump(...)
{
	...
	corename = kmalloc(CORENAME_MAX_SIZE *
			   atomic_read(call_count),
			   GFP_KERNEL);
	...
}


That will train the path to allocate a sensible size after the first crash, and
avoid lots of calls to krealloc in the pessimal case

Neil

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ