linux-kernel - Re: kernel BUG at drivers/ide/ide-disk.c:187 (2.6.31)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20091001.094034.161463891.davem@davemloft.net>
Date:	Thu, 01 Oct 2009 09:40:34 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	bzolnier@...il.com
Cc:	elendil@...net.nl, manty@...ty.net, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: kernel BUG at drivers/ide/ide-disk.c:187 (2.6.31)

From: Bartlomiej Zolnierkiewicz <bzolnier@...il.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 :-)

If we're tossing a request, signal an error to the submitter.

I hear we have infrastructure for that :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/