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: <20121206093019.GA4584@dhcp-192-168-178-175.profitbricks.localdomain> Date: Thu, 6 Dec 2012 10:30:19 +0100 From: Vasilis Liaskovitis <vasilis.liaskovitis@...fitbricks.com> To: Toshi Kani <toshi.kani@...com> Cc: "Rafael J. Wysocki" <rjw@...k.pl>, linux-acpi@...r.kernel.org, Wen Congyang <wency@...fujitsu.com>, Wen Congyang <wencongyang@...il.com>, isimatu.yasuaki@...fujitsu.com, lenb@...nel.org, gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org Subject: Re: [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario Hi, On Thu, Nov 29, 2012 at 10:44:11AM -0700, Toshi Kani wrote: > On Thu, 2012-11-29 at 12:04 +0100, Vasilis Liaskovitis wrote: > > Yes, that's what I had in mind along with device_lock(). I think the > lock is necessary to close the window. > http://www.spinics.net/lists/linux-mm/msg46973.html > > But as I mentioned in other email, I prefer option 3 with > suppress_bind_attrs. So, yes, please take a look to see how it works > out. I tested the suppress_bind_attrs and it works by simply setting it to true before driver registration e.g. --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -783,7 +783,8 @@ int acpi_bus_register_driver(struct acpi_driver *driver) driver->drv.name = driver->name; driver->drv.bus = &acpi_bus_type; driver->drv.owner = driver->owner; - + if (!strcmp(driver->class, "memory")) + driver->drv.suppress_bind_attrs = true; ret = driver_register(&driver->drv); return ret; } No bind/unbind sysfs files are created when using this, as expected. I assume we only want to suppress for acpi_memhotplug (class=ACPI_MEMORY_DEVICE_CLASS i.e. "memory") devices. Is there agreement on what acpi_bus_trim behaviour and rollback (if any) we want to have for the current ACPI framework (partial trim or full trim on failure)? thanks, - Vasilis -- 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