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
| ||
|
Message-ID: <CAPcyv4jrxMNEEeUZZG3=CdkYSyX7OtJLv_ZQ1gbML7bscePiQA@mail.gmail.com> Date: Sat, 20 Apr 2019 09:36:42 -0700 From: Dan Williams <dan.j.williams@...el.com> To: Pavel Tatashin <pasha.tatashin@...een.com> Cc: James Morris <jmorris@...ei.org>, Sasha Levin <sashal@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux MM <linux-mm@...ck.org>, linux-nvdimm <linux-nvdimm@...ts.01.org>, Andrew Morton <akpm@...ux-foundation.org>, Michal Hocko <mhocko@...e.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Keith Busch <keith.busch@...el.com>, Vishal L Verma <vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, Ross Zwisler <zwisler@...nel.org>, Tom Lendacky <thomas.lendacky@....com>, "Huang, Ying" <ying.huang@...el.com>, Fengguang Wu <fengguang.wu@...el.com>, Borislav Petkov <bp@...e.de>, Bjorn Helgaas <bhelgaas@...gle.com>, Yaowei Bai <baiyaowei@...s.chinamobile.com>, Takashi Iwai <tiwai@...e.de>, Jérôme Glisse <jglisse@...hat.com> Subject: Re: [v1 2/2] device-dax: "Hotremove" persistent memory that is used like normal RAM On Sat, Apr 20, 2019 at 9:30 AM Pavel Tatashin <pasha.tatashin@...een.com> wrote: > > > > + > > > + /* Walk and offline every singe memory_block of the dax region. */ > > > + lock_device_hotplug(); > > > + rc = walk_memory_range(start_pfn, end_pfn, dev, offline_memblock_cb); > > > + unlock_device_hotplug(); > > > + if (rc) > > > + return rc; > > > > This potential early return is the reason why memory hotremove is not > > reliable vs the driver-core. If this walk fails to offline the memory > > it will still be online, but the driver-core has no consideration for > > device-unbind failing. The ubind will proceed while the memory stays > > pinned. > > Hi Dan, > > Thank you for looking at this. Are you saying, that if drv.remove() > returns a failure it is simply ignored, and unbind proceeds? Yeah, that's the problem. I've looked at making unbind able to fail, but that can lead to general bad behavior in device-drivers. I.e. why spend time unwinding allocated resources when the driver can simply fail unbind? About the best a driver can do is make unbind wait on some event, but any return results in device-unbind.
Powered by blists - more mailing lists