From: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>
To: Am?rico_Wang <xiyou.wangcong@gmail.com>
Cc: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>,
"Wu Fengguang" <fengguang.wu@intel.com>,
viro@zeniv.linux.org.uk,
"Andrew Morton" <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"hugh.dickins@tiscali.co.uk" <hugh.dickins@tiscali.co.uk>,
oleg@redhat.com
Subject: Re: [RFC][PATCH][bugfix] more checks for negative f_pos handling (Was Re: Question: how to handle too big f_pos
Date: Wed, 16 Sep 2009 21:06:48 +0900 (JST) [thread overview]
Message-ID: <84889d57a3943f47b3ee0df6d1ff25c2.squirrel@webmail-b.css.fujitsu.com> (raw)
In-Reply-To: <2375c9f90909160213q7e011117hd4e4ea2f386ed42a@mail.gmail.com>
Américo_Wang wrote:
> On Wed, Sep 16, 2009 at 4:44 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>> Ah, sorry. I should CC: you.
>
>
> No problem. :)
>
>>> > --- mmotm-2.6.31-Sep14.orig/fs/proc/base.c
>>> > +++ mmotm-2.6.31-Sep14/fs/proc/base.c
>>> > @@ -903,18 +903,30 @@ out_no_task:
>>> >
>>> > ?loff_t mem_lseek(struct file *file, loff_t offset, int orig)
>>> > ?{
>>> > + ? ? ? struct task_struct *task =
>>> get_proc_task(file->f_path.dentry->d_inode);
>>> > + ? ? ? unsigned long long new_offset = -EINVAL;
>>>
>>>
>>> Why not make 'new_offset' as loff_t? This can make your code easier.
>>>
>> loff_t is "long long", I wanted "unsigned long long" for showing
>> f_pos here is treated as "unsigned".
>>
>
>
> Yeah, the same as for __verify_negative_pos_range(), right...
>
>
> <snip>
>
>>> > ? ? ? ?}
>>> > - ? ? ? force_successful_syscall_return();
>>> > - ? ? ? return file->f_pos;
>>> > + ? ? ? if (new_offset < (unsigned long long)TASK_SIZE_OF(task)) {
>>>
>>>
>>> Hmm, why this check?
>>>
>> 2 reasons.
>>
>> ?1. If this lseek has to check something, this is it.
>> ?2. On architecture where 32bit program can ran on 64bit,
>> ? ? moving f_pos above 4G is out-of-range, for example.
>>
>> But mem_read() will catch any bad f_pos, anyway. So, just making
>> allow all f_pos here is maybe a choice. Considering lseek,
>> providing this range check here is not so bad.
>
> Ok, I misunderstood the macro 'TASK_SIZE_OF', then no problem.
>
> Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
>
Ah, very sorry. I noticed I didn't handle pread/pwrite, splice, etc...
I'll do retry.
Sorry,
-Kame
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2009-09-16 12:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-14 3:29 [PATCH] devmem: handle partial kmem write/read Wu Fengguang
2009-09-14 4:34 ` Wu Fengguang
2009-09-15 0:24 ` KAMEZAWA Hiroyuki
2009-09-15 1:52 ` KAMEZAWA Hiroyuki
2009-09-15 2:05 ` Wu Fengguang
2009-09-15 2:02 ` Wu Fengguang
2009-09-15 2:31 ` KAMEZAWA Hiroyuki
2009-09-15 2:57 ` Wu Fengguang
2009-09-15 7:58 ` Question: how to handle too big f_pos " KAMEZAWA Hiroyuki
2009-09-15 8:11 ` Wu Fengguang
2009-09-15 9:52 ` Hugh Dickins
2009-09-16 5:29 ` [RFC][PATCH][bugfix] more checks for negative f_pos handling (Was Re: Question: how to handle too big f_pos KAMEZAWA Hiroyuki
2009-09-16 8:20 ` Américo Wang
2009-09-16 8:44 ` KAMEZAWA Hiroyuki
2009-09-16 9:13 ` Américo Wang
2009-09-16 12:06 ` KAMEZAWA Hiroyuki [this message]
2009-09-17 3:06 ` Américo Wang
2009-09-17 5:53 ` [RFC][PATCH][bugfix] more checks for negative f_pos handling v2 KAMEZAWA Hiroyuki
2009-09-17 6:07 ` [RFC][PATCH][bugfix] more checks for negative f_pos handling v3 KAMEZAWA Hiroyuki
2009-09-17 6:21 ` Wu Fengguang
2009-09-17 6:31 ` KAMEZAWA Hiroyuki
2009-09-17 6:53 ` Wu Fengguang
2009-09-17 6:51 ` [RFC][PATCH][bugfix] more checks for negative f_pos handling v4 KAMEZAWA Hiroyuki
2009-09-17 7:14 ` Wu Fengguang
2009-09-17 7:23 ` KAMEZAWA Hiroyuki
2009-09-17 7:30 ` Wu Fengguang
2009-09-17 9:42 ` Wu Fengguang
2009-09-17 10:54 ` KAMEZAWA Hiroyuki
2009-09-17 10:58 ` KAMEZAWA Hiroyuki
2009-09-17 12:40 ` Wu Fengguang
2009-09-18 0:02 ` KAMEZAWA Hiroyuki
2009-09-18 2:25 ` Américo Wang
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=84889d57a3943f47b3ee0df6d1ff25c2.squirrel@webmail-b.css.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xiyou.wangcong@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome