[lkml]   [2006]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Export current_is_keventd() for libphy
On Tue, 5 Dec 2006 17:48:05 +0000 (GMT)
"Maciej W. Rozycki" <> wrote:

> Essentially there is a race when disconnecting from a PHY, because
> interrupt delivery uses the event queue for processing. The function to
> handle interrupts that is called from the event queue is phy_change().
> It takes a pointer to a structure that is associated with the PHY. At the
> time phy_stop_interrupts() is called there may be one or more calls to
> phy_change() still pending on the event queue. They may not be able to be
> processed until the structure passed to phy_change() have been freed, at
> which point calling the function is wrong.
> One way of avoiding it is calling flush_scheduled_work() from
> phy_stop_interrupts(). This is fine as long as a caller of
> phy_stop_interrupts() (not necessarily the immediate one calling into
> libphy) does not hold the netlink lock.

So let me try to rephrase...

- phy_change() is the workqueue callback function. It is executed by

- Something under phy_change() takes rtnl_lock() (but what??)

- phy_stop_interrupts() does flush_scheduled_work(). This has to
following logic:

- if I am kevetnd, run phy_change() directly.

- If I am not keventd, wait for keventd() to run phy_change()

- So if the caller of phy_stop_interrupt() already holds rtnl_lock(),
and if that caller is keventd then it will recur onto rntl_lock() and
will deadlock.

Problem is, if the caller of phy_stop_interrupt() is *not* keventd, that
caller will still deadlock, because that caller is waiting for keventd to
run phy_change(), and keventd cannot do that, because the not-keventd
process already holds rtnl_lock.

Now, afaict, there are only two callers of phy_stop_interrupts(): the
close() handlers of gianfar.c and fs_enet-main.c (confusingly held in
netdevice.stop (confusingly called by dev_close())). Via phy_disconnect.
Did I miss anything?

And the dev_close() caller holds rtnl_lock.


a) Please tell us what code under phy_change() wants to take rtnl_lock

b) I think it should deadlock whether or not the caller of
phy_stop_interrupt() is keventd. What am I missing?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-05 21:43    [W:0.129 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site