Messages in this thread | | | Date | Thu, 22 May 2014 07:12:30 +0900 (JST) | From | Thomas Gleixner <> | Subject | Re: [patch 3/3] timerfd: Implement write method |
| |
On Thu, 22 May 2014, Cyrill Gorcunov wrote: > On Thu, May 22, 2014 at 06:43:08AM +0900, Thomas Gleixner wrote: > > On Tue, 29 Apr 2014, Cyrill Gorcunov wrote: > > > +static ssize_t timerfd_write(struct file *file, const char __user *buf, > > > + size_t count, loff_t *ppos) > > > +{ > > > + struct timerfd_ctx *ctx = file->private_data; > > > + u64 ticks = 0; > > > + > > > + if (count < sizeof(ticks)) > > > + return -EINVAL; > > > + > > > + if (get_user(ticks, (u64 __user *) buf)) > > > + return -EFAULT; > > > + > > > + spin_lock_irq(&ctx->wqh.lock); > > > + ctx->ticks = ticks; > > > > So what wakes a potential waiter in read/poll? > > Why should it? You mean the scenario when timer is armed then > someone writes nonzero @ticks and we should wake waiters? > The idea was to setup this ticks on timer restore without > waking anyone. If it breaks the logic of timerfd in general, > then sure I need to rework. Hm?
There is a world outside of checkpoint/restore, really.
So what's the semantics of that write function? We really want to have that agreed on and documented in the man page.
Right now the write will just update the ticks and nothing else. So what if there is a waiter already? What if there is a timer armed?
Can you please describe how checkpoint/restore is going to use all of this. How is the timer restored and how/when is the reader which was waiting in read/poll at the time of suspend reattached to it.
Thanks,
tglx
| |