linux-kernel - Re: [PATCH -mm] workqueue: debug possible endless loop in cancel_rearming_delayed

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]

Date:	Thu, 19 Apr 2007 10:28:02 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -mm] workqueue: debug possible endless loop in cancel_rearming_delayed_work

On Thu, Apr 19, 2007 at 09:32:22AM +0200, Ingo Molnar wrote:
> 
> * Jarek Poplawski <jarkao2@...pl> wrote:
> 
> > +		int i = 1000;
> >  
> > -		while (!cancel_delayed_work(dwork))
> > +		while (!cancel_delayed_work(dwork)) {
> >  			flush_workqueue(wq);
> > +			BUG_ON(!i--);
> > +		}
> 
> if then make it a WARN_ON(). But ... dont we have the softlockup 
> detector for such cases? Does CONFIG_DETECT_SOFTLOCKUP=y give you enough 
> information?

Maybe it was my testing, but no softlockup detection triggered here.
I'll try to wait longer - and if no result - I'll resubmit tomorrow.

On the other hand, I think the return of cancel_delayed_work is
too much depending on probability here (it may look like shooting
to running targets), so it could be hard to repeat (and debugging
not necessarily on at the time). As a matter of fact I intentionally
made it for -mm, to see if the problem really exists, because then,
another solution is needed.

And of course WARN_ON should be better - if only it's messages were
more reliably saved in logs after rebooting.

Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/