linux-kernel - Re: [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario

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: <14429189.LmXxfguqbu@vostro.rjw.lan>
Date:	Thu, 06 Dec 2012 13:50:47 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Vasilis Liaskovitis <vasilis.liaskovitis@...fitbricks.com>
Cc:	Toshi Kani <toshi.kani@...com>, 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

On Thursday, December 06, 2012 10:30:19 AM Vasilis Liaskovitis wrote:
> 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)?

Last time I suggested to split the trimming so that first we only unbind
drivers (and roll back that part, ie. rebind the drivers on errors) and
next we remove the struct acpi_device objects, just before doing the actual
eject.  So there would be two walks of the hierarchy below the device we want
to eject, one for driver unbinding (that can be rolled back) and one for the
actual removal.

Toshi Kani seemed to agree with that and there were no follow-ups.

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/