Re: Notifier chains are unsafe

From: Keith Owens (kaos_at_ocs.com.au)
Date: 10/28/05

  • Next message: Jeff Garzik: "[git patches] 2.6.x libata updates"
    To: sekharan@us.ibm.com
    Date:	Fri, 28 Oct 2005 10:48:00 +1000
    
    

    On Thu, 27 Oct 2005 16:02:08 -0700,
    Chandra Seetharaman <sekharan@us.ibm.com> wrote:
    >On Thu, 2005-10-27 at 17:21 -0400, Alan Stern wrote:
    >> The other problem is that you violated Keith's statement that
    >> notifier_call_chain shouldn't take any locks. On the other hand, if we
    >
    >I would interpret Keith's comment like this: callout should not be
    >called with any locks held (because that would limit the callouts from
    >blocking).

    We should be able to call notifier_call_chain() from any context. That
    includes oops, panic, NMI and other unmaskable machine check events.
    If you can call notifier_call_chain() from an unmaskable context then
    it follows that the callbacks cannot take any locks. Locks are not
    safe in NMI context.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Jeff Garzik: "[git patches] 2.6.x libata updates"

    Relevant Pages

    • Re: a few usb issues related to edge cases
      ... in a particular context where the polling is supposed to be used - in the ... The current USB code can be run fine without real locks, ... struct mtx { ...
      (freebsd-current)
    • Re: CCriticalSection - does my thread already have a lock?
      ... I have several worker threads waiting on an IOCP. ... hunts for the appropriate context, validates that the context is still ... locks the context (which could wait on another thread that is already ... IOCP M fires, thread X wakes up (but a timeslice happens, and the thread ...
      (microsoft.public.vc.mfc)
    • Re: skipping locks, mutex_owned, usb
      ... of 'infinite' recursion because mtx_ownedalways returns false. ... mtx_trylock'should' return when we actually act as if no locks ... special context of after panic. ... Skipped locking seems like it should be left silent. ...
      (freebsd-arch)
    • Re: skipping locks, mutex_owned, usb
      ... ukbd_poll(keyboard_t *kbd, int on) ... of 'infinite' recursion because mtx_ownedalways returns false. ... I skip all lock/unlock/etc operations in the post-panic context. ... mtx_trylock'should' return when we actually act as if no locks ...
      (freebsd-arch)
    • Re: skipping locks, mutex_owned, usb
      ... mtx_trylock'should' return when we actually act as if no locks ... special context of after panic. ... aware of its execution context. ... skipping locks reduces the burden on the programmer. ...
      (freebsd-arch)