From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: elendil@planet.nl, manty@manty.net, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: kernel BUG at drivers/ide/ide-disk.c:187 (2.6.31)
Date: Thu, 1 Oct 2009 20:21:24 +0200 [thread overview]
Message-ID: <200910012021.24260.bzolnier@gmail.com> (raw)
In-Reply-To: <20091001.094034.161463891.davem@davemloft.net>
On Thursday 01 October 2009 18:40:34 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 1 Oct 2009 11:25:40 +0200
>
> > The problem is that you simply cannot know what is the system state here.
> >
> > Thus when the unknown block layer request is encountered the best thing
> > you can do is to BUG early instead of allowing the situation when some
> > requests are silently dropped and possibly causing the data corruption.
>
> Yes, but if you BUG() in this kind of location, the chance of getting
> the debugging information from the user can be close to zero. We were
> very lucky this time :-)
Do you mean that there is higher chance of user noticing some WARN_ON
warning somewhere in the log than OOPS? I don't quite believe it..
> If we're tossing a request, signal an error to the submitter.
>
> I hear we have infrastructure for that :-)
It has its own problems (see blk_execute_rq() overriding error values
for one of many examples)..
Anyway this is completely besides the point here (however please don't
let it stop you from fixing the aforementioned infrastructure) until
the whole issue gets debugged properly and I'd be quite happy to do it
under normal circumstances but since:
- you are always jumping the gun with your strong opinions before people
even had chance to debug the issue properly and find real root causes
(vide infamous sparc cmd64x problems, which were caused by the real
bugfixes and were completely fixed within 48h from the initial report)
- for the last three months you haven't debugged/fixed a single IDE issue
and you keep dodging every single bug-report
- I have neither time nor interest for this kind of silly corporate-style
games (I had some really good laugh few times though :)
- I really do not have to work on IDE (never had, it was always a hobby)
- I'm not the maintainer any longer :)
I simply do not even want to be cc:ed on IDE problems unless it is a paid
job or mail comes from the person who in the past proved the ability to
work well with others.
Thank you for understanding.
next prev parent reply other threads:[~2009-10-01 18:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-30 11:05 kernel BUG at drivers/ide/ide-disk.c:187 (2.6.31) Santiago Garcia Mantinan
2009-10-01 6:57 ` Andrew Morton
2009-10-01 8:26 ` Frans Pop
2009-10-01 8:30 ` David Miller
2009-10-01 9:25 ` Bartlomiej Zolnierkiewicz
2009-10-01 16:40 ` David Miller
2009-10-01 18:21 ` Bartlomiej Zolnierkiewicz [this message]
2009-10-01 18:34 ` David Miller
2009-10-01 18:52 ` Bartlomiej Zolnierkiewicz
2009-10-01 10:11 ` Santiago Garcia Mantinan
2009-10-01 18:47 ` David Miller
2009-10-01 18:53 ` David Miller
2009-10-03 3:39 ` Santiago Garcia Mantinan
2009-10-04 22:37 ` Santiago Garcia Mantinan
2009-10-05 0:19 ` David Miller
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=200910012021.24260.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=elendil@planet.nl \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manty@manty.net \
/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