On Fri, 6 Jun 2025 02:56:21 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx.
