Hi Helmut!
On 10/18/22 12:48, Helmut Grohne wrote:
I was also wondering about this Y2038 thingy and did some experiments.
I'm reporting what I found to document it, but don't see much actionable
stuff here. Many thanks to Arnd Bergmann for his input.
Attempt #1: rebootstrap
Given that I develop rebootstrap, attempting to use it for a time64
bootstrap seemed quite natural. I've been talking to this with Steve
multiple times including DC22. The question was how to plug it in. In
the end I went for Arnd's suggestion to set DPKG_*_APPEND variables to
modify dpkg-buildflags. Not every package uses these flags, but a
majority do. For a survey, this is probably good enough.
I would love to do that for m68k as well. We could use this opportunity to >rebuild the m68k port with 32-bit alignment which would solve quite a number >of problems since many projects like LLVM and Qt assume a minimum alignment >of 32 bits while m68k still defaults to 16 bits.
Since the time64 rebootstrap would break the ABI anyway, we could use to fix >alignment issue on m68k once and for all :-).
I was also wondering about this Y2038 thingy and did some experiments.
I'm reporting what I found to document it, but don't see much actionable stuff here. Many thanks to Arnd Bergmann for his input.
Attempt #1: rebootstrap
Given that I develop rebootstrap, attempting to use it for a time64
bootstrap seemed quite natural. I've been talking to this with Steve
multiple times including DC22. The question was how to plug it in. In
the end I went for Arnd's suggestion to set DPKG_*_APPEND variables to
modify dpkg-buildflags. Not every package uses these flags, but a
majority do. For a survey, this is probably good enough.
I don't want to be rude, but I really don't see how m68k fits here. Of course, feel free to do a rebootstrap if you like, but I genuinely
don't see any great need for it.
likely to still be in routine use beyond 2038
Given that I develop rebootstrap, attempting to use it for a time64 bootstrap seemed quite natural. I've been talking to this with Steve multiple times including DC22. The question was how to plug it in. In
the end I went for Arnd's suggestion to set DPKG_*_APPEND variables to modify dpkg-buildflags. Not every package uses these flags, but a
majority do. For a survey, this is probably good enough.
I would love to do that for m68k as well. We could use this opportunity to rebuild the m68k port with 32-bit alignment which would solve quite a number of problems since many projects like LLVM and Qt assume a minimum alignment of 32 bits while m68k still defaults to 16 bits.
I would love to do that for m68k as well. We could use this opportunity to >rebuild the m68k port with 32-bit alignment which would solve quite a number >of problems since many projects like LLVM and Qt assume a minimum alignment >of 32 bits while m68k still defaults to 16 bits.
Hi,
Steve McIntyre wrote:
likely to still be in routine use beyond 2038
Sidenote towards ISO 9660 image producers:
Don't forget to check from time to time whether Linux removed the
int bottleneck in fs/isofs/.
See:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627#38
The bug report was originally about a Y2028 rollover caused by 8-bit signedness. It was closed after
https://github.com/torvalds/linux/commit/34be4dbf87fc
which left the int problem for future adventures.
Currently it's still "int iso_date()" in:
https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h line 109
https://github.com/torvalds/linux/blob/master/fs/isofs/util.c line 19
Have a nice day :)
On Tue, Oct 18, 2022, at 16:41, Thomas Schmitt wrote:
Currently it's still "int iso_date()" in:
https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h line 109
https://github.com/torvalds/linux/blob/master/fs/isofs/util.c line 19
Have a nice day :)
That's just a trivially fixed bug, right? I don't recall
ever seeing a bug report or a patch for it in the past. Would
you like to send the patch, or should I?
That's just a trivially fixed bug, right?
I don't recall ever seeing a bug report or a patch for it in the past.
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.)
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.
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 ?
https://lore.kernel.org/linux-scsi/20201120140633.1673-1-scdbackup@gmx.net/T/
https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbackup@gmx.net/T/
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,
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 mainly care about the y2038 issue here,
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
Well, that's quite disjoint from the list which i figured out:
linux-kernel@vger.kernel.org
linux-scsi@vger.kernel.org
axboe@kernel.dk
jejb@linux.ibm.com
martin.petersen@oracle.com
Can you rebase the patch on top of v6.1-rc1 and send it to
this list of people?
I know the word "rebase" but cannot promise that i can fill it with
substance soon ...
What kernel branches should i choose for sr and for isofs ?
I mainly care about the y2038 issue here,
If you want to do us both a favor then bring the changes from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627#38
into the kernel.
Feel free to take my reasoning and demonstration text. The code change is trivial.
It might be worth to verify my claims:
The only callers of iso_date() are in isofs/inode.c and isofs/rock.c
and put the result into struct inode.i_{a,c,m}time.tv_sec which is
of type time64_t.
The time value of iso_date() essentially stems from mktime64().
and to exercise the demonstration by a xorriso-made ISO.
This would be the correct list for the cdrom driver patches,
my list above would be for the isofs time64 patch.
It's generally ok to just use the latest -rc1 (right now 6.1-rc1)
If you want to do us both a favor then bring the changes from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800627#38
into the kernel.
Done now.
Can you rebase the patch on top of v6.1-rc1
What kernel branches should i choose for sr and for isofs ?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 107:53:16 |
| Calls: | 6,700 |
| Files: | 12,232 |
| Messages: | 5,348,424 |