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:	Tue, 28 Jun 2011 09:38:44 -0700
From:	Sergiu Iordache <sergiu@...gle.com>
To:	Marco Stornelli <marco.stornelli@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"Ahmed S. Darwish" <darwish.07@...il.com>,
	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] char drivers: ramoops record_size module parameter

On Mon, Jun 27, 2011 at 11:39 PM, Marco Stornelli
<marco.stornelli@...il.com> wrote:
> Hi,
>
> 2011/6/28 Sergiu Iordache <sergiu@...omium.org>:
>> The size of the dump is currently set using the RECORD_SIZE macro which
>> is set to a page size. This patch makes the record size a module
>> parameter and allows it to be set through platform data as well to allow
>> larger dumps if needed.
>>
>> Change-Id: Ie6bd28a898dab476abf34decb0eecc42122f17ce
>> Signed-off-by: Sergiu Iordache <sergiu@...omium.org>
>> ---
>
> the idea can be valid, but you have to add some check to set the
> record size. It'd be better to add a lower and upper bound and to
> check for it's power of two.

That sounds like a good idea. Since the memory size gets rounded to a
power of two it would probably be more consistent to round down the
record size as well. This way you would be sure that mem_size is a
multiple of record size as well. The upper bound would be the memory
size, which is already checked. I'm not sure whether it would be a
good idea to add lower bound different from record_size != 0 (I don't
know why someone would need to dump 8 bytes for example but is there a
reason to limit it?)

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