linux-kernel - Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068 trace_hardirqs_on

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:	Mon, 21 Jul 2008 09:17:21 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	Vegard Nossum <vegard.nossum@...il.com>, Greg KH <gregkh@...e.de>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	kernel-testers@...r.kernel.org, linux-next@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Bernhard Walle <bwalle@...e.de>, Ingo Molnar <mingo@...e.hu>,
	kexec <kexec@...ts.infradead.org>
Subject: Re: linux-next: Tree for July 18: warning at kernel/lockdep.c:2068
	trace_hardirqs_on_caller

On Sun, Jul 20, 2008 at 02:01:02AM -0700, Dave Hansen wrote:
> On Sun, 2008-07-20 at 01:11 +0200, Vegard Nossum wrote:
> > Maybe the firmware memmap code can simply run a little later in the
> > boot sequence?
> 
> Heh, I'm catching up on this thread...
> 
> It is possible that it could run later.  But, I do know that there are
> at least a couple of these tables (on various arches) that we toss out
> of memory or become unavailable later in boot.  
> 
> I do this this:
> 
>     sysfs: add /sys/firmware/memmap
> 
> is really being done at the wrong level.  I don't, for instance, see
> *any* reference to memory hotplug in these patches.  That's because
> they're done against firmware structures, and memory hotplug doesn't
> update firmware structures on the two architectures that I can remember
> (ppc64 and x86).
> 
> In other words, kexec using this probably won't work on a memory hotplug
> machine.

If memory is just being added and not being removed then kexec will
continue to work. Just that newly added memory will not be visible to
second kernel. (Unless we start modifying /sys/firmware/memmap upon 
memory hotplug event).

Is /proc/iomem updated upon memory hotplug event. All these years, kexec
has been using that interace.

> 
> Secondly, why don't we just modify the
> existing /sys/devices/system/memory things to properly export what exec
> needs?  They're already cross-platform *and* they're updated with memory
> hotplug events.  

As bernhard mentioned that above interface has got long dependeny list
and will not work for kexec until and unless we get rid of those 
dependencies.

What does /sys/devices/system/memory represent? All the physical memory
present in the system or all the physical memory being used by kernel
(for example, memory limited by command line options mem=).

If it represents all the physical memory present in the system then it
might make sense to not create another interface but to use this one for
kexec. (But we shall have to get rid of long list of dependencies so that
it can gel wil more universal appeal of kexec).

Do you think that we can decouple /sys/devices/system/memory interface with
CONFIG_MEMORY_HOTPLUG?

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