linux-kernel - Re: Cannot hot remove a memory device

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: <2124016.41i4c3lbD4@vostro.rjw.lan>
Date:	Sat, 03 Aug 2013 01:43:31 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Toshi Kani <toshi.kani@...com>
Cc:	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	rafael.j.wysocki@...el.com, vasilis.liaskovitis@...fitbricks.com,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	tangchen@...fujitsu.com, wency@...fujitsu.com
Subject: Re: Cannot hot remove a memory device

On Friday, August 02, 2013 03:46:15 PM Toshi Kani wrote:
> On Thu, 2013-08-01 at 23:43 +0200, Rafael J. Wysocki wrote:
> > Hi,
> > 
> > Thanks for your report.
> > 
> > On Thursday, August 01, 2013 05:37:21 PM Yasuaki Ishimatsu wrote:
> > > By following commit, I cannot hot remove a memory device.
> > > 
> > > ACPI / memhotplug: Bind removable memory blocks to ACPI device nodes
> > > commit e2ff39400d81233374e780b133496a2296643d7d
> > > 
> > > Details are follows:
> > > When I add a memory device, acpi_memory_enable_device() always fails
> > > as follows:
> > > 
> > > ...
> > > [ 1271.114116]  [ffffea121c400000-ffffea121c7fffff] PMD -> [ffff880813c00000-ffff880813ffffff] on node 3
> > > [ 1271.128682]  [ffffea121c800000-ffffea121cbfffff] PMD -> [ffff880813800000-ffff880813bfffff] on node 3
> > > [ 1271.143298]  [ffffea121cc00000-ffffea121cffffff] PMD -> [ffff880813000000-ffff8808133fffff] on node 3
> > > [ 1271.157799]  [ffffea121d000000-ffffea121d3fffff] PMD -> [ffff880812c00000-ffff880812ffffff] on node 3
> > > [ 1271.172341]  [ffffea121d400000-ffffea121d7fffff] PMD -> [ffff880812800000-ffff880812bfffff] on node 3
> > > [ 1271.186872]  [ffffea121d800000-ffffea121dbfffff] PMD -> [ffff880812400000-ffff8808127fffff] on node 3
> > > [ 1271.201481]  [ffffea121dc00000-ffffea121dffffff] PMD -> [ffff880812000000-ffff8808123fffff] on node 3
> > > [ 1271.216041]  [ffffea121e000000-ffffea121e3fffff] PMD -> [ffff880811c00000-ffff880811ffffff] on node 3
> > > [ 1271.230623]  [ffffea121e400000-ffffea121e7fffff] PMD -> [ffff880811800000-ffff880811bfffff] on node 3
> > > [ 1271.245148]  [ffffea121e800000-ffffea121ebfffff] PMD -> [ffff880811400000-ffff8808117fffff] on node 3
> > > [ 1271.259683]  [ffffea121ec00000-ffffea121effffff] PMD -> [ffff880811000000-ffff8808113fffff] on node 3
> > > [ 1271.274194]  [ffffea121f000000-ffffea121f3fffff] PMD -> [ffff880810c00000-ffff880810ffffff] on node 3
> > > [ 1271.288764]  [ffffea121f400000-ffffea121f7fffff] PMD -> [ffff880810800000-ffff880810bfffff] on node 3
> 
> It appears that each memory object only has 64MB of memory.  This is
> less than the memory block size, which is 128MB.  This means that a
> single memory block associates with two ACPI memory device objects.

That'd be bad.

How did that work before if that indeed is the case?

> > > ...	
> > > [ 1271.325841] acpi PNP0C80:03: acpi_memory_enable_device() error
> > 
> > Well, the only new way acpi_memory_enable_device() can fail after that commit
> > is a failure in acpi_bind_memory_blocks().
> 
> Agreed.
> 
> > This means that either handle is NULL, which I think we can exclude, because
> > acpi_memory_enable_device() wouldn't be called at all if that were the case, or
> > there's a more subtle error in acpi_bind_one().
> > 
> > One that comes to mind is that we may be calling acpi_bind_one() twice for the
> > same memory region, in which it will trigger -EINVAL from the sanity check in
> > there.
> 
> I think it fails with -EINVAL at the place with dev_warn(dev, "ACPI
> handle is already set\n").  When two ACPI memory objects associate with
> a same memory block, the bind procedure of the 2nd ACPI memory object
> sees that ACPI_HANDLE(dev) is already set to the 1st ACPI memory object.

That sound's plausible, but I wonder how we can fix that?

There's no way for a single physical device to have two different ACPI
"companions".  It looks like the memory blocks should be 64 M each in that
case.  Or we need to create two child devices for each memory block and
associate each of them with an ACPI object.  That would lead to complications
in the user space interface, though.

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/