Re: [PATCH 10/13] media: adv7604 prevent underflow condition when reporting colorspace

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Wed, 16 Oct 2024 13:58:48 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 16/10/2024 13:24, Mauro Carvalho Chehab wrote:
> > Em Wed, 16 Oct 2024 12:57:53 +0200
> > Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> >   
> >> On 16/10/2024 12:22, Mauro Carvalho Chehab wrote:  
> >>> Currently, adv76xx_log_status() reads some date using
> >>> io_read() which may return negative values. The current logi
> >>> doesn't check such errors, causing colorspace to be reported
> >>> on a wrong way at adv76xx_log_status().
> >>>
> >>> If I/O error happens there, print a different message, instead
> >>> of reporting bogus messages to userspace.
> >>>
> >>> Fixes: 54450f591c99 ("[media] adv7604: driver for the Analog Devices ADV7604 video decoder")
> >>> Cc: stable@vger.kernel.org    
> >>
> >> Not really a fix since this would just affect logging for debugging
> >> purposes. I would personally just drop the Fixes and Cc tag.  
> > 
> > The issue is on a VIDIOC_ ioctl, so part of media API. Ok, this is
> > used only for debugging purposes and should, instead be implemented
> > via debugfs, etc, but, in summary: it is what it is: part of the V4L2
> > uAPI.  
> 
> The ioctl, yes, but what it logs to the kernel log isn't part of the ABI.
> That can change.

Sure, logs can change, but this is an user-visible bug.

> I think it is overkill to send this to stable for an old chip that almost
> nobody uses, and that requires an i2c read to go wrong for it to produce
> a wrong debug message. It seems an unnecessary waste of time.

Agreed. Will drop cc stable.

> > 
> > -
> > 
> > Now, the question about what should have Fixes: tag and what
> > shouldn't is a different matter. I've saw long discussions about
> > that at the kernel mailing lists. In the particular case of y2038,
> > I'm pretty sure I saw some of them with Fixes tag on it.  
> 
> But patch 13/13 doesn't affect the operation either, again it is just
> an incorrect log message that can only go wrong if Pulse-Eight still
> sells that device in 2038 with a firmware build date >= 2038. 

> And v6.12 is guaranteed to be EOL in 2038 :-)

We can't count on it. Civil infrastructure is now working with a 10 years
SLTS:

	https://www.linuxfoundation.org/press/civil-infrastructure-platform-expands-slt-stable-kernel-program

I heard somewhere that having a 15 years or 20 years stable Kernel is a
need for certain usages.

Even commercial distros have a minimum of 10 years as LTS.

Suse is now working with a 13-years support. Both Canonical and Red Hat
announced a 12-years ELTS support. As they usually takes the last year's 
LTS Kernel, it means support will end with a 14 years old Kernel (so, 
support will end in 2037 or 2038 if they release an LTS distro next year),
and don't decide to extend it further.

I also heard during LPC that there's an increased pressure from Linux
customers from commercial distros to extend it even further.


Thanks,
Mauro