linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
	"Van Maren, Kevin" <kevin.vanmaren@unisys.com>,
	linux-ia64@linuxia64.org,
	Linux Kernel List <linux-kernel@vger.kernel.org>,
	dhowells@redhat.com, mingo@elte.hu, torvalds@transmeta.com
Subject: Re: [Linux-ia64] reader-writer livelock problem
Date: Fri, 8 Nov 2002 20:36:08 -0800	[thread overview]
Message-ID: <20021109043608.GF23425@holomorphy.com> (raw)
In-Reply-To: <20021109041543.EBE8A2C29F@lists.samba.org>

In message <1036777105.13021.13.camel@ixodes.goop.org> you write:
>> 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.

On Sat, Nov 09, 2002 at 01:48:17PM +1100, Rusty Russell wrote:
> 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*!

My only interest is doing this specifically for problematic cases,
e.g. the tasklist_lock. Other usages probably shouldn't be altered
during this release cycle unless they too prove problematic, in which
case their usages should be fixed by their maintainers as bugfixes.

Of course, I'm not happy to hear about this explicit recursion.


Bill

  reply	other threads:[~2002-11-09  4:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3FAD1088D4556046AEC48D80B47B478C0101F4E7@usslc-exch-4.slc.unisys.com>
2002-11-08  3:51 ` [Linux-ia64] reader-writer livelock problem William Lee Irwin III
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:38       ` Jeremy Fitzhardinge
2002-11-08 17:43         ` David Howells
2002-11-08 17:57         ` Linus Torvalds
2002-11-09  2:48         ` Rusty Russell
2002-11-09  4:36           ` William Lee Irwin III [this message]
     [not found]           ` <3DCFDAE9.6D359448@email.mot.com>
2002-11-11 19:22             ` David Mosberger
2002-11-12  1:39               ` your mail Rik van Riel
2002-11-08 17:34     ` [Linux-ia64] reader-writer livelock problem David Howells
2002-11-08 17:54       ` David Howells
2002-11-08 17:55       ` Stephen Hemminger
2002-11-08 17:41 Van Maren, Kevin
2002-11-08 17:52 ` Matthew Wilcox
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-08 20:24 Van Maren, Kevin

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=20021109043608.GF23425@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=dhowells@redhat.com \
    --cc=jeremy@goop.org \
    --cc=kevin.vanmaren@unisys.com \
    --cc=linux-ia64@linuxia64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@transmeta.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;
as well as URLs for NNTP newsgroup(s).