mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Helge Hafting <helgehaf@aitel.hist.no>
To: "Chad N. Tindel" <chad@tindel.net>
Cc: Paulo Marques <pmarques@grupopie.com>,
	Chris Friesen <cfriesen@nortel.com>,
	Mike Galbraith <EFAULT@gmx.de>,
	akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Xterm Hangs - Possible scheduler defect?
Date: Fri, 25 Feb 2005 21:25:43 +0100	[thread overview]
Message-ID: <20050225202543.GA1249@hh.idb.hist.no> (raw)
In-Reply-To: <20050224192237.GA31894@calma.pair.com>

On Thu, Feb 24, 2005 at 02:22:37PM -0500, Chad N. Tindel wrote:
> > If you keep a learning attitude, there is a chance for this discussion 
> > to go on. However, if you keep the "Come now, don't bullshit me, this is 
> > a broken architecture and you're just trying to cover up" attitude, 
> > you're just going to get discarded as a troll.
> 
> I'm not trying to troll here; I suppose I'm just coming from a different 
> background.  I'll try to adjust my tone.
> 
> > I personally like the linux way: "root has the ability to shoot himself 
> > in the foot if he wants to". This is my computer, damn it, I am the one 
> > who tells it what to do.
> 
> I'm all for allowing people to shoot themselves in the foot.  That doesn't
> mean that it is OK for a single userspace thread to mess up a 64-way box.
> 
What's so special about a 64-way box?

Note that the box wasn't messed up - the thread merely used too much cpu.  It 
is perfectly ok - even on a 64-way box - to have a thread that runs with 
higher priority than all the kernel threads - *�if* it occationally sleeps.  
That means the thread can get very low latency work done, and the kernel 
threads will simply wait a little.  Then the thread sleeps, and those 
cruical kernel  threads move on.  A high-priority thread that doesn't 
run all the time is no problem. and it may need the ability to preempt
kernel threads occationally due to timing constraints.  

In the case mentioned, the high-priority thread ran all the time.  That's bad, 
but there is no way the kernel can guess that is was a bad idea in that case.  
The kernel does what it is told.  An ordinary user can�'t use such priorities,
so there is no security problem here.  Only root can, and root has the
power to disrupt service anyway (shutdown, kill any process, delete any file.)

Someone who runs as root is _trusted_ to do the right thing, this trust
might be outside the scope of the os.  In other words, some people are
allowed to run special processes, by the machine owner.  Some gets
the root password - and they are supposed to be above the "crowds" and
not crash the machine just because they can.

Helge Hafting


  parent reply	other threads:[~2005-02-25 20:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20050224075756.GA18639@calma.pair.com>
     [not found] ` <30111.1109237503@www1.gmx.net>
2005-02-24 17:53   ` Chad N. Tindel
2005-02-24 18:19     ` Chris Friesen
2005-02-24 18:38       ` Chad N. Tindel
2005-02-24 19:04         ` Paulo Marques
2005-02-24 19:22           ` Chad N. Tindel
2005-02-24 19:46             ` Chris Friesen
2005-02-24 20:08               ` Chad N. Tindel
2005-02-24 20:29                 ` Chris Friesen
2005-02-25  0:51                 ` Ingo Oeser
2005-02-25 15:12                   ` Chris Friesen
2005-02-25 15:39                     ` Ingo Oeser
2005-02-25 15:53                       ` Paulo Marques
2005-02-25 16:24                         ` Lee Revell
2005-02-25 17:07                           ` Chris Friesen
2005-02-24 19:52             ` Barry K. Nathan
2005-02-25 20:25             ` Helge Hafting [this message]
2005-02-25 21:02               ` Chad N. Tindel
2005-02-25 23:24                 ` Lee Revell
2005-02-26 11:58                 ` Helge Hafting
2005-02-25  4:25     ` Mike Galbraith
2005-02-23 23:06 Chad N. Tindel
2005-02-24  2:36 ` Andrew Morton
2005-02-24  5:23   ` Chad N. Tindel
2005-02-24  6:50     ` Andrew Morton
2005-02-24  5:26   ` Chad N. Tindel
2005-02-24 13:25     ` Helge Hafting
2005-02-24 17:33       ` Chad N. Tindel
2005-02-24 22:25         ` Peter Chubb
2005-02-24 22:40           ` Chad N. Tindel
2005-02-24 23:00         ` Andrew Morton
2005-02-24 23:22           ` Chris Friesen
2005-02-24 23:32             ` Andrew Morton
2005-02-25  0:47           ` Kyle Moffett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050225202543.GA1249@hh.idb.hist.no \
    --to=helgehaf@aitel.hist.no \
    --cc=EFAULT@gmx.de \
    --cc=akpm@osdl.org \
    --cc=cfriesen@nortel.com \
    --cc=chad@tindel.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmarques@grupopie.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®