From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
To: David Miller <davem@davemloft.net>
Cc: thomas.petazzoni@free-electrons.com, netdev@vger.kernel.org,
michael@free-electrons.com
Subject: Re: [PATCH] macb: Add support of the netpoll API
Date: Fri, 17 Apr 2009 11:25:53 +0200 [thread overview]
Message-ID: <20090417112553.21e1f2e5@hskinnemoen-d830> (raw)
In-Reply-To: <20090417.020841.21679845.davem@davemloft.net>
David Miller wrote:
> From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> Date: Fri, 17 Apr 2009 11:07:03 +0200
>
> > David Miller wrote:
> >> 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.
> >
> > The interrupt handler takes bp->lock. Isn't that sufficient to prevent
> > it from running on other cpus?
>
> We don't necessarily hold bp->lock here, we could be called from
> the netpoll code. Another cpu could easily hold bp->lock and be
> in the middle of the interrupt handler.
Yes, but we're about to take it. poll_controller() disables interrupts
and calls the interrupt handler, which takes the lock. That's
essentially an open-coded spin_lock_irqsave().
Now, that will obviously deadlock too if we're called from within the
interrupt handler or some other place holding bp->lock...
I guess you're right -- we just have to be careful about calling
printk() from within the driver. But it seems a lot easier to just drop
the lock before dumping an error message than it is to work around that
disable_irq() deadlock. And if you're running with verbose debugging
enabled, you probably shouldn't be using netconsole anyway.
Haavard
next prev parent reply other threads:[~2009-04-17 9:26 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-15 13:46 [PATCH] macb: Add support of the netpoll API Thomas Petazzoni
2009-04-16 9:07 ` Haavard Skinnemoen
2009-04-16 9:24 ` Thomas Petazzoni
2009-04-16 10:31 ` Haavard Skinnemoen
2009-04-17 8:34 ` David Miller
2009-04-17 9:07 ` Haavard Skinnemoen
2009-04-17 9:08 ` David Miller
2009-04-17 9:25 ` Haavard Skinnemoen [this message]
2009-04-17 9:33 ` David Miller
2009-04-17 9:50 ` Haavard Skinnemoen
2009-04-17 10:44 ` David Miller
2009-04-17 11:39 ` David Miller
2009-04-20 10:57 ` Haavard Skinnemoen
2009-04-21 8:54 ` David Miller
2009-05-04 11:54 ` [PATCH v3] " Haavard Skinnemoen
2009-05-04 18:08 ` David Miller
2009-04-17 11:41 ` [PATCH] " Haavard Skinnemoen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090417112553.21e1f2e5@hskinnemoen-d830 \
--to=haavard.skinnemoen@atmel.com \
--cc=davem@davemloft.net \
--cc=michael@free-electrons.com \
--cc=netdev@vger.kernel.org \
--cc=thomas.petazzoni@free-electrons.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox