On Tue, May 18, 2021 at 10:48:07AM +0000, Quentin Perret wrote:

On Tuesday 18 May 2021 at 11:28:34 (+0100), Will Deacon wrote:

quoted

I don't have strong opinions on this, but I _do_ want the admission via
sched_setattr() to be consistent with execve(). What you're suggesting
ticks that box, but how many applications are prepared to handle a failed
execve()? I suspect it will be fatal.

Yep, probably.

quoted

Probably also worth pointing out that the approach here will at least
warn in the execve() case when the affinity is overridden for a deadline
task.

Right so I think either way will be imperfect, so I agree with the
above.

Maybe one thing though is that, IIRC, userspace _can_ disable admission
control if it wants to. In this case I'd have no problem with allowing
this weird behaviour when admission control is off -- the kernel won't
provide any guarantees. But if it's left on, then it's a different
story.

So what about we say, if admission control is off, we allow execve() and
sched_setattr() with appropriate warnings as you suggest, but if
admission control is on then we fail both?

That's an interesting idea. The part that I'm not super keen about is
that it means admission control _also_ has an effect on the behaviour of
execve(), so practically you'd have to have it disabled as long as you
have the possibility of 32-bit deadline tasks anywhere in the system,
which impacts 64-bit tasks which may well want admission control enabled.

So perhaps my initial position of trying to keep sched_setattr() and
execve() consistent with each other is flawed and actually we can say:

  * Disable admission control if you want to admit a 32-bit task explicitly
    via sched_setattr()

  * If a 64-bit deadline task execve()s a 32-bit program then we warn
    and override the affinity (i.e. you should avoid doing this if you
    care about the deadlines).

That amounts to dropping this patch and tweaking the documentation.

Dunno, what do you think?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel