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: <4A4B24280200007800008618@vpn.id2.novell.com>
Date:	Wed, 01 Jul 2009 07:54:00 +0100
From:	"Jan Beulich" <JBeulich@...ell.com>
To:	"Rusty Russell" <rusty@...tcorp.com.au>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] replace various uses of num_physpages by
	 totalram_pages

>>> Rusty Russell <rusty@...tcorp.com.au> 01.07.09 06:57 >>>
>On Tue, 30 Jun 2009 08:38:32 pm Jan Beulich wrote:
>> Sizing of memory allocations shouldn't depend on the number of physical
>> pages found in a system, as that generally include (perhaps a huge
>> amount of) non-RAM pages. The amount of what actually is usable as
>> storage should instead be used as a basis here.
>
>I like this patch.  Where's num_physpages used after this: should it be an 
>arch-specific or even a static?

It's still being used for some hash value initialization in under net/, and in
the generic power management code (kernel/power/). While the earlier
part certainly looks replaceable, I'm not certain about the latter.

In any case it would seem like a first step might now be to no longer export
the symbol (or, for a transitional period, make it an unused export).

Once all uses are gone, making it arch specific (reducing its scope as much
as possible, up to complete elimination) would certainly seem desirable
(not the least to perhaps finally address comments like "How many end-
of-memory variables you have, grandma!").

Jan

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