ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [Ksummit-discuss] [CORE TOPIC] How to cope with 'creative' userspace
@ 2016-07-08 22:35 Jiri Kosina
  2016-07-09 12:18 ` Vlastimil Babka
  0 siblings, 1 reply; 2+ messages in thread
From: Jiri Kosina @ 2016-07-08 22:35 UTC (permalink / raw)
  To: ksummit-discuss

There are many cases where certain components of modern linux desktops 
slightly misuse the features provided by the kernel.

One of the latests instances was PIDs controller being instructed by an 
init system to actually limit the number of created sub-processess/threads 
to insanely small number

	https://github.com/systemd/systemd/blob/dd050decb6ad131ebdeabb71c4f9ecb4733269c0/NEWS#L60

That of course caused horrible user experience left and right.

This is not a single and only exceptional instance of such issue.

I know that this in principle shouldn't really be directly our business, 
but I believe we should be at least a bit nervous when our interfaces are 
being used "incorrectly".

I dont' have a good idea from top of my head what we could immediately do 
to improve this. Some sort of documented guidance on sane values for 
certain userspace toggles? Issue a warning when we think userspace is 
trying to shoot itself in a foot? ...?

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Ksummit-discuss] [CORE TOPIC] How to cope with 'creative' userspace
  2016-07-08 22:35 [Ksummit-discuss] [CORE TOPIC] How to cope with 'creative' userspace Jiri Kosina
@ 2016-07-09 12:18 ` Vlastimil Babka
  0 siblings, 0 replies; 2+ messages in thread
From: Vlastimil Babka @ 2016-07-09 12:18 UTC (permalink / raw)
  To: Jiri Kosina, ksummit-discuss

On 07/09/2016 12:35 AM, Jiri Kosina wrote:
> There are many cases where certain components of modern linux desktops 
> slightly misuse the features provided by the kernel.
> 
> One of the latests instances was PIDs controller being instructed by an 
> init system to actually limit the number of created sub-processess/threads 
> to insanely small number
> 
> 	https://github.com/systemd/systemd/blob/dd050decb6ad131ebdeabb71c4f9ecb4733269c0/NEWS#L60
> 
> That of course caused horrible user experience left and right.
> 
> This is not a single and only exceptional instance of such issue.
> 
> I know that this in principle shouldn't really be directly our business, 
> but I believe we should be at least a bit nervous when our interfaces are 
> being used "incorrectly".

I don't know, this sounds like it has a massive bikesheding potential :)
There might be scenarios where the settings make perfect sense and
deciding upfront what's "incorrect" is impossible.

And we can't always anticipate how creative userspace might be, so it's
unlikely that even if we had some idea, it would get reliably
implemented for all potentially problematic cases, until we actually see
userspace trigger them.

> I dont' have a good idea from top of my head what we could immediately do 
> to improve this. Some sort of documented guidance on sane values for 
> certain userspace toggles? Issue a warning when we think userspace is 
> trying to shoot itself in a foot? ...?

IMHO a first important step is to make sure that if kernel takes some
unusual action due to these userspace interventions, the user has a way
to learn what happened and why. IIRC this kind of visibility for the
pids controller rejecting fork was added only recently (or still being
discussed/improved?). So that's IMHO too late. But don't want to blame
anyone, as my previous paragraph above applies...

> Thanks,
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-07-09 12:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-08 22:35 [Ksummit-discuss] [CORE TOPIC] How to cope with 'creative' userspace Jiri Kosina
2016-07-09 12:18 ` Vlastimil Babka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox