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:	Tue, 27 Jan 2009 10:48:51 -0800
From:	Mandeep Singh Baines <msb@...gle.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	rientjes@...gle.com, mbligh@...gle.com, thockin@...gle.com,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v4] softlockup: remove hung_task_check_count

Ingo Molnar (mingo@...e.hu) wrote:
> 
> * Mandeep Singh Baines <msb@...gle.com> wrote:
> 
> > The design was proposed by Frédéric Weisbecker. Peter Zijlstra suggested 
> > the use of RCU.
> 
> ok, this looks _much_ cleaner.
> 
> One question:
> 
> > -	read_lock(&tasklist_lock);
> > +	rcu_read_lock();
> >  	do_each_thread(g, t) {
> > -		if (!--max_count)
> > +		if (need_resched())
> >  			goto unlock;
> 
> Isnt it dangerous to skip a check just because we got marked for 
> reschedule? Since it runs so rarely it could by accident be preempted and 
> we'd not get any checking done for a long time.
> 

Yeah, the checking could be deferred indefinitely. So you could have a system
where tasks are hung but it takes a really long time to detect this and
finally panic the system. Not so good for high-availability.

What if a check_count sysctl was added? But instead of being a max_check_count,
it would be a min_check_count. This would guarantee that a minimum amount of
checking is done.

Alternatively, the code for trying to continue the iteration after a
reschedule could be re-inserted. That code is a little tricky and
potentially fragile since continuation of a tasklist iteration is not
really supported by the sched.h APIs. But it is does have the nice properties
of getting through the entire list almost all the time and still playing nice
with the scheduler.

Regards,
Mandeep
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ