linux-kernel - Re: pktcdvd

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: <CAHk-=whfor49J0YTYi6zauiJ_MWwF-XwhSty+HvD4CzxFQ_ZGA@mail.gmail.com>
Date:   Sat, 28 Jan 2023 11:43:46 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: pktcdvd

On Sat, Jan 28, 2023 at 11:35 AM Pali Rohár <pali@...nel.org> wrote:
>
> Hello! Sorry for a longer delay. Now I have started testing it with
> Linux 6.2.0-rc5. Adding mapping works fine. Reading also works. Mounting
> filesystem also works, reading mounted fs also. But after writing some
> data to fs and calling sync cause kernel oops. Below is the dmesg log.
> "sync" freezes and never finish.
>
> [ 1284.701497] pktcdvd: pktcdvd0: writer mapped to sr0
> [ 1321.432589] pktcdvd: pktcdvd0: Fixed packets, 32 blocks, Mode-2 disc
> [ 1321.437543] pktcdvd: pktcdvd0: maximum media speed: 10
> [ 1321.437546] pktcdvd: pktcdvd0: write speed 10x
> [ 1327.098955] pktcdvd: pktcdvd0: 590528kB available on disc
> [ 1329.737263] UDF-fs: INFO Mounting volume 'LinuxUDF', timestamp 2023/01/28 19:16 (103c)
> [ 1435.627449] ------------[ cut here ]------------
> [ 1435.627466] kernel BUG at drivers/block/pktcdvd.c:2434!

Well, this is very much an example of one of the BUG_ON() cases I
absolutely hate - not only did it cause the traceback (which can be
interesting), it also effectively killed the machine in the process.

So that BUG_ON() most definitely shouldn't be a BUG_ON().

Turning it into a WARN_ON() (possibly even of the "ONCE" variety)
together with then finishing the IO with a bio_io_error() would have
been a better option for debugging.

Of course, the real fix is to fix whatever causes it, and I don't know
what that is.

So I'm just piping up to once more highlight my hatred of using
BUG_ON() for "this shouldn't happen" debug code. It's basically never
the right thing to do unless you are in core code that would kill the
machine anyway.

                      Linus