All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Zizhi Wo <wozizhi@huawei.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org,
	akpm@linux-foundation.org, jlayton@kernel.org,
	dchinner@redhat.com, adobriyan@gmail.com,
	yang.lee@linux.alibaba.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, yangerkun@huawei.com
Subject: Re: [PATCH next V3] proc: support file->f_pos checking in mem_lseek
Date: Fri, 10 Nov 2023 09:30:37 +0100	[thread overview]
Message-ID: <20231110083037.GA3381@redhat.com> (raw)
In-Reply-To: <20231110151928.2667204-1-wozizhi@huawei.com>

On 11/10, Zizhi Wo wrote:
>
> From: WoZ1zh1 <wozizhi@huawei.com>
>
> In mem_lseek, file->f_pos may overflow. And it's not a problem that
> mem_open set file mode with FMODE_UNSIGNED_OFFSET(memory_lseek). However,
> another file use mem_lseek do lseek can have not FMODE_UNSIGNED_OFFSET
> (kpageflags_proc_ops/proc_pagemap_operations...), so in order to prevent
> file->f_pos updated to an abnormal number, fix it by checking overflow and
> FMODE_UNSIGNED_OFFSET.

I am wondering if we can do something like the patch below instead...

but I agree that the "proc_lseek == mem_lseek" in proc_reg_open()
looks ugly.

Oleg.

diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 532dc9d240f7..af7e6b1e17fe 100644
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -496,6 +496,8 @@ static int proc_reg_open(struct inode *inode, struct file *file)
 
 	if (!pde->proc_ops->proc_lseek)
 		file->f_mode &= ~FMODE_LSEEK;
+	else if (pde->proc_ops->proc_lseek == mem_lseek)
+		file->f_mode |= FMODE_UNSIGNED_OFFSET;
 
 	if (pde_is_permanent(pde)) {
 		open = pde->proc_ops->proc_open;
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 3dd5be96691b..729b28ad1a96 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1748,7 +1748,9 @@ static int pagemap_open(struct inode *inode, struct file *file)
 	mm = proc_mem_open(inode, PTRACE_MODE_READ);
 	if (IS_ERR(mm))
 		return PTR_ERR(mm);
+
 	file->private_data = mm;
+	file->f_mode |= FMODE_UNSIGNED_OFFSET;
 	return 0;
 }
 


      parent reply	other threads:[~2023-11-10 17:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-10 15:19 [PATCH next V3] proc: support file->f_pos checking in mem_lseek Zizhi Wo
2023-11-10  8:21 ` Al Viro
2023-11-10  8:30 ` Oleg Nesterov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231110083037.GA3381@redhat.com \
    --to=oleg@redhat.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wozizhi@huawei.com \
    --cc=yang.lee@linux.alibaba.com \
    --cc=yangerkun@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.