linux-kernel - Re: [RFC][PATCH] ACPI: Eliminate race conditions related to removing event handlers

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] [day] [month] [year] [list]

Message-Id: <201002242122.20435.rjw@sisk.pl>
Date:	Wed, 24 Feb 2010 21:22:20 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Moore, Robert" <robert.moore@...el.com>
Cc:	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Lin, Ming M" <ming.m.lin@...el.com>
Subject: Re: [RFC][PATCH] ACPI: Eliminate race conditions related to removing event handlers

On Wednesday 24 February 2010, Moore, Robert wrote:
> 
> Rafael,
> 
> I've got some issues with this design.
> 
> First of all, are the two interfaces, acpi_remove_notify_handler() and
> acpi_remove_gpe_handler(), really being used in such a way to require such
> synchronization?

I had a problem with that when I was trying to implement adding more than one
system notify handler per device at the PCI level.  Specifically, I was trying
to create an extra layer of notify objects to be used by the PCI layer for
installing ACPI system notify handlers such that every PCI device had one
handler that might handle wakeup notifications as well as hotplug
notifications.  That didn't work, because I needed to remove a notify object
from memory after calling acpi_remove_notify_handler() for the handler
associated with it and I was unable to tell whether that was safe.

The patch at http://patchwork.kernel.org/patch/80104/ solved this issue for me
(BTW, you told me you'd have a look at this one :-)), but I think it generally
is good to know a handler is not being executed after
acpi_remove_notify_handler() or acpi_remove_gpe_handler() has been called
for it.

> Is there any way to limit their use to times where it is known that no
> handlers will be executing?

I don't think this is generally possible.  Since the event handlers are called
from a workqueue, we can't really guarantee any synchronization between them
and the other threads unless we use a mechanism that will enforce it.

> In addition, I'm afraid that this whole "events" mechanism, with an interface
> to wait for event completion, and now the concept of adding "barriers" to the
> event queue, is much too OS-specific for the core ACPICA code.

OK, I'm not going to insist.  However, I think that
acpi_os_wait_events_complete() should be called before we try to acquire
ACPI_MTX_EVENTS for the first time, because dropping it "temporarily" just in
order to call acpi_os_wait_events_complete() really defeats the purpose of the
locking.

Rafael
--
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/