From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH RT] net: move xmit_recursion to per-task variable on -RT
Date: Fri, 15 Jan 2016 10:34:33 +0100 [thread overview]
Message-ID: <5698BD29.8090405@stressinduktion.org> (raw)
In-Reply-To: <alpine.DEB.2.11.1601150916180.3575@nanos>
On 15.01.2016 09:21, Thomas Gleixner wrote:
> On Fri, 15 Jan 2016, Hannes Frederic Sowa wrote:
>> On 14.01.2016 23:20, Eric Dumazet wrote:
>>> On Thu, 2016-01-14 at 23:02 +0100, Hannes Frederic Sowa wrote:
>>>
>>>> We are just adding a second recursion limit solely to openvswitch which
>>>> has the same problem:
>>>>
>>>> https://patchwork.ozlabs.org/patch/566769/
>>>>
>>>> This time also we depend on rcu_read_lock marking the section being
>>>> nonpreemptible. Nice would be a more generic solution here which doesn't
>>>> need to always add something to *current.
>>>
>>>
>>> Note that rcu_read_lock() does not imply that preemption is disabled.
>>
>> Exactly, it is conditional on CONFIG_PREEMPT_CPU/CONFIG_PREMPT_COUNT but
>> haven't thought about exactly that in this moment.
>
> Wrong. CONFIG_PREEMPT_RCU makes RCU preemptible.
>
> If that is not set then it fiddles with preempt_count when
> CONFIG_PREEMPT_COUNT=y. If CONFIG_PREEMPT_COUNT=n then you have a non
> preemptible system anyway.
>
> So you cannot assume that rcu_read_lock() disables preemption.
Sorry for maybe writing it misleading but that is exactly what I wanted
to say here. Yes, I agree, I didn't really check because of _bh and
rcu_read_lock. This was a mistake. ;)
I already send out an updated patch with added preemption guards.
Thanks,
Hannes
prev parent reply other threads:[~2016-01-15 9:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 15:23 [PATCH RT] net: move xmit_recursion to per-task variable on -RT Sebastian Andrzej Siewior
2016-01-13 17:31 ` Thomas Gleixner
2016-01-14 14:50 ` Sebastian Andrzej Siewior
2016-01-14 22:02 ` Hannes Frederic Sowa
2016-01-14 22:20 ` Eric Dumazet
2016-01-14 23:00 ` Hannes Frederic Sowa
2016-01-15 8:21 ` Thomas Gleixner
2016-01-15 9:34 ` Hannes Frederic Sowa [this message]
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=5698BD29.8090405@stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=bigeasy@linutronix.de \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.