Re: [PATCH net-next v2 1/2] lockdep: Introduce in_softirq lockdep assert

2020-11-24 Thread Yunsheng Lin
On 2020/11/24 16:11, Peter Zijlstra wrote: > On Mon, Nov 23, 2020 at 12:12:59PM -0800, Jakub Kicinski wrote: >> One liner would be: >> >> * Acceptable for protecting per-CPU resources accessed from BH >> >> We can add: >> >> * Much like in_softirq() - semantics are ambiguous, use

Re: [PATCH net-next v2 1/2] lockdep: Introduce in_softirq lockdep assert

2020-11-24 Thread Peter Zijlstra
On Mon, Nov 23, 2020 at 12:12:59PM -0800, Jakub Kicinski wrote: > One liner would be: > > * Acceptable for protecting per-CPU resources accessed from BH > > We can add: > > * Much like in_softirq() - semantics are ambiguous, use carefully. * > > > IIUC we basically want to

Re: [PATCH net-next v2 1/2] lockdep: Introduce in_softirq lockdep assert

2020-11-23 Thread Jakub Kicinski
On Mon, 23 Nov 2020 15:27:25 +0100 Peter Zijlstra wrote: > On Sat, Nov 21, 2020 at 11:06:15AM +0800, Yunsheng Lin wrote: > > The current semantic for napi_consume_skb() is that caller need > > to provide non-zero budget when calling from NAPI context, and > > breaking this semantic will cause hard

Re: [PATCH net-next v2 1/2] lockdep: Introduce in_softirq lockdep assert

2020-11-23 Thread Peter Zijlstra
On Sat, Nov 21, 2020 at 11:06:15AM +0800, Yunsheng Lin wrote: > The current semantic for napi_consume_skb() is that caller need > to provide non-zero budget when calling from NAPI context, and > breaking this semantic will cause hard to debug problem, because > _kfree_skb_defer() need to run in

[PATCH net-next v2 1/2] lockdep: Introduce in_softirq lockdep assert

2020-11-20 Thread Yunsheng Lin
The current semantic for napi_consume_skb() is that caller need to provide non-zero budget when calling from NAPI context, and breaking this semantic will cause hard to debug problem, because _kfree_skb_defer() need to run in atomic context in order to push the skb to the particular cpu'