linux-kernel - Re: [PATCH](memory hotplug) Repost remove useless message at boot time from 2.6.18-rc4.

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: <20060829102200.FC1D.Y-GOTO@jp.fujitsu.com>
Date:	Tue, 29 Aug 2006 10:57:23 +0900
From:	Yasunori Goto <y-goto@...fujitsu.com>
To:	mail@...ninger.de
Cc:	Thomas Renninger <trenn@...e.de>, akpm@...l.org,
	"Brown, Len" <len.brown@...el.com>,
	keith mannthey <kmannth@...ibm.com>,
	ACPI-ML <linux-acpi@...r.kernel.org>,
	Linux Kernel ML <linux-kernel@...r.kernel.org>,
	Linux Hotplug Memory Support 
	<lhms-devel@...ts.sourceforge.net>, naveen.b.s@...el.com
Subject: Re: [PATCH](memory hotplug) Repost remove useless message at boot time from 2.6.18-rc4.

> > Old code registers handler for all of memory devices even if it is not
> > enabled.
> Yeah, therefore the mem_device cannot be passed as callback data as it
> might get generated in the notify handler func and all the additional
> stuff is needed..., ouch.
> > 
> > If my understanding is wrong, please let me know. ;-)
> It's me who is wrong, thanks a lot for checking!
> 
> > Memory device might not have _EJ0/_EJD, but parent device 
> > (like one NUMA node) might be able to be ejectable.
> > In this case, only the parent device has _EJ0/_EJD.
> > So, one more check is necessary.
> 
> I feared something like that (should have add a comment...), as the EJ0
> and _STA functions are only used on the device itself I thought checking
> for them makes sense, but for a missing EJ0 func powering down the
> device just fails and it should not be harmful.
> So the only useful thing from my patch (as long as .add is only invoked
> if device is present) is using the general acpi_bus_get_status() func. 
> Hmm, it must be used if the _STA function on the memory device is also
> missing and the parent _STA must be used then? Could make sense on a
> machine where a whole node must be inserted/ejected? The
> acpi_bus_get_status() function already contains the checking for the
> parent's _STA function and uses this one if the device itself has none.

I don't have any report like "no _STA on memory device" so far.
Current code assume each memory device has _STA.
I suppose each memory device should have _STA method. For example,
if a memory device is broken, its _STA should return disable status. 
So, basically checking _STA of only memory device should be ok now.

However I'm not sure that every vendor will do it in the future.
If there is no _STA on memory device, parents, grand-parents or
more ancestor might have _STA for it.
(See acpi_get_pxm() in driver/acpi/numa.c. It searches ancestor's _PXM.
 If insane vendor make like it, it will be good reference.)

Bye.
-- 
Yasunori Goto 


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