All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Benjamin LaHaise <bcrl@redhat.com>, jw schultz <jw@pegasys.ws>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: wait queue process state
Date: Fri, 31 May 2002 15:05:39 -0400	[thread overview]
Message-ID: <20020531190539.GA3965@think.thunk.org> (raw)
In-Reply-To: <1022676201.9255.160.camel@irongate.swansea.linux.org.uk> <1022631707.4123.151.camel@irongate.swansea.linux.org.uk> <3CF2A0FB.8090507@um.edu.mt> <1022572663.12203.127.camel@pc-16.office.scali.no> <20020528160143.G885@pegasys.ws> <20020528190518.E21009@redhat.com> <2338.1022669938@redhat.com> <9160.1022673363@redhat.com>

On Wed, May 29, 2002 at 12:56:03PM +0100, David Woodhouse wrote:
> 
> alan@lxorguk.ukuu.org.uk said:
> >  Given an infinite number of monkeys yes. The 'disk I/O is not
> > interruptible' assumption is buried in vast amounts of software. This
> > isnt a case of sorting out a few misbehaving applications, you can
> > start with some of the most basic unix programs like 'ed' and work
> > outwards.
> 
> Still probably worth doing in the long term. In the short term, we could 
> possibly have a sysctl or personality flag to disable it for the benefit of 
> broken software. I'm in favour of just letting it break though, to be 
> honest - it's _already_ possible to trigger the breakage in some 
> circumstances and making it more reproducible is a _good_ thing.

If you really think this is important thing to do, I suggest you
create a kernel patch which returns a partial read/write whenever the
the size is even (and return an odd number of bytes), thus
guaranteeing that 50% of the time, any I/O appears to have been
interrupted.

Then run it on a system, and see what breaks.  I wouldn't suggest
doing this on any system that you care about, though!

							- Ted

  reply	other threads:[~2002-05-31 19:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-27 21:11 wait queue process state Joseph Cordina
2002-05-27 15:49 ` William Lee Irwin III
2002-05-28  7:57 ` Terje Eggestad
2002-05-28 23:01   ` jw schultz
2002-05-28 23:05     ` Benjamin LaHaise
2002-05-29  0:21       ` Alan Cox
2002-05-29 10:58         ` David Woodhouse
2002-05-29 12:43           ` Alan Cox
2002-05-29 11:55             ` Roman Zippel
2002-05-29 13:29               ` Alan Cox
2002-05-29 11:56             ` David Woodhouse
2002-05-31 19:05               ` Theodore Ts'o [this message]
2002-05-29 11:25       ` Trond Myklebust

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=20020531190539.GA3965@think.thunk.org \
    --to=tytso@mit.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bcrl@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=jw@pegasys.ws \
    --cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.