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

[Al Viro <viro@zeniv.linux.org.uk>]

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.