On 2018-10-18 18:19:21 [+0900], Toshiaki Makita wrote:
> On 2018/10/18 18:08, Sebastian Andrzej Siewior wrote:
> > Again: lockdep saw the lock in softirq context once and in process
> > context once and this is what triggers the warning. It does not matter
> > if NAPI is enabled or not during the access in process context. If you
> > want to allow this you need further lockdep annotation…
> >
> > … but: refill_work() disables NAPI for &vi->rq[1] and refills + updates
> > stats while NAPI is enabled for &vi->rq[0].
>
> Do you mean this is false positive? rq[0] and rq[1] never race with each
> other...
Why? So you can't refill rq[1] and then be interrupted and process NAPI
for rq[0]?
But as I said. If lockdep saw the lock in acquired in softirq (what it
did) _and_ in process context (what it did as well) _once_ then this is
enough evidence for the warning.
If you claim that this can not happen due to NAPI guard [0] then this is
something lockdep does not know about.
[0] which I currently don't understand and therefore sent the patch [1]
as Jason pointed out that in the ->ndo_open case the work is
scheduled and then NAPI is enabled (which means the worker could
disable NAPI and refill but before it finishes, ->ndo_open would
continue and enable NAPI)).
[1] 20181018084753.wefvsypdevbzoadg@xxxxxxxxxxxxx
Sebastian
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
