Re: [PATCH] proc: clear FMODE_LSEEK flag correctly for permanent pde

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 6 Jun 2025 02:56:21 +0100 Al Viro <viro@zeniv.linux.org.uk> wrote:

> On Thu, Jun 05, 2025 at 02:44:15PM -0700, Andrew Morton wrote:
> > On Thu, 5 Jun 2025 14:52:52 +0800 wangzijie <wangzijie1@honor.com> wrote:
> > 
> > > Clearing FMODE_LSEEK flag should not rely on whether proc_open ops exists,
> > 
> > Why is this?
> > 
> > > fix it.
> > 
> > What are the consequences of the fix?  Is there presently some kernel
> > misbehavior?
> 
> At a guess, that would be an oops due to this:
>         if (pde_is_permanent(pde)) {
> 		return pde->proc_ops->proc_lseek(file, offset, whence);
> 	} else if (use_pde(pde)) {
> 		rv = pde->proc_ops->proc_lseek(file, offset, whence);
> 		unuse_pde(pde);
> 	}
> in proc_reg_llseek().  No FMODE_LSEEK == "no seeks for that file, just
> return -ESPIPE".  It is set by do_dentry_open() if you have NULL
> ->llseek() in ->f_op; the reason why procfs needs to adjust that is
> the it has uniform ->llseek, calling the underlying method for that 
> proc_dir_entry.  So if it's NULL, we need ->open() (also uniform,
> proc_reg_open() for all of those) to clear FMODE_LSEEK from ->f_mode.
> 
> The thing I don't understand is where the hell had proc_reg_open()
> changed in that way - commit refered in the patch doesn't exist in
> mainline, doesn't seem to be in -next or -stable either.

It's a fix against the very recently merged
https://lkml.kernel.org/r/20250528034756.4069180-1-wangzijie1@honor.com.