[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090417.013450.02738760.davem@davemloft.net>
Date: Fri, 17 Apr 2009 01:34:50 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: thomas.petazzoni@...e-electrons.com
Cc: haavard.skinnemoen@...el.com, netdev@...r.kernel.org,
michael@...e-electrons.com
Subject: Re: [PATCH] macb: Add support of the netpoll API
From: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Date: Thu, 16 Apr 2009 11:24:35 +0200
> Le Thu, 16 Apr 2009 11:07:53 +0200,
> Haavard Skinnemoen <haavard.skinnemoen@...el.com> a écrit :
>
>> Hmm...is this safe? What if printk() is called from the macb interrupt
>> handler?
>
> I'm not sure, but that strategy is used in most drivers supporting the
> netpoll API (3c509.c, 8139cp.c, 8139too.c, b44.c, bfin_mac.c,
> bnx2x_main.c, etc.). It also seems to be the way suggested by netpoll
> author, http://oss.sgi.com/archives/netdev/2003-10/msg00800.html.
>
> disable_irq() only disables the macb IRQ line. Is that an issue for
> printk() execution ?
And in response to this Haavard explained the potential deadlock
(sorry I deleted that email) and suggested to use local_irq_save()
But that won't work either, because it doesn't prevent the interrupt
handler from running on other cpus, it only prevents that on the
local cpu.
But I do wonder, because a lot of drivers do in fact use that
disable_irq() scheme to implement ->poll_controller().
I suppose one just needs to be careful about using printk from
the interrupt handler when supporting netpoll.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists