Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

2018-05-04 Thread Peter Zijlstra
On Fri, May 04, 2018 at 09:07:35PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-05-04 20:51:32 [+0200], Peter Zijlstra wrote: > > softirqs disabled, ack that is exactly what it checks. > > > > But afaict the assertion you introduced tests that we are _in_ softi

Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

2018-05-04 Thread Peter Zijlstra
On Fri, May 04, 2018 at 08:45:39PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote: > > On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote: > > > From: Anna-Maria Gleixner <anna-ma...@linutronix.de>

Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning

2018-05-04 Thread Peter Zijlstra
On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote: > From: Anna-Maria Gleixner > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure > the softirq context for the subsequent netif_receive_skb() call. That's not in fact

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

2018-01-08 Thread Peter Zijlstra
On Mon, Jan 08, 2018 at 11:43:42AM +, Alan Cox wrote: > On Mon, 8 Jan 2018 11:08:36 +0100 > Peter Zijlstra <pet...@infradead.org> wrote: > > > On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote: > > > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Bi

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

2018-01-08 Thread Peter Zijlstra
On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote: > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman > wrote: > > In at least one place (mpls) you are patching a fast path. Compile out > > or don't load mpls by all means. But it is not acceptable to change

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

2017-03-03 Thread Peter Zijlstra
On Fri, Mar 03, 2017 at 03:49:38PM +0100, Peter Zijlstra wrote: > On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote: > > Right. The main purpose is to read/write _ONCE_. You can assume a somewhat > > atomic access for sizes <= word size. And there ar

Re: [PATCH 02/26] rewrite READ_ONCE/WRITE_ONCE

2017-03-03 Thread Peter Zijlstra
On Fri, Mar 03, 2017 at 09:26:50AM +0100, Christian Borntraeger wrote: > Right. The main purpose is to read/write _ONCE_. You can assume a somewhat > atomic access for sizes <= word size. And there are certainly places that > rely on that. But the *ONCE thing is mostly used for things where we

Re: sched/core: WARNING in __might_sleep

2016-02-01 Thread Peter Zijlstra
On Mon, Feb 01, 2016 at 12:26:06PM +0100, Johannes Berg wrote: > On Mon, 2016-02-01 at 12:13 +0100, Peter Zijlstra wrote: > >  > > Yeah, from the rfkill code, which you failed to CC. > > Thanks Peter :) > > > In any case, this is a fail in the rfkill co

Re: sched/core: WARNING in __might_sleep

2016-02-01 Thread Peter Zijlstra
On Sun, Jan 31, 2016 at 11:33:43PM +0800, Baozeng wrote: > Hello, > The following program triggers WARNING in __might_sleep: Yeah, from the rfkill code, which you failed to CC. Also, please don't use the gmail web interface to send email, it completely destroys stuff and almost guarantees

Re: [RFC 0/4] mac80211: jump labels for hw flags

2015-11-09 Thread Peter Zijlstra
On Mon, Nov 09, 2015 at 11:02:33PM +0100, Johannes Berg wrote: > As far as the code is concerned, there are two really ugly things: > 1) I still use struct static_key - couldn't quite figure it out > with static_key_false. I think I can replace it easily though. Yeah, didn't see anything

Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive

2015-07-09 Thread Peter Zijlstra
On Thu, Jul 09, 2015 at 08:31:16PM +0200, Arend van Spriel wrote: There is or there was? If there is now I am fine with this patch, but if it already was there the author might have had a reason for adding a local function and I would like to hear that reason. Nevermind. Just noticed you are