netdev - Re: Question about locks in qdisc

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] [day] [month] [year] [list]

Message-ID: <49F6138D.6090007@cosmosbay.com>
Date:	Mon, 27 Apr 2009 22:20:29 +0200
From:	Eric Dumazet <dada1@...mosbay.com>
To:	Tom Herbert <therbert@...gle.com>
CC:	netdev@...r.kernel.org
Subject: Re: Question about locks in qdisc_restart

Tom Herbert a écrit :
> In qdisc_restart the qdisc lock is released before taking the
> netif_tx_lock, and only acquired again after unlocking the
> netif_tx_lock.  There's a comment with the function that
> "qdisc_lock(q) and netif_tx_lock are mutually exclusive, if one is
> grabbed, another must be free."  Can anyone tell me the motivation for
> this restriction?  We are seeing some performance improvements by
> holding the lock through qdisc_restart, and I'm not sure why this
> would be bad to do.
> 

Well, motivation is to let other users (cpus) have a chance getting the lock :)

Do you see performance improvements too if using spin_is_contended()
to break the __qdisc_run loop ?

if (need_resched() || jiffies != start_time || spin_is_contended(qdisc_lock(q))

(And removing the unlock/lock in qdisc_restart() as you did)

--
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