linux-kernel - Re: Linux 6.2-rc1

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: <90eb90da-2679-cac0-979d-6ba0cc8ccbb8@kernel.dk>
Date:   Wed, 4 Jan 2023 14:43:16 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Pali Rohár <pali@...nel.org>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.2-rc1

On 1/4/23 2:32?PM, Linus Torvalds wrote:
>> But here it is CD-RW media in read-write mode with kernel udf
>> filesystem driver without any userspace involved (after proper
>> formatting).
> 
> ... but I'm not sure about direct writeable mount support.
> 
> That may indeed be an area that only pktcdvd ended up doing. I've
> never used it myself, even historically.
> 
> Let's bring in more people. Because they may not have thought about
> some RW UDF case.

We did think about it, since that's the only reason for pktcdvd to
exist. Basically what the driver does is ensure that any write is 32K in
size, which is the size which can be written to media. It'll gather data
as needed to make that happen. Thats it. Outside of that, it's just some
setup and closing code.

This obviously would be better to handle in userspace, all of it. Back
when I wrote this driver, we didn't have a lot of the fancier stuff we
have today. It could be done via ublk, for example, or something like
that.

The surprising bit here is:

1) Someone is still using this driver, and
2) It actually works!

While I'd love to nudge folks in other directions for this use case, and
I strongly think that we should, it also doesn't seem fair to just yank
it while folks are using it... But I'd like to VERY strongly encourage
folks to come up with a new solution for this use case. It really isn't
a solution that belongs in the kernel today.

> The removal seems to revert cleanly, although it does require
> reverting a few subsequent commits too (that removed code that only
> pktcdvd used):
> 
>     git revert db1c7d779767 85d6ce58e493 f40eb99897af
> 
> where we have
> 
>     db1c7d779767 block: bio_copy_data_iter
>     85d6ce58e493 block: remove devnode callback from struct
> block_device_operations
>     f40eb99897af pktcdvd: remove driver.

I'll queue this up - and unless I hear valid complaints to why we should
not just reinstate the driver for now, it'll go out with the next pull
request.

-- 
Jens Axboe