Re: another attempt at Y2038
On Thu, Oct 20, 2022, at 12:06, Thomas Schmitt wrote:
> Arnd Bergmann wrote:
>
> https://lore.kernel.org/linux-scsi/20201120140633.1673-1-scdbackup@gmx.net/T/
> [PATCH] isofs: fix Oops with zisofs and large PAGE_SIZE
>
> https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbackup@gmx.net/T/
> [PATCH v2 0/2] Fix automatic CD tray loading for data reading via sr
> [PATCH v2 1/2] cdrom: delegate automatic CD tray loading to callers of
> cdrom_open()
> [PATCH v2 2/2] sr: fix automatic tray loading for data reading
>
> I made more bug fixes and a wishlist patch two years ago.
> But keeping them up to date with the agile kernel development is quite a
> big task for me. (As said: userlander.)
These look like you did everything right, and they should have been
picked up by the scsi maintainers. If you ever re-send them, I would
suggest putting the maintainers in 'To:' for the email and the mailing
list in Cc, and asking them specifically to pick up the patches.
> Especially fs/isofs has no maintainer, so i could only submit to linux-scsi
> because of the proximity to cdrom and sr. I had hoped that above two
> patches would be considered as modest self-introduction, but obviously my
> social skills are not sufficient.
I think the hard part here is knowing who to send the patches to.
Unmaintained file systems are particularly tricky, in this case I
would have used
To: Alexander Viro <viro@zeniv.linux.org.uk>
To: Jan Kara <jack@suse.cz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: y2038@lists.linaro.org
Can you rebase the patch on top of v6.1-rc1 and send it to
this list of people? I'll reply with a 'Reviewed-by' tag,
and one of the above should be able to pick it up.
> This is what i think needed mending in kernel 5.10 two years ago:
>
> [PATCH 0/3] Fix the old CD read-ahead bug for media with a single TAO track
> (Most drives report the 2 unreadable TAO run-out blocks as
> part of the medium capacity.)
>
> [PATCH 0/1] sr: verify that last_written block is readable before deriving
> size from it
> (Size assessment of optical media in Linux is quite a mess
> and can overshoot beyond the TAO run-out problem.)
>
> [PATCH 0/4] Attribute size 0 to sr device if no readable medium is loaded
> (Linux reports the size of the last loaded medium, or 2048
> bytes if a blank medium is inserted.)
>
> [PATCH 0/4] Make mount -t iso9660 -o session=N work on DVD and BD media up
> to N=168
> (While -o sbsector= works for all media types, session= works
> only with CD media.)
>
> [PATCH 0/1] isofs: truncate oversized Rock Ridge names to 255 bytes
> (Truncation currently happens if name length is >= 254 and
> then cuts off much more of the name than needed.)
>
> When those bugs would be fixed (or mitigated in case of TAO), i hoped to
> get a favor for my own hobby:
>
> [PATCH 0/3] Introduce a new ioctl CDROM_SIMUL_CHANGE for burn programs
> (Currently Linux knows about new content created via ioctl
> SG_IO only after eject and reload of the Medium.)
>
> The housekeeping aspects of kernel development are really hard for me to
> master. I don't strive to become a regular contributor. But seeing those
> bugs since years causes me to mention them when there is hope to meet
> kernel developers.
>
> So:
> Thanks a lot for replying. Is there a chance to get you interested in the
> other bugs above and maybe even my wish for ioctl CDROM_SIMUL_CHANGE ?
I mainly care about the y2038 issue here, haven't done anything interesting
on cdrom drivers in 20 years ;-)
Arnd
Reply to: