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:	Fri, 16 Jan 2009 20:13:30 -0800
From:	Mandeep Singh Baines <msb@...gle.com>
To:	Frédéric Weisbecker <fweisbec@...il.com>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org, rientjes@...gle.com,
	mbligh@...gle.com, thockin@...gle.com
Subject: Re: [PATCH v2] softlockup: decouple hung tasks check from softlockup detection

Hi Frédéric,

Frédéric Weisbecker (fweisbec@...il.com) wrote:
> > -       read_lock(&tasklist_lock);
> > -       do_each_thread(g, t) {
> > -               if (!--max_count)
> > -                       goto unlock;
> 
> 
> Instead of having this arbitrary limit of tasks, why not just
> lurk the need_resched() and then schedule if it needs too.
> 
> I know that sounds a bit racy, because you will have to release the
> tasklist_lock and
> a lot of things can happen in the task list until you become resched.
> But you can do a get_task_struct() on g and t before your thread is
> going to sleep and then put them
> when it is awaken.
> Perhaps some tasks will disappear or be appended in the list before g
> and t, but that doesn't really matter:
> if they disappear, they didn't lockup, and if they were appended, they
> are not enough cold to be analyzed :-)
> 
> This way you can drop the arbitrary limit of task number given by the user....
> 
> Frederic.
> 

Would be nice to remove the limit. But I don't think get_task_struct()
can be used to prevent a task from being unlinked from the task list. It
only prevents the task_struct from being freed. So hung_task could end up
holding a reference to an unlinked task after it returns from schedule().

That doesn't mean what you are suggesting can't be implemented. Just means
that the case of the held task being unlinked needs to be handled.

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