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:	Fri, 16 Nov 2012 01:40:56 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Toshi Kani <toshi.kani@...com>
Cc:	Wen Congyang <wency@...fujitsu.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linux-acpi@...r.kernel.org,
	Len Brown <len.brown@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Minchan Kim <minchan.kim@...il.com>,
	Mel Gorman <mgorman@...e.de>,
	David Rientjes <rientjes@...gle.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [Patch v5 0/7] acpi,memory-hotplug: implement framework for hot removing memory

On Friday, November 16, 2012 01:28:43 AM Rafael J. Wysocki wrote:
> On Thursday, November 15, 2012 02:59:30 PM Wen Congyang wrote:
> > The memory device can be removed by 2 ways:
> > 1. send eject request by SCI
> > 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
> > 
> > In the 1st case, acpi_memory_disable_device() will be called.
> > In the 2nd case, acpi_memory_device_remove() will be called.
> > acpi_memory_device_remove() will also be called when we unbind the
> > memory device from the driver acpi_memhotplug or a driver initialization
> > fails.
> > 
> > acpi_memory_disable_device() has already implemented a code which
> > offlines memory and releases acpi_memory_info struct . But
> > acpi_memory_device_remove() has not implemented it yet.
> > 
> > So the patch prepares the framework for hot removing memory and
> > adds the framework into acpi_memory_device_remove().
> > 
> > We may hotremove the memory device by this 2 ways at the same time.
> > So we remove the function acpi_memory_disable_device(), and use
> > acpi_bus_hot_remove_device() which is used by 2nd case to implement it.
> > We lock device in acpi_bus_hot_remove_device(), so there is no
> > need to add lock in acpi_memhotplug.
> > 
> > The last version of this patchset is here:
> > https://lkml.org/lkml/2012/11/8/121
> > 
> > Note:
> > 1. The following commit in pm tree can be dropped now(The other two patches
> >    are already dropped):
> >    54c4c7db6cb94d7d1217df6d7fca6847c61744ab
> > 2. This patchset requires the following patch(It is in pm tree now)
> >    https://lkml.org/lkml/2012/11/1/225
> > 
> > Changes from v4 to v5:
> > 1. patch2: new patch. use acpi_bus_hot_remove_device() to implement memory
> >    device hotremove.
> > 
> > Changes from v3 to v4:
> > 1. patch1: unlock list_lock when removing memory fails.
> > 2. patch2: just rebase them
> > 3. patch3-7: these patches are in -mm tree, and they conflict with this
> >    patchset, so Adrew Morton drop them from -mm tree. I rebase and merge
> >    them into this patchset.
> > 
> > Wen Congyang (6):
> >   acpi,memory-hotplug: deal with eject request in hotplug queue
> >   acpi_memhotplug.c: fix memory leak when memory device is unbound from
> >     the module acpi_memhotplug
> >   acpi_memhotplug.c: free memory device if acpi_memory_enable_device()
> >     failed
> >   acpi_memhotplug.c: don't allow to eject the memory device if it is
> >     being used
> >   acpi_memhotplug.c: bind the memory device when the driver is being
> >     loaded
> >   acpi_memhotplug.c: auto bind the memory device which is hotplugged
> >     before the driver is loaded
> > 
> > Yasuaki Ishimatsu (1):
> >   acpi,memory-hotplug : add memory offline code to
> >     acpi_memory_device_remove()
> 
> Well, I have tried _really_ hard to apply this patchset, but pretty much
> none of the patches except for [1/7] applied for me.  I have no idea what
> tree they are against, but I'm pretty sure it's not my tree.
> 
> I _have_ applied patches [1-4/7] and pushed them to linux-pm.git/linux-next.
> I needed to fix up almost all of them so that they applied, so please check
> if my fixups make sense (and let me know ASAP if that's not the case).
> 
> If they are OK, please rebase the rest of the series on top of
> linux-pm.git/linux-next and repost.  I'm not going to take any more
> patches that don't apply from you.
> 
> Moreover, I'm not going to take any more ACPI memory hotplug patches
> for v3.8 except for the [5-7/7] from this series (after they have been
> rebased and _if_ they apply), so please don't submit any until the v3.8
> merge window closes (of course, you're free to post RFCs, but I will
> ignore them).

And by the way, if someone gives a "Reviewed-by" to a patch that _obviously_
doesn't apply, I will ignore any "Reviewed-by" from that person going forward,
because that quite obviously means you haven't even compared the patch with the
existing code and thus your "review" is worthless.

If you just want to say you agree with the patch, use "Acked-by".

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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