Re: [PLUG] Multimedia blues

[Rich Freeman <r-plug@thefreemanclan.net>]

On Sat, Jul 8, 2017 at 9:51 PM, Steve Litt <slitt@troubleshooters.com> wrote:
> On Sat, 8 Jul 2017 21:36:37 -0400
> Rich Freeman <r-plug@thefreemanclan.net> wrote:
>
>> Sure, but if a non-root application can make your console hang or your
>> computer freeze, there is a bug in your OS.  Whether the application
>> is "a pig" is beside the point.
>
> I didn't believe you, so I made this program:
>
> And as a normal user ran it like this:
>
> nice -20 ./a.out
>
> My machine was plenty responsive, in or out of X. You're right, at
> least as far as CPU is concerned.
>

I'd be right even if your computer froze up.  :)  It would merely
demonstrate that your OS has a bug.

Note that you can't actually set negative nice values as a non-root
user (typically - I'm not sure offhand if there is a way to tweak
this).

A fork bomb would probably have had a bigger impact.  Though, with
cgroups I suspect that isn't as terrible as it used to be.  If you
have 50M processes running on a modern linux install under one UID
those 50M processes will get about as much time combined as the 3
processes being run under a different UID, as the system will probably
stick those 50M processes in a single cgroup.  By default the linux
scheduler takes cgroups into account when allocating time.  The
scheduler wouldn't fix the exhaustion of process IDs however, and
you'd need to log in as root to kill them off (linux saves one PID for
root only in this situation).

Linux has improved a great deal over the years when it comes to thinks
like this.  The same is true of graphics drivers.  In the old days X
used to run as root and directly manipulated the hardware at some
level.  Now most of that has been abstracted and X can usually run as
non-root, which correctly moves the driver code to, well, the drivers.

That said I suspect that some of this is still imperfect.  It can get
tricky when you're dealing with hardware since the hardware doesn't
follow the same rules as the software.  If a driver allows a program
to send the right instructions to the hardware, then that hardware
could go messing with RAM/etc and doing bad things on its behalf.  Of
course IOMMU can prevent that, but only if it is correctly programmed,
which is of course another driver responsibility.  Since all this
stuff is less mature than other parts of the kernel graphics are one
of the areas where you can get console lockups.  The neverending race
for fancier GPUs also fuels this, as the DRM code never completely
settles down.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug