public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Mario Smarduch <cms063@email.mot.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] reader-writer livelock problem
Date: Mon, 11 Nov 2002 16:29:29 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590709805382@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590709805355@msgid-missing>

Rusty Russell wrote:

> In message <1036777105.13021.13.camel@ixodes.goop.org> you write:
> > On Fri, 2002-11-08 at 09:25, Linus Torvalds wrote:
> > > There's another reason for not doing it that way: allowing readers to keep
> > > interrupts on even in the presense of interrupt uses of readers.
> > >
> > > If you do the "pending writes stop readers" approach, you get
> > >
> > >             cpu1                    cpu2
> > >
> > >             read_lock() - get
> > >
> > >                                     write_lock_irq() - pending
> > >
> > >             irq happens
> > >              - read_lock() - deadlock
> > >
> > > and that means that you need to make readers protect against interrupts
> > > even if the interrupts only read themselves.
> >
> > Even without interrupts that would be a bug.  It isn't ever safe to
> > attempt to retake a read lock if you already hold it, because you may
> > deadlock with a pending writer.  Fair multi-reader locks aren't
> > recursive locks.
>
> That's the point.  This is explicitly guaranteed with the current
> locks, and you are allowed to recurse on them.  The netfilter code
> explicitly uses this to retake the net brlock, since it gets called
> from different paths.
>
> Implement "read_lock_yield" or "wrlock_t" but don't break existing
> semantics until 2.7 *please*!
>
> Rusty.
> --
>   Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

From what I understand this is a huge security risk - any mischevious user
can hang the system. Practically speaking its a hard sell to tell any customer
that in 2.7 the problem will be fixed and hope that it doesnt happen before
then.  Is there any way to prevent the user (non-root) from exploiting this
weakness? In order for this to happen do all the CPUs have to run at
100%? I know that on some commercial Unix systems there are ways
to cap the CPU utilization by user/group ids are there such features/patches
available
on Linux?

- Mario.



  parent reply	other threads:[~2002-11-11 16:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-08  3:23 [Linux-ia64] reader-writer livelock problem Van Maren, Kevin
2002-11-08 17:13 ` Jeremy Fitzhardinge
2002-11-08 17:25 ` Linus Torvalds
2002-11-08 17:28 ` Linus Torvalds
2002-11-08 17:34 ` David Howells
2002-11-08 17:38 ` Jeremy Fitzhardinge
2002-11-08 17:41 ` Van Maren, Kevin
2002-11-08 17:43 ` David Howells
2002-11-08 17:52 ` Matthew Wilcox
2002-11-08 17:54 ` David Howells
2002-11-08 17:55 ` Stephen Hemminger
2002-11-08 18:05 ` Van Maren, Kevin
2002-11-08 19:19 ` Matthew Wilcox
2002-11-08 19:26 ` David Mosberger
2002-11-08 20:17 ` Van Maren, Kevin
2002-11-08 20:39 ` Matthew Wilcox
2002-11-09  2:48 ` Rusty Russell
2002-11-11 16:29 ` Mario Smarduch [this message]
2002-11-11 20:01 ` [Linux-ia64] reader-writer livelock proble Mario Smarduch

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=marc-linux-ia64-105590709805382@msgid-missing \
    --to=cms063@email.mot.com \
    --cc=linux-ia64@vger.kernel.org \
    /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