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: <20230105174210.jbjoqelllcrd57q6@pali>
Date:   Thu, 5 Jan 2023 18:42:10 +0100
From:   Pali Rohár <pali@...nel.org>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 6.2-rc1

On Wednesday 04 January 2023 14:43:16 Jens Axboe wrote:
> 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!

Yes, there are still users and userspace tools (cdrwtool / pktsetup) are
still receiving either small patches or issue reports. I think that it
was two years ago when cdrwtool received big fixups to support
formatting CD-RW discs on new CD/DVD drives.

> 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.

Linus in previous email wrote that he did "make SCSI commands generic"
work in past so direct usage of /dev/cdrom device works for CD-R burning
and read-only mounting.

So could not be (for example sr.c) driver extended to directly do
pktcdvd's work? So when somebody opens /dev/cdrom device in O_RDWR mode
and CD-RW medium is present then it would behave like pktcdvd device...
To have /dev/cdrom generic also for CD-RW write access.

> > 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
>