netdev - Re: [PATCH take 2] pkt_sched: Fix qdisc_watchdog() vs. dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080912.182259.238925690.davem@davemloft.net>
Date:	Fri, 12 Sep 2008 18:22:59 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	jarkao2@...il.com, netdev@...r.kernel.org, kaber@...sh.net
Subject: Re: [PATCH take 2] pkt_sched: Fix qdisc_watchdog() vs.
 dev_deactivate() race

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Fri, 12 Sep 2008 18:10:18 -0700

> On Fri, Sep 12, 2008 at 04:10:05PM -0700, David Miller wrote:
> > Well, once that is discussed and resolved, at least the patch I
> > posted can be used as a base for implementation :-)
> 
> Well we should remember the skb returned by peek, and then return
> it on the next dequeue.  If peek hasn't been called since the
> last dequeue then it's equivalent to the current dequeue.
> 
> This works for the two scenarios where we're planning to use
> peek since they'll both call dequeue immediately.
> 
> It'd even work if there was a large gap (i.e., a sleep) after
> the peek since we'd just peek again after waking up.

This requires state, for the unlink.  And that unlink point could be
several levels deep into the tree.

There is also currently no restriction on how a packet scheduler
maintains it's queue of SKBs.

So, if the idea is to keep track of the skb_queue_head pointer to
unlink from at the root, I don't think that's a good idea.

And then there are all of these complicated pieces of state the
classful qdiscs modify when a SKB is removed from their visibility.
So, the unlink isn't just a simple list delete operation.  There
are queue lengths that need to be updated, watchdog timers to
manage, etc.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html