On Wed, 2018-05-16 at 09:56 +0200, Paolo Abeni wrote: > On Tue, 2018-05-15 at 23:17 +0300, Michael S. Tsirkin wrote: > > On Tue, May 15, 2018 at 04:24:37PM +0200, Paolo Abeni wrote: > > > After the previous patch, for NOLOCK qdiscs, q->seqlock is > > > always held when the dequeue() is invoked, we can drop > > > any additional locking to protect such operation. > > > > > > Signed-off-by: Paolo Abeni <pab...@redhat.com> > > > --- > > > include/linux/skb_array.h | 5 +++++ > > > net/sched/sch_generic.c | 4 ++-- > > > 2 files changed, 7 insertions(+), 2 deletions(-) > > > > Is the seqlock taken during qdisc_change_tx_queue_len? > > We need to prevent that racing with dequeue. > > Thanks for the head-up! I missed that code-path. > > I'll add the lock in qdisc_change_tx_queue_len() in v2.
Actually the lock is not needed in qdisc_change_tx_queue_len(): the device is deactivated before calling ops->change_tx_queue_len, so the latter can't race with ops->dequeue(). I think the current patch is safe. Cheers, Paolo
