netdev
[Top] [All Lists]

Re: Deadlock in sungem/ip_auto_config/linkwatch

To: Michal Ostrowski <mostrows@xxxxxxxxxxxxxx>
Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch
From: Stefan Rompf <srompf@xxxxxx>
Date: Mon, 5 Jan 2004 17:50:55 +0100
Cc: netdev@xxxxxxxxxxx
In-reply-to: <1073319565.2043.98923.camel@xxxxxxxxxxxxxxxxxxxx>
References: <1073307882.2041.98320.camel@xxxxxxxxxxxxxxxxxxxx> <200401051550.51063.srompf@xxxxxx> <1073319565.2043.98923.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.5.94
Am Montag, 05. Januar 2004 17:19 schrieb Michal Ostrowski:

> Suppose the linkwatch code backs-off in the case that rtnl_sem is held
> legitimately by thread A.  Meanwhile, thread B is doing a
> flush_scheduled_work in order to wait for pending linkwatch events to
> complete.

This won't happen. If a pending linkwatch event needs to be scheduled 
synchronously (f.e. when a device is unregistered), it is executed in context 
of the calling process, not inside the workqueue thread.

> My initial though was to use a seperate work-queue, un-entangled with
> the global queue used for flush_scheduled_work. This would allow
> linkwatch events to be synchronized against explicitly.

That's overkill, and if I understand flush_workqueue() right, it doesn't care 
about work that is queued with delay, so it even wouldn't help. That's why I 
thought about a function to unregister pending work.

Stefan
-- 
"doesn't work" is not a magic word to explain everything.

Attachment: smime.p7s
Description: signature

<Prev in Thread] Current Thread [Next in Thread>