lkml.org 
[lkml]   [2010]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC][PATCH] ACPI: Eliminate race conditions related to removing event handlers
    Date
    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


    \
     
     \ /
      Last update: 2010-02-24 21:25    [W:2.465 / U:1.800 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site