Re: [patch 3/3] timerfd: Implement write method

[Thomas Gleixner]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/