From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757052AbcAOJej (ORCPT ); Fri, 15 Jan 2016 04:34:39 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:55792 "EHLO out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756455AbcAOJeg (ORCPT ); Fri, 15 Jan 2016 04:34:36 -0500 X-Sasl-enc: +se09nQiB4AzL8mPZwuXvgsL14Gx6nUKAH446mp4w29F 1452850475 Subject: Re: [PATCH RT] net: move xmit_recursion to per-task variable on -RT To: Thomas Gleixner References: <20160113152352.GH29964@linutronix.de> <20160114145007.GC17776@linutronix.de> <56981AE1.20202@stressinduktion.org> <1452810004.1223.154.camel@edumazet-glaptop2.roam.corp.google.com> <56982895.6070901@stressinduktion.org> Cc: Eric Dumazet , Sebastian Andrzej Siewior , linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org, Steven Rostedt , netdev@vger.kernel.org From: Hannes Frederic Sowa Message-ID: <5698BD29.8090405@stressinduktion.org> Date: Fri, 15 Jan 2016 10:34:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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