linux-kernel - Re: [PATCH]: exec: avoid propagating PF_NO

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: <20131128144502.GE3925@htj.dyndns.org>
Date:	Thu, 28 Nov 2013 09:45:02 -0500
From:	Tejun Heo <htejun@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, zhang.yi20@....com.cn,
	lkml <linux-kernel@...r.kernel.org>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH]: exec: avoid propagating PF_NO_SETAFFINITY into
 userspace child

Hello,

On Thu, Nov 28, 2013 at 03:38:57PM +0100, Peter Zijlstra wrote:
> It seems like a perfectly fine interface to me. And much preferable to
> creating yet another weird interface to manage tasks.

The problem with that is it isn't an interface where the user
specifies what's desired but more of just an exposed facet of
implementation details and locks us into either keeping that single
parent model for the eternity or doing a shitty hack like extracing
attributes from that task if we ever need to change the implementation
for whatever reason.  In general, it's a much better idea to have an
interface where the feature supported is represented explicitly and
finitely.  If this is something which is actually necessary, I'd vote
for having an explicit interface for the desired feature, whatever
that may be.

Thanks.

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