From: "Paul E. McKenney" <paulmck@linux•vnet.ibm.com>
To: Herbert Xu <herbert@gondor•apana.org.au>
Cc: David Miller <davem@davemloft•net>,
linville@tuxdriver•com, netdev@vger•kernel.org
Subject: Re: [PATCH] netpoll: use non-BH variant of RCU
Date: Fri, 13 Aug 2010 09:29:12 -0700 [thread overview]
Message-ID: <20100813162912.GJ2511@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100813143904.GA27261@gondor.apana.org.au>
On Fri, Aug 13, 2010 at 10:39:04AM -0400, Herbert Xu wrote:
> On Thu, Aug 12, 2010 at 08:42:13AM -0700, Paul E. McKenney wrote:
> >
> > +/**
> > + * rcu_read_lock_bh_irqsoff() - mark the beginning of an RCU-bh critical section
> > + *
> > + * This is equivalent of rcu_read_lock_bh(), but to be used where the
> > + * caller either is in an irq handler or has irqs disabled. Note that
> > + * this function assumes that PREEMPT_RT kernels run irq handlers at
> > + * higher priority than softirq handlers!
> > + */
> > +static inline void rcu_read_lock_bh_irqsoff(void)
> > +{
> > + rcu_read_unlock_bh_irqsoff_check();
> > + __acquire(RCU_BH);
> > + rcu_read_acquire_bh();
> > +}
>
> Thanks for the patch Paul!
>
> But this doesn't really solve the problem for netif_rx. The reason
> is that netif_rx can either be called with IRQs on OR off. So we
> need to take the right precautions in the case where IRQs are
> enabled along with BH.
Interesting...
Is it possible that IRQs are off at rcu_read_lock_bh_irqsoff() time, but
enabled by the time we get to rcu_read_unlock_bh_irqsoff()? I hope not,
but have to ask. If I am guaranteed of the same state in both cases,
I can do something like the following:
static inline void rcu_read_lock_bh_irqsoff(void)
{
if (!in_irq() && !irqs_disabled())
local_bh_disable();
__acquire(RCU_BH);
rcu_read_acquire_bh();
}
static inline void rcu_read_unlock_bh_irqsoff(void)
{
rcu_read_release_bh();
__release(RCU_BH);
if (!in_irq() && !irqs_disabled())
local_bh_enable();
}
If the state can change in the RCU-bh read-side critical section, then
I would have to record the state in the task structure or some such.
But all in all, mightn't it be easier to remove the checks from
_local_bh_enable(), and then just use rcu_read_lock_bh()? Have those
checks really been that helpful in finding bugs? ;-)
Thanx, Paul
next prev parent reply other threads:[~2010-08-13 16:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-10 20:25 [PATCH] netpoll: use non-BH variant of RCU John W. Linville
2010-08-10 20:43 ` Herbert Xu
2010-08-10 21:19 ` Paul E. McKenney
2010-08-10 23:31 ` David Miller
2010-08-11 11:03 ` Herbert Xu
2010-08-11 11:27 ` Herbert Xu
2010-08-11 15:37 ` John W. Linville
2010-08-12 6:16 ` David Miller
2010-08-11 12:20 ` Paul E. McKenney
2010-08-11 22:00 ` Paul E. McKenney
2010-08-12 6:09 ` David Miller
2010-08-12 15:42 ` Paul E. McKenney
2010-08-13 14:39 ` Herbert Xu
2010-08-13 16:29 ` Paul E. McKenney [this message]
2010-08-13 17:51 ` Herbert Xu
2010-08-15 6:50 ` David Miller
2010-09-02 17:26 ` Paul E. McKenney
2010-09-03 15:34 ` David Miller
2010-09-03 15:52 ` Paul E. McKenney
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=20100813162912.GJ2511@linux.vnet.ibm.com \
--to=paulmck@linux$(echo .)vnet.ibm.com \
--cc=davem@davemloft$(echo .)net \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=linville@tuxdriver$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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