From: Davi Arnaut <davi@haxent.com.br>
To: tglx@linutronix.de
Cc: Andrew Morton <akpm@linux-foundation.org>,
Davide Libenzi <davidel@xmailserver.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch 09/22] pollfs: pollable hrtimers
Date: Wed, 02 May 2007 20:00:50 -0300 [thread overview]
Message-ID: <46391822.1000707@haxent.com.br> (raw)
In-Reply-To: <1178140567.2340.16.camel@localhost.localdomain>
Thomas Gleixner wrote:
> On Wed, 2007-05-02 at 02:22 -0300, Davi Arnaut wrote:
>> plain text document attachment (pollfs-timer.patch)
>> Per file descriptor high-resolution timers. A classic unix file interface for
>> the POSIX timer_(create|settime|gettime|delete) family of functions.
>>
>> Signed-off-by: Davi E. M. Arnaut <davi@haxent.com.br>
>
> Nacked-by-me.
>
> Aside of the fact, that it is a bad clone of the timerfd code, it is
> simply broken and untested.
I've made it by the same time of timerfd, I even sent it to Davide and
the list. "Clone" is a bit of overstatment, timerfd is not bugged as this :)
>> +
>> +struct hrtimerspec {
>> + int flags;
>> + clockid_t clock;
>> + struct itimerspec expr;
>> +};
>
> How exactly knows userspace what a struct hrtimerspec is ? Is the c file
> exported as a header ?
Will move then all to another header later.
>> +static ssize_t read(struct pfs_timer *evs, struct itimerspec __user *uspec)
>> +{
>> + int ret = -EAGAIN;
>> + ktime_t remaining = {};
>> + unsigned long overruns = 0;
>> + struct itimerspec spec = {};
>> + struct hrtimer *timer = &evs->timer;
>> +
>> + spin_lock_irq(&evs->lock);
>> +
>> + if (!evs->overruns)
>> + goto out_unlock;
>> +
>> + if (hrtimer_active(timer))
>> + remaining = hrtimer_get_remaining(timer);
>> + else if (evs->interval.tv64 > 0)
>> + overruns = hrtimer_forward(timer, hrtimer_cb_get_time(timer),
>> + evs->interval);
>
> Where is the logic here ?
Return the remaing time for timer firing, or rearm the timer. And its
pretty broken because of the first if and I forgot to reset overruns.
> If no overrun, return remaining time = 0
>
> If active, return the real remaining time. This path is never hit, as
> the timer is nowhere restarted.
>
> If not active, return remanining time = 0. How does the caller know how
> many events are missed ?
>
>> + ret = -EOVERFLOW;
>> + if (overruns > (ULONG_MAX - evs->overruns))
>> + goto out_unlock;
>> + else
>> + evs->overruns += overruns;
>
> Interesting feature. evs->overruns is adding up forever and then limited
> to ULONG_MAX
See third comment!
>> +static enum hrtimer_restart timer_fn(struct hrtimer *timer)
>> +{
>> + struct pfs_timer *evs = container_of(timer, struct pfs_timer, timer);
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&evs->lock, flags);
>> + /* timer tick, interval has elapsed */
>> + if (!evs->overruns++)
>> + wake_up_all(&evs->wait);
>
> Cool. Waiters, which came after the first event are stuck. Simply
> because there is no second event.
See third comment!
>> +static ssize_t write(struct pfs_timer *evs,
>> + const struct hrtimerspec __user *uspec)
>> +{
>> + struct hrtimerspec spec;
>
> See first comment !
>
>> + if (copy_from_user(&spec, uspec, sizeof(spec)))
>> + return -EFAULT;
>> +
>> + if (spec_invalid(&spec))
>> + return -EINVAL;
>> +
>> + rearm_timer(evs, &spec);
>> +
>> + return 0;
>> +}
>> +
>> +static int poll(struct pfs_timer *evs)
>> +{
>> + int ret;
>> +
>> + ret = evs->overruns ? POLLIN : 0;
>> +
>> + return ret;
>> +}
>
> Creative lockless programming style with 4 lines overhead and a
> guaranteed return POLLIN after the first timer event. This is really
> cute as it covers the missing timer restart and guarantees 100% CPU load
> for ever. Hmm, maybe it's correct: polling should loop for ever,
> shouldn't it ?
See third comment! -- It will remain lockless, as reading and setting
this data type is guaranteed to happen atomically.
>> +static const struct pfs_operations timer_ops = {
>> + .read = PFS_READ(read, struct pfs_timer, struct itimerspec),
>> + .write = PFS_WRITE(write, struct pfs_timer, struct hrtimerspec),
>> + .poll = PFS_POLL(poll, struct pfs_timer),
>> + .release = PFS_RELEASE(release, struct pfs_timer),
>> + .rsize = sizeof(struct itimerspec),
>> + .wsize = sizeof(struct hrtimerspec),
>
> See first comment !
This has nothing to do with user space, or you got lost in comments
references.
--
Davi Arnaut
next prev parent reply other threads:[~2007-05-02 23:00 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-02 5:22 [patch 00/22] pollfs: filesystem abstraction for pollable objects Davi Arnaut
2007-05-02 5:22 ` [patch 01/22] pollfs: kernel-side API header Davi Arnaut
2007-05-02 5:22 ` [patch 02/22] pollfs: file system operations Davi Arnaut
2007-05-02 5:22 ` [patch 03/22] pollfs: asynchronously wait for a signal Davi Arnaut
2007-05-02 5:22 ` [patch 04/22] pollfs: pollable signal Davi Arnaut
2007-05-02 5:22 ` [patch 05/22] pollfs: pollable signal compat code Davi Arnaut
2007-05-02 5:22 ` [patch 06/22] pollfs: export the plsignal system call Davi Arnaut
2007-05-02 5:22 ` [patch 07/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02 5:22 ` [patch 08/22] pollfs: x86_64, " Davi Arnaut
2007-05-02 5:22 ` [patch 09/22] pollfs: pollable hrtimers Davi Arnaut
2007-05-02 21:16 ` Thomas Gleixner
2007-05-02 23:00 ` Davi Arnaut [this message]
2007-05-02 5:22 ` [patch 10/22] pollfs: export the pltimer system call Davi Arnaut
2007-05-02 5:22 ` [patch 11/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02 5:22 ` [patch 12/22] pollfs: x86_64, " Davi Arnaut
2007-05-02 5:22 ` [patch 13/22] pollfs: asynchronous futex wait Davi Arnaut
2007-05-02 5:22 ` [patch 14/22] pollfs: pollable futex Davi Arnaut
2007-05-02 5:54 ` Eric Dumazet
2007-05-02 6:16 ` Davi Arnaut
2007-05-02 6:39 ` Eric Dumazet
2007-05-02 6:54 ` Davi Arnaut
2007-05-02 7:11 ` Davi Arnaut
2007-05-02 7:40 ` Ulrich Drepper
2007-05-02 7:55 ` Eric Dumazet
2007-05-02 8:08 ` Ulrich Drepper
2007-05-02 8:49 ` Eric Dumazet
2007-05-02 16:39 ` Ulrich Drepper
2007-05-02 16:59 ` Davi Arnaut
2007-05-02 17:10 ` Ulrich Drepper
2007-05-02 17:29 ` Davide Libenzi
2007-05-02 17:53 ` Ulrich Drepper
2007-05-02 18:21 ` Davide Libenzi
2007-05-03 13:46 ` Ulrich Drepper
2007-05-03 18:24 ` Davide Libenzi
2007-05-03 19:03 ` Ulrich Drepper
2007-05-03 22:14 ` Davide Libenzi
2007-05-04 15:28 ` Ulrich Drepper
2007-05-04 19:15 ` Davide Libenzi
2007-05-04 19:20 ` 2.6.20.4 / 2.6.21.1 AT91SAM9260-EK oops Ryan Ordway
2007-05-04 23:38 ` [patch 14/22] pollfs: pollable futex Ulrich Drepper
2007-05-05 18:54 ` Davide Libenzi
2007-05-06 7:50 ` Ulrich Drepper
2007-05-06 19:47 ` Davide Libenzi
2007-05-06 19:54 ` Andrew Morton
2007-05-06 20:18 ` Davide Libenzi
2007-05-06 21:57 ` Davi Arnaut
2007-05-07 5:33 ` Ulrich Drepper
2007-05-07 5:46 ` Ulrich Drepper
2007-05-02 17:37 ` Davi Arnaut
2007-05-02 17:49 ` Ulrich Drepper
2007-05-02 18:05 ` Davi Arnaut
2007-05-03 13:40 ` Ulrich Drepper
2007-05-02 12:20 ` Davi Arnaut
2007-05-02 12:39 ` Davi Arnaut
2007-05-02 16:46 ` Ulrich Drepper
2007-05-02 17:05 ` Davi Arnaut
2007-05-02 5:22 ` [patch 15/22] pollfs: export the plfutex system call Davi Arnaut
2007-05-02 5:22 ` [patch 16/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02 5:22 ` [patch 17/22] pollfs: x86_64, " Davi Arnaut
2007-05-02 5:22 ` [patch 18/22] pollfs: check if a AIO event ring is empty Davi Arnaut
2007-05-02 5:22 ` [patch 19/22] pollfs: pollable aio Davi Arnaut
2007-05-02 5:22 ` [patch 20/22] pollfs: export the plaio system call Davi Arnaut
2007-05-02 5:22 ` [patch 21/22] pollfs: x86, wire up " Davi Arnaut
2007-05-02 5:22 ` [patch 22/22] pollfs: x86_64, " Davi Arnaut
2007-05-02 6:05 ` [patch 00/22] pollfs: filesystem abstraction for pollable objects Andrew Morton
2007-05-02 17:28 ` Davide Libenzi
2007-05-02 17:47 ` Davi Arnaut
2007-05-02 18:23 ` Davide Libenzi
2007-05-02 18:50 ` Davi Arnaut
2007-05-02 19:42 ` Davide Libenzi
2007-05-02 20:11 ` Davi Arnaut
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=46391822.1000707@haxent.com.br \
--to=davi@haxent.com.br \
--cc=akpm@linux-foundation.org \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.