From: Ben Hutchings <bhutchings@solarflare.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Decotigny <decot@googlers.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Or Gerlitz <ogerlitz@mellanox.com>,
Amir Vadai <amirv@mellanox.com>,
"Paul E. McKenney" <paul.mckenney@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Josh Triplett <josh@joshtriplett.org>,
David Howells <dhowells@redhat.com>,
Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: [PATCH v4] lib: cpu_rmap: avoid flushing all workqueues
Date: Thu, 3 Jan 2013 22:26:59 +0000 [thread overview]
Message-ID: <1357252019.2685.45.camel@bwh-desktop.uk.solarflarecom.com> (raw)
In-Reply-To: <20130103134749.1d01bc2e.akpm@linux-foundation.org>
On Thu, 2013-01-03 at 13:47 -0800, Andrew Morton wrote:
> On Wed, 2 Jan 2013 18:35:00 -0800
> David Decotigny <decot@googlers.com> wrote:
> >
>
> (please don't top-post)
>
> > Thanks. It is not too late to review this code. But I'd prefer not to
> > address refactoring issues with this patch, which is supposed to fix a
> > deadlock with some drivers. So I'd rather not to add function
> > renaming, suppressions, etc. that have an effect outside cpu_rmap's
> > code. Instead, I'd like to propose another patch later, which will be
> > a little more intrusive in that respect, if that's ok with you.
> >
> > I believe Ben answered your other concerns, I consider him as the
> > expert as to whether there should be finer-grained locking implemented
> > in this subsystem. Let me just add that I second him in saying that
> > the deadlock risk was clearly identified and mentioned in the doc.
> > Unfortunately, initial implementation makes this risk hard to
> > work-around for some drivers, which is what this patch proposes to
> > address.
>
> ^^ all this pertains to the existing code.
>
> > So, for now, I'd like to keep v4 as the current version. And some
> > refactoring will be done in a later patch.
>
> ^^ this pertains to the current patch. And no reason for ignoring my
> review comments was provided.
>
> So I did it myself. It's very simple, as free_cpu_rmap() has no callers.
>
> Also, free_irq_cpu_rmap() is now distinctly fishy - it runs all the
> notifiers every time it is called.
It removes the notifiers.
> Surely it should only do that when the refcount falls to zero?
[...]
No, absolutely not. An IRQ cpu_rmap may have multiple references to it
now, but it only has one owner: the driver that allocates it and the
associated IRQs.
As soon as the driver frees those IRQs, they may be allocated by some
other driver, so we require that notifiers are removed from them first
(see the WARN_ON in free_irq()). Also, if free_irq_cpu_rmap() did not
remove the notifiers, more notifications could be scheduled and keep the
cpu_rmap alive indefinitely.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
next prev parent reply other threads:[~2013-01-03 22:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1357163124.git.decot@googlers.com>
2013-01-02 21:52 ` David Decotigny
2013-01-02 21:54 ` Ben Hutchings
2013-01-02 22:05 ` Eric Dumazet
2013-01-02 22:20 ` Josh Triplett
2013-01-02 23:12 ` Andrew Morton
2013-01-02 23:46 ` Ben Hutchings
2013-01-03 21:58 ` Andrew Morton
2013-01-08 16:05 ` Ben Hutchings
2013-01-03 2:35 ` David Decotigny
2013-01-03 21:47 ` Andrew Morton
2013-01-03 22:26 ` Ben Hutchings [this message]
2013-01-07 13:00 ` Amir Vadai
2013-01-07 13:01 ` Amir Vadai
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=1357252019.2685.45.camel@bwh-desktop.uk.solarflarecom.com \
--to=bhutchings@solarflare.com \
--cc=akpm@linux-foundation.org \
--cc=amirv@mellanox.com \
--cc=davem@davemloft.net \
--cc=decot@googlers.com \
--cc=dhowells@redhat.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=paul.gortmaker@windriver.com \
--cc=paul.mckenney@linaro.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®