linux-kernel - Re: [PATCH 04/40] sched: implement __set_cpus

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:	Mon, 18 Jan 2010 12:41:09 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	torvalds@...ux-foundation.org, mingo@...e.hu, awalls@...ix.net,
	linux-kernel@...r.kernel.org, jeff@...zik.org,
	akpm@...ux-foundation.org, jens.axboe@...cle.com,
	rusty@...tcorp.com.au, cl@...ux-foundation.org,
	dhowells@...hat.com, arjan@...ux.intel.com, avi@...hat.com,
	johannes@...solutions.net, andi@...stfloor.org,
	Mike Galbraith <efault@....de>
Subject: Re: [PATCH 04/40] sched: implement __set_cpus_allowed()

On Mon, 2010-01-18 at 20:22 +0900, Tejun Heo wrote:
> On 01/18/2010 06:56 PM, Peter Zijlstra wrote:
> >> NOTE: It would be nice to implement kthread_bind() in terms of
> >>       __set_cpus_allowed() if we can drop the capability to bind to a
> >>       dead CPU from kthread_bind(), which doesn't seem too popular
> >>       anyway.  With such change, we'll have set_cpus_allowed_ptr() for
> >>       regular tasks and kthread_bind() for kthreads and can use
> >>       PF_THREAD_BOUND instead of passing @force parameter around.
> > 
> > 
> > And your changelog still sucks... it only says what it does, not why.
> > 
> > still hate the patch too.
> 
> These part haven't changed at all since the last posting so if you
> disliked it before it's kind of expected you still do so.

You could at least have augmented the changelog with the why.. my memory
thinks it had to so with that silly move back on up story.

> Anyways, I'm not the greatest fan of this patch either.  Let's see how
> the whole series fares out first and try to make this better.  What do
> you think about doing what's described in the NOTE?

I'm still not sure we need any of this. For new threads we have the
stopped state and kthread_bind() should work in its current form (except
you need patch 1 in your series when you're creating new threads when
the cpu is currently going down).



--
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/