From: Fam Zheng <famz-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Seymour, Shane M" <shane.seymour-VXdhtT5mjnY@public.gmane.org>
Cc: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
"x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
David Herrmann
<dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>,
Miklos Szeredi <mszeredi-AlSwsSmVLrQ@public.gmane.org>,
David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>,
Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
Heiko Carstens
<heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
Rasmus Villemoes
<linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org>,
Rashika Kheria
<rashika.kheria-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Hugh Dickins <hughd>
Subject: Re: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
Date: Mon, 16 Feb 2015 16:12:06 +0800 [thread overview]
Message-ID: <20150216081119.GA9964@cpc-pc.redhat.com> (raw)
In-Reply-To: <DDB9C85B850785449757F9914A034FCB3BF41130-4I1V4pQFGigSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
Hi Seymour,
On Mon, 02/16 07:25, Seymour, Shane M wrote:
> I found the manual pages really confusing so I had a go at rewriting
> them - there were places in the manual page that didn't match the
> functionality provided by your code as well as I could tell).
Could you point which places don't match the code?
>
> My apologies for a few formatting issues though. I still don't like
> parts of epoll_pwait1 but it's less confusing than it was.
Any other than the timespec question don't you like?
>
> You are free to take some or all or none of the changes.
>
> I did have a question I marked with **** below about what you
> describe and what your code does.
>
<snip>
> The timeout member specifies the minimum time that epoll_wait(2) will
> block. The time spent waiting will be rounded up to the clock
> granularity. Kernel scheduling delays mean that the blocking
> interval may overrun by a small amount. Specifying a -1 for either
> tv_sec or tv_nsec member of the struct timespec timeout will cause
> causes epoll_pwait1(2) to block indefinitely. Specifying a timeout
> equal to zero (both tv_sec or tv_nsec member of the struct timespec
> timeout are zero) causes epoll_wait(2) to return immediately, even
> if no events are available.
>
> **** Are you really really sure about this for the -1 stuff? your code copies
> in the timespec and just passes it to timespec_to_ktime:
>
> + if (copy_from_user(&p, params, sizeof(p)))
> + return -EFAULT;
> ...
> + kt = timespec_to_ktime(p.timeout);
>
> Compare that to something like the futex syscall which does this:
>
> if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
> return -EFAULT;
> if (!timespec_valid(&ts))
> return -EINVAL;
>
> t = timespec_to_ktime(ts);
>
> If the timespec is not valid it returns -EINVAL back to user space. With your
> settings of tv_sec and/or tv_usec to -1 are you relying on a side effect of
> the conversion that could break your code in the future if in the unlikely
> event someone changes timespec_to_ktime() and should it be:
>
> + if (copy_from_user(&p, params, sizeof(p)))
> + return -EFAULT;
> + if ((p.timeout.tv_sec == -1) || (p.timeout.tv_nsec == -1)) {
> + /* this is off the top of my head no idea if it will compile */
> + p.timeout.tv_sec = KTIME_SEC_MAX;
> + p.timeout.tv_nsec = 0;
> + }
> + if (!timespec_valid(&p.timeout))
> + return -EINVAL;
> ...
> + kt = timespec_to_ktime(p.timeout);
OK. timespec_valid() is clear about this: negative tv_sec is invalid, so I
don't think accepting -1 from user is the right thing to do.
We cannot do pointer check as ppoll already because the structure is embedded
in epoll_wait_params.
Maybe it's best to use a flags bit (#define EPOLL_PWAIT1_BLOCK 1). What do you
think?
Fam
<snip>
WARNING: multiple messages have this Message-ID (diff)
From: Fam Zheng <famz-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: "Seymour, Shane M" <shane.seymour-VXdhtT5mjnY@public.gmane.org>
Cc: Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Ingo Molnar <mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
"x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org"
<x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
David Herrmann
<dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>,
Miklos Szeredi <mszeredi-AlSwsSmVLrQ@public.gmane.org>,
David Drysdale <drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org>,
"Theodore Ts'o" <tytso-3s7WtUTddSA@public.gmane.org>,
Heiko Carstens
<heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>,
Rasmus Villemoes
<linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org>,
Rashika Kheria
<rashika.kheria-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Hugh Dickins <hughd
Subject: Re: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
Date: Mon, 16 Feb 2015 16:12:06 +0800 [thread overview]
Message-ID: <20150216081119.GA9964@cpc-pc.redhat.com> (raw)
In-Reply-To: <DDB9C85B850785449757F9914A034FCB3BF41130-4I1V4pQFGigSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
Hi Seymour,
On Mon, 02/16 07:25, Seymour, Shane M wrote:
> I found the manual pages really confusing so I had a go at rewriting
> them - there were places in the manual page that didn't match the
> functionality provided by your code as well as I could tell).
Could you point which places don't match the code?
>
> My apologies for a few formatting issues though. I still don't like
> parts of epoll_pwait1 but it's less confusing than it was.
Any other than the timespec question don't you like?
>
> You are free to take some or all or none of the changes.
>
> I did have a question I marked with **** below about what you
> describe and what your code does.
>
<snip>
> The timeout member specifies the minimum time that epoll_wait(2) will
> block. The time spent waiting will be rounded up to the clock
> granularity. Kernel scheduling delays mean that the blocking
> interval may overrun by a small amount. Specifying a -1 for either
> tv_sec or tv_nsec member of the struct timespec timeout will cause
> causes epoll_pwait1(2) to block indefinitely. Specifying a timeout
> equal to zero (both tv_sec or tv_nsec member of the struct timespec
> timeout are zero) causes epoll_wait(2) to return immediately, even
> if no events are available.
>
> **** Are you really really sure about this for the -1 stuff? your code copies
> in the timespec and just passes it to timespec_to_ktime:
>
> + if (copy_from_user(&p, params, sizeof(p)))
> + return -EFAULT;
> ...
> + kt = timespec_to_ktime(p.timeout);
>
> Compare that to something like the futex syscall which does this:
>
> if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
> return -EFAULT;
> if (!timespec_valid(&ts))
> return -EINVAL;
>
> t = timespec_to_ktime(ts);
>
> If the timespec is not valid it returns -EINVAL back to user space. With your
> settings of tv_sec and/or tv_usec to -1 are you relying on a side effect of
> the conversion that could break your code in the future if in the unlikely
> event someone changes timespec_to_ktime() and should it be:
>
> + if (copy_from_user(&p, params, sizeof(p)))
> + return -EFAULT;
> + if ((p.timeout.tv_sec == -1) || (p.timeout.tv_nsec == -1)) {
> + /* this is off the top of my head no idea if it will compile */
> + p.timeout.tv_sec = KTIME_SEC_MAX;
> + p.timeout.tv_nsec = 0;
> + }
> + if (!timespec_valid(&p.timeout))
> + return -EINVAL;
> ...
> + kt = timespec_to_ktime(p.timeout);
OK. timespec_valid() is clear about this: negative tv_sec is invalid, so I
don't think accepting -1 from user is the right thing to do.
We cannot do pointer check as ppoll already because the structure is embedded
in epoll_wait_params.
Maybe it's best to use a flags bit (#define EPOLL_PWAIT1_BLOCK 1). What do you
think?
Fam
<snip>
WARNING: multiple messages have this Message-ID (diff)
From: Fam Zheng <famz@redhat.com>
To: "Seymour, Shane M" <shane.seymour@hp.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
"x86@kernel.org" <x86@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@amacapital.net>,
David Herrmann <dh.herrmann@gmail.com>,
Alexei Starovoitov <ast@plumgrid.com>,
Miklos Szeredi <mszeredi@suse.cz>,
David Drysdale <drysdale@google.com>,
Oleg Nesterov <oleg@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Vivek Goyal <vgoyal@redhat.com>,
Mike Frysinger <vapier@gentoo.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Rashika Kheria <rashika.kheria@gmail.com>,
Hugh Dickins <hughd@google.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Omar Sandoval <osandov@osandov.com>
Subject: Re: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
Date: Mon, 16 Feb 2015 16:12:06 +0800 [thread overview]
Message-ID: <20150216081119.GA9964@cpc-pc.redhat.com> (raw)
In-Reply-To: <DDB9C85B850785449757F9914A034FCB3BF41130@G9W0766.americas.hpqcorp.net>
Hi Seymour,
On Mon, 02/16 07:25, Seymour, Shane M wrote:
> I found the manual pages really confusing so I had a go at rewriting
> them - there were places in the manual page that didn't match the
> functionality provided by your code as well as I could tell).
Could you point which places don't match the code?
>
> My apologies for a few formatting issues though. I still don't like
> parts of epoll_pwait1 but it's less confusing than it was.
Any other than the timespec question don't you like?
>
> You are free to take some or all or none of the changes.
>
> I did have a question I marked with **** below about what you
> describe and what your code does.
>
<snip>
> The timeout member specifies the minimum time that epoll_wait(2) will
> block. The time spent waiting will be rounded up to the clock
> granularity. Kernel scheduling delays mean that the blocking
> interval may overrun by a small amount. Specifying a -1 for either
> tv_sec or tv_nsec member of the struct timespec timeout will cause
> causes epoll_pwait1(2) to block indefinitely. Specifying a timeout
> equal to zero (both tv_sec or tv_nsec member of the struct timespec
> timeout are zero) causes epoll_wait(2) to return immediately, even
> if no events are available.
>
> **** Are you really really sure about this for the -1 stuff? your code copies
> in the timespec and just passes it to timespec_to_ktime:
>
> + if (copy_from_user(&p, params, sizeof(p)))
> + return -EFAULT;
> ...
> + kt = timespec_to_ktime(p.timeout);
>
> Compare that to something like the futex syscall which does this:
>
> if (copy_from_user(&ts, utime, sizeof(ts)) != 0)
> return -EFAULT;
> if (!timespec_valid(&ts))
> return -EINVAL;
>
> t = timespec_to_ktime(ts);
>
> If the timespec is not valid it returns -EINVAL back to user space. With your
> settings of tv_sec and/or tv_usec to -1 are you relying on a side effect of
> the conversion that could break your code in the future if in the unlikely
> event someone changes timespec_to_ktime() and should it be:
>
> + if (copy_from_user(&p, params, sizeof(p)))
> + return -EFAULT;
> + if ((p.timeout.tv_sec == -1) || (p.timeout.tv_nsec == -1)) {
> + /* this is off the top of my head no idea if it will compile */
> + p.timeout.tv_sec = KTIME_SEC_MAX;
> + p.timeout.tv_nsec = 0;
> + }
> + if (!timespec_valid(&p.timeout))
> + return -EINVAL;
> ...
> + kt = timespec_to_ktime(p.timeout);
OK. timespec_valid() is clear about this: negative tv_sec is invalid, so I
don't think accepting -1 from user is the right thing to do.
We cannot do pointer check as ppoll already because the structure is embedded
in epoll_wait_params.
Maybe it's best to use a flags bit (#define EPOLL_PWAIT1_BLOCK 1). What do you
think?
Fam
<snip>
next prev parent reply other threads:[~2015-02-16 8:12 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-13 9:03 [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1 Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:03 ` [PATCH RFC v3 2/7] epoll: Specify clockid explicitly Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:03 ` [PATCH RFC v3 3/7] epoll: Extract ep_ctl_do Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:03 ` Fam Zheng
[not found] ` <1423818243-15410-1-git-send-email-famz-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-02-13 9:03 ` [PATCH RFC v3 1/7] epoll: Extract epoll_wait_do and epoll_pwait_do Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:03 ` Fam Zheng
2015-02-13 9:04 ` [PATCH RFC v3 4/7] epoll: Add implementation for epoll_ctl_batch Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` [PATCH RFC v3 5/7] x86: Hook up epoll_ctl_batch syscall Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` [PATCH RFC v3 6/7] epoll: Add implementation for epoll_pwait1 Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` [PATCH RFC v3 7/7] x86: Hook up epoll_pwait1 syscall Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:04 ` Fam Zheng
2015-02-13 9:53 ` [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1 Omar Sandoval
2015-02-13 9:53 ` Omar Sandoval
2015-02-13 9:53 ` Omar Sandoval
2015-02-15 6:44 ` Fam Zheng
2015-02-15 15:16 ` Michael Kerrisk (man-pages)
2015-02-15 15:16 ` Michael Kerrisk (man-pages)
2015-02-15 15:16 ` Michael Kerrisk (man-pages)
2015-02-15 22:00 ` Jonathan Corbet
2015-02-15 22:00 ` Jonathan Corbet
2015-02-15 22:00 ` Jonathan Corbet
[not found] ` <20150215150011.0340686c-T1hC0tSOHrs@public.gmane.org>
2015-02-16 1:02 ` Fam Zheng
2015-02-16 1:02 ` Fam Zheng
2015-02-16 1:02 ` Fam Zheng
2015-02-16 7:25 ` Seymour, Shane M
2015-02-16 7:25 ` Seymour, Shane M
2015-02-16 7:25 ` Seymour, Shane M
[not found] ` <DDB9C85B850785449757F9914A034FCB3BF41130-4I1V4pQFGigSZAcGdq5asR6epYMZPwEe5NbjCUgZEJk@public.gmane.org>
2015-02-16 8:12 ` Fam Zheng [this message]
2015-02-16 8:12 ` Fam Zheng
2015-02-16 8:12 ` Fam Zheng
2015-02-18 18:49 ` Ingo Molnar
2015-02-18 18:49 ` Ingo Molnar
2015-02-18 18:49 ` Ingo Molnar
2015-02-25 3:30 ` Fam Zheng
2015-02-25 3:30 ` Fam Zheng
2015-02-25 3:30 ` Fam Zheng
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=20150216081119.GA9964@cpc-pc.redhat.com \
--to=famz-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org \
--cc=corbet-T1hC0tSOHrs@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=dh.herrmann-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=drysdale-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=heiko.carstens-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-qQsb+v5E8BnlAoU/VqSP6n9LOBIZ5rWg@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=mingo-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=mszeredi-AlSwsSmVLrQ@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=rashika.kheria-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=shane.seymour-VXdhtT5mjnY@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=tytso-3s7WtUTddSA@public.gmane.org \
--cc=vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org \
--cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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.