From: Muli Ben-Yehuda <mulix@mulix.org>
To: "Måns Rullgård" <mru@kth.se>
Cc: linux-kernel@vger.kernel.org
Subject: Re: What does tainting actually mean?
Date: Wed, 28 Apr 2004 17:22:20 +0300 [thread overview]
Message-ID: <20040428142219.GC9820@mulix.org> (raw)
In-Reply-To: <yw1x3c6omdwb.fsf@kth.se>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
On Wed, Apr 28, 2004 at 03:27:00PM +0200, Måns Rullgård wrote:
> Muli Ben-Yehuda <mulix@mulix.org> writes:
>
> > On Wed, Apr 28, 2004 at 02:48:30PM +0200, Måns Rullgård wrote:
> >> > Stack overflows in a badly written device driver can overwrite task
> >> > structures and cause apparent filesystem problems which are blamed on
> >> > the hapless filesystem authors instead of where the blame properly
> >> > lies, namely the device driver author.
> >>
> >> Wouldn't the problem be just as difficult to pin to a certain module
> >> even if the source code was open? I prefer open source modules (I
> >> have Alpha machines), but I just can't see this argument work.
> >
> > No. If the code is open, you can read it and find the bug - just by
> > reading it. If the code is closed, your only recourse is to observe
> > the corruption while it happens or read the assembly, which is quite a
> > lot more difficult.
>
> Something has to hint to as to which code to read. The usual way to
> find the offending module is to remove modules until the problem goes
> away. The availability of source code only matters when you have
> found which module actually has the bug.
If it's closed, you may think you have found the bug, but you can't
verify. If it's open, you can.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-04-28 14:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-28 4:00 What does tainting actually mean? Nigel Cunningham
2004-04-28 4:27 ` Jurriaan
2004-04-28 4:30 ` Nigel Cunningham
2004-04-28 5:19 ` Chris Friesen
2004-04-28 5:18 ` Nigel Cunningham
2004-04-28 12:10 ` Theodore Ts'o
2004-04-28 12:48 ` Måns Rullgård
2004-04-28 13:04 ` Muli Ben-Yehuda
2004-04-28 13:27 ` Måns Rullgård
2004-04-28 14:22 ` Muli Ben-Yehuda [this message]
2004-04-28 15:56 ` Joseph Pingenot
2004-04-28 16:01 ` Valdis.Kletnieks
2004-05-03 12:45 ` Pavel Machek
2004-05-03 18:50 ` Stefan Smietanowski
2004-04-28 5:51 ` Karim Yaghmour
2004-04-28 6:51 ` Keith Duthie
2004-04-28 10:26 ` Ville Herva
2004-05-06 15:25 ` Anthony de Boer
[not found] <04Apr28.020259edt.41801@gpu.utcc.utoronto.ca>
2004-04-28 6:18 ` Nigel Cunningham
2004-04-28 10:37 ` Bartlomiej Zolnierkiewicz
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=20040428142219.GC9820@mulix.org \
--to=mulix@mulix.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mru@kth.se \
/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.