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.
