linux-kernel - Re: [PATCH v2] softlockup: decouple hung tasks check from softlockup detection

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]

Message-ID: <20090117041330.GE14946@google.com>
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/