Re: another attempt at Y2038

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

i wrote:
> > 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/

Arnd Bergmann wrote:
> These look like you did everything right, and they should have been
> picked up by the scsi maintainers.

I thought the same, but also that insisting, screaming, or trampling
won't help.


> If you ever re-send them, I would
> suggest putting the maintainers in 'To:' for the email and the mailing
> list in Cc,

I remember to have looked into the MAINTAINERS file and the git log for
names.
(In the case of the powerpc64 Oops, it looks like i added you in Cc:.
If i only could remember why ...)


> 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. So if at all, i would be fully recognized by "Suggested-by:".

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.


Have a nice day :)

Thomas