RE: proc_lseek backport request

[David Laight <David.Laight@ACULAB.COM>]

From: Greg KH 
> Sent: Thursday, August 17, 2023 3:43 PM
> 
> On Thu, Aug 17, 2023 at 11:22:30AM +0200, t.martitz@avm.de wrote:
> > Dear stable team,
> >
> > I'm asking that
> >
> > commit 3f61631d47f1 ("take care to handle NULL ->proc_lseek()")
> >
> > gets backported to the stable and LTS kernels down to 5.10.
> >
> > Background:
> > We are in the process of upgrading our kernels. One target kernel
> > is based on 5.15 LTS.
> >
> > Here we found that, if proc file drivers do not implement proc_lseek,
> > user space crashes easily, because various library routines internally
> > perform lseek(2). The crash happens in proc_reg_llseek, where it
> > wants to jump to a NULL pointer.
> >
> > We could, arguably, fix these drivers to use ".proc_lseek = no_llseek".
> > But this doesn't seem like a worthwhile path forward, considering that
> > latest Linux kernels (including 6.1 LTS) allow proc_lseek == NULL again
> > and *remove* no_lseek. Essentially, on HEAD, it's best practice to leave
> > proc_lseek == NULL.
> > Therefore, I ask that the above procfs fix gets backported so that our
> > drivers can work across all kernel versions, including latest 6.x.

Wrong patch and wrong default behaviour.
See d4455faccd.

All the NULL got converted to default_llseek().

> Attempting to keep kernel code outside of the kernel tree is, on
> purpose, very expensive in time and resources.  The very simple way to
> solve this is to get your drivers merged properly into the mainline
> kernel tree.

I've got some of those, you really wouldn't want them.
They are audio/telephony drivers for some very specific hardware.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)