Query: Y2038 patch series for 3.18 Kernel

Query: Y2038 patch series for 3.18 Kernel

[Pintu Kumar Agarwal]

Hi,

We have an arm32 based embedded product which is based on the 3.18
kernel and a simple busybox.
We wanted to support the Y2038 issue on this older kernel.
Is this feasible
Do we have the Y2038 separate patches available for both kernel and userspace ?
Or upgrading the kernel is the only option ?

Thanks,
Pintu

Re: Query: Y2038 patch series for 3.18 Kernel

[Siddh Raman Pant]

Mon, 03 Nov 2025 09:57:18 +0530 को Pintu Kumar Agarwal ने लिखा :
> We have an arm32 based embedded product which is based on the 3.18
> kernel and a simple busybox.
> We wanted to support the Y2038 issue on this older kernel.
> Is this feasible
> Do we have the Y2038 separate patches available for both kernel and userspace
> ?
> Or upgrading the kernel is the only option ?

Upgrading is a much much better option.

3.18 is extremely ancient and extremely insecure.

(Sending again as I didn't press "reply all")

Thanks,
Siddh

Re: Query: Y2038 patch series for 3.18 Kernel

[Pintu Kumar Agarwal]

On Mon, 3 Nov 2025 at 10:35, Siddh Raman Pant <sanganaka@siddh.me> wrote:
>
> Mon, 03 Nov 2025 09:57:18 +0530 को Pintu Kumar Agarwal ने लिखा :
> > We have an arm32 based embedded product which is based on the 3.18
> > kernel and a simple busybox.
> > We wanted to support the Y2038 issue on this older kernel.
> > Is this feasible
> > Do we have the Y2038 separate patches available for both kernel and userspace
> > ?
> > Or upgrading the kernel is the only option ?
>
> Upgrading is a much much better option.
>
Yes, I understand, but upgrading the kernel on this older SoC brings
more complexities, challenges and time taking.
Customers also do not agree for the upgrade at this stage and they are
looking for alternatives.
So, we are exploring both the options right now.

Are there any patchset maintained separately for this Y2038 issue for
each kernel version to have a look ?


Thanks,
Pintu

Re: Query: Y2038 patch series for 3.18 Kernel

[Greg KH]

On Tue, Nov 04, 2025 at 10:32:28AM +0530, Pintu Kumar Agarwal wrote:
> On Mon, 3 Nov 2025 at 10:35, Siddh Raman Pant <sanganaka@siddh.me> wrote:
> >
> > Mon, 03 Nov 2025 09:57:18 +0530 को Pintu Kumar Agarwal ने लिखा :
> > > We have an arm32 based embedded product which is based on the 3.18
> > > kernel and a simple busybox.
> > > We wanted to support the Y2038 issue on this older kernel.
> > > Is this feasible
> > > Do we have the Y2038 separate patches available for both kernel and userspace
> > > ?
> > > Or upgrading the kernel is the only option ?
> >
> > Upgrading is a much much better option.
> >
> Yes, I understand, but upgrading the kernel on this older SoC brings
> more complexities, challenges and time taking.
> Customers also do not agree for the upgrade at this stage and they are
> looking for alternatives.
> So, we are exploring both the options right now.
> 
> Are there any patchset maintained separately for this Y2038 issue for
> each kernel version to have a look ?

Nope, sorry.  Please just update to a newer kernel version, that is the
only way forward (and as a bonus, you actually will have tens of
thousands of bugs fixed on your system.)

good luck!

greg k-h

Re: Query: Y2038 patch series for 3.18 Kernel

[Arnd Bergmann]

On Tue, Nov 4, 2025, at 06:02, Pintu Kumar Agarwal wrote:
> On Mon, 3 Nov 2025 at 10:35, Siddh Raman Pant <sanganaka@siddh.me> wrote:
>>
>> Mon, 03 Nov 2025 09:57:18 +0530 को Pintu Kumar Agarwal ने लिखा :
>> > We have an arm32 based embedded product which is based on the 3.18
>> > kernel and a simple busybox.
>> > We wanted to support the Y2038 issue on this older kernel.
>> > Is this feasible
>> > Do we have the Y2038 separate patches available for both kernel and userspace
>> > ?
>> > Or upgrading the kernel is the only option ?
>>
>> Upgrading is a much much better option.
>>
> Yes, I understand, but upgrading the kernel on this older SoC brings
> more complexities, challenges and time taking.
> Customers also do not agree for the upgrade at this stage and they are
> looking for alternatives.
> So, we are exploring both the options right now.
>
> Are there any patchset maintained separately for this Y2038 issue for
> each kernel version to have a look ?

I used to maintain a 5.4 kernel with backports from the 5.6 patches,
but I would not recommend using that. Anything earlier than 5.4
is completely hopeless for 2038 because one would have to essentially
redo the changes from scratch.

Which chip exactly are you using?

     Arnd

Re: Query: Y2038 patch series for 3.18 Kernel

[Pintu Kumar Agarwal]

On Tue, 4 Nov 2025 at 15:18, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Nov 4, 2025, at 06:02, Pintu Kumar Agarwal wrote:
> > On Mon, 3 Nov 2025 at 10:35, Siddh Raman Pant <sanganaka@siddh.me> wrote:
> >>
> >> Mon, 03 Nov 2025 09:57:18 +0530 को Pintu Kumar Agarwal ने लिखा :
> >> > We have an arm32 based embedded product which is based on the 3.18
> >> > kernel and a simple busybox.
> >> > We wanted to support the Y2038 issue on this older kernel.
> >> > Is this feasible
> >> > Do we have the Y2038 separate patches available for both kernel and userspace
> >> > ?
> >> > Or upgrading the kernel is the only option ?
> >>
> >> Upgrading is a much much better option.
> >>
> > Yes, I understand, but upgrading the kernel on this older SoC brings
> > more complexities, challenges and time taking.
> > Customers also do not agree for the upgrade at this stage and they are
> > looking for alternatives.
> > So, we are exploring both the options right now.
> >
> > Are there any patchset maintained separately for this Y2038 issue for
> > each kernel version to have a look ?
>
> I used to maintain a 5.4 kernel with backports from the 5.6 patches,
> but I would not recommend using that. Anything earlier than 5.4
> is completely hopeless for 2038 because one would have to essentially
> redo the changes from scratch.
>
OK thanks.

> Which chip exactly are you using?
This request is for one of the legacy QC MDM 9K chipset.

Re: Query: Y2038 patch series for 3.18 Kernel

[Arnd Bergmann]

On Wed, Nov 5, 2025, at 10:47, Pintu Kumar Agarwal wrote:
> On Tue, 4 Nov 2025 at 15:18, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> Which chip exactly are you using?
> This request is for one of the legacy QC MDM 9K chipset.

Ah, I see. Support for those was never fully merged, so it's
much harder to upgrade than other platforms, especially
if you need the modem driver to work.

We do have some support for the newer sdx55/sdxx65 chips,
and much more rudimentary support for mdm9607 and mdm9615
(without modem) in mainline, but since we've never had a
fully supported board use the older chips I would not expect
them to work without additional bugfixes and a rebase of
the missing drivers.

There is of course a chance that you may get them to work
in a way that does not rely on knowing the time. If you
don't have (or use) and RTC and the system time is always
set to Jan 1 1970 on boot, this would technically work
indefinitely. Running a 3.18 kernel is obviously a bad idea
for a number of other reasons.

     Arnd

Re: Query: Y2038 patch series for 3.18 Kernel

[Pintu Kumar Agarwal]

On Thu, 6 Nov 2025 at 13:48, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Nov 5, 2025, at 10:47, Pintu Kumar Agarwal wrote:
> > On Tue, 4 Nov 2025 at 15:18, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> >> Which chip exactly are you using?
> > This request is for one of the legacy QC MDM 9K chipset.
>
> Ah, I see. Support for those was never fully merged, so it's
> much harder to upgrade than other platforms, especially
> if you need the modem driver to work.
>
Sorry for my late reply.
Yes, I see some supports are present but not fully functional.

> We do have some support for the newer sdx55/sdxx65 chips,
> and much more rudimentary support for mdm9607 and mdm9615
> (without modem) in mainline, but since we've never had a
> fully supported board use the older chips I would not expect
> them to work without additional bugfixes and a rebase of
> the missing drivers.
>
Yes, last year and this year as well we already did kernel upgrades
for some of them but few are still remaining.

> There is of course a chance that you may get them to work
> in a way that does not rely on knowing the time. If you
> don't have (or use) and RTC and the system time is always
> set to Jan 1 1970 on boot, this would technically work
> indefinitely. Running a 3.18 kernel is obviously a bad idea
> for a number of other reasons.
>
Yes, we would also like to propose for the kernel upgrade
as the last option if there are no valid alternatives.

Thank you so much Arnd for your help and guidance.

Thank you all for the discussion!

Regards,
Pintu

Re: Query: Y2038 patch series for 3.18 Kernel

[syrus]

From: [Syrus] <[syrus.lssu@ingenic.com]>

Hi Arnd, all,

Thanks for the discussion. While kernel upgrade solves Y2038 for new
projects, our legacy devices on 3.10.14 kernel face upgrade challenges
due to driver compatibility and limited resources (limited manpower, 
communication barriers between different departments and companies, etc.).

Has anyone successfully backported Y2038 fixes to older kernels like
3.10.x? I'm looking for patch summaries or experiences with such
backports, or at least a summary of the commit history that addresses
this issue. Any guidance on key subsystems to focus on would be very
helpful for maintaining our legacy devices.

Best regards,
[Syrus]

Re: Query: Y2038 patch series for 3.18 Kernel

[Arnd Bergmann]

On Tue, Jan 20, 2026, at 02:05, syrus wrote:
> From: [Syrus] <[syrus.lssu@ingenic.com]>
>
> Hi Arnd, all,
>
> Thanks for the discussion. While kernel upgrade solves Y2038 for new
> projects, our legacy devices on 3.10.14 kernel face upgrade challenges
> due to driver compatibility and limited resources (limited manpower, 
> communication barriers between different departments and companies, etc.).
>
> Has anyone successfully backported Y2038 fixes to older kernels like
> 3.10.x? I'm looking for patch summaries or experiences with such
> backports, or at least a summary of the commit history that addresses
> this issue. Any guidance on key subsystems to focus on would be very
> helpful for maintaining our legacy devices.

Hi Syrus,

As I replied earlier, anything older than 5.4 has pretty much no
chance of getting the kernel backports.

If you are specifically working on Ingenic's own SoC support,
I do think that you are in luck as these seem to be fairly well
supported in recent kernels, based on the work that Paul Cercueil
has done over the years, at least for the chips that ended up
in popular development boards and gaming handhelds (jz4725,
jz4740, jz4760, jz4770).

If there are specific drivers that are not yet supported upstream
but work on the patched 3.10 kernel, I'm sure you can find
consulting companies that are able to port those drivers as well.

     Arnd