netdev - Re: 2.6.24 BUG: soft lockup

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]

Date:	Sat, 29 Mar 2008 10:11:01 +0100
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Matheos Worku <Matheos.Worku@....COM>,
	David Miller <davem@...emloft.net>, jesse.brandeburg@...el.com,
	netdev@...r.kernel.org, hadi@...erus.ca
Subject: Re: 2.6.24 BUG: soft lockup - CPU#X

On Sat, Mar 29, 2008 at 09:06:10AM +0800, Herbert Xu wrote:
> On Fri, Mar 28, 2008 at 04:29:53PM +0100, Jarek Poplawski wrote:
> >
> > But during this, now limited, time of qdisc_run() there is a contention
> > for queue_lock and probably some additional cache updating because of
> > this other enqueuing, which could be delayed especially if queue length
> > is above some level.
> 
> You mean delaying into a per-cpu queue? That sounds interesting.

I mean any delaying could be necessary here. After rethinking it seems
to me this solution with the flag could be wrong even after current fix.

The owner of the flag has to give up queue_lock for some time, and
because of this its chances for regaining the lock are worse: other CPUs
could take it in a loop, winning the cache, and adding packets, which
are imediately dumped (or requeued).

So, it would make a kind of reverse lockup situation. Then, even normal
contention for both locks seems safer against such races: throughput
could be worse, but probably no such "(soft)lockup" risk.

Regards,
Jarek P.
--
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