On Wed, Jun 11, 2014 at 01:52:46PM +0400, Cyrill Gorcunov wrote:
> On Wed, Jun 11, 2014 at 01:09:15PM +0400, Andrew Vagin wrote:
> > On Wed, Jun 11, 2014 at 11:51:25AM +0400, Cyrill Gorcunov wrote:
> > > On Wed, Jun 11, 2014 at 11:27:43AM +0400, Andrew Vagin wrote:
> >
> > Setting ticks to zero is
On Wed, Jun 11, 2014 at 01:09:15PM +0400, Andrew Vagin wrote:
> On Wed, Jun 11, 2014 at 11:51:25AM +0400, Cyrill Gorcunov wrote:
> > On Wed, Jun 11, 2014 at 11:27:43AM +0400, Andrew Vagin wrote:
>
> ...
>
> > +#ifdef CONFIG_CHECKPOINT_RESTORE
> > +static long timerfd_ioctl(struct file *file, unsi
On Wed, Jun 11, 2014 at 11:51:25AM +0400, Cyrill Gorcunov wrote:
> On Wed, Jun 11, 2014 at 11:27:43AM +0400, Andrew Vagin wrote:
...
> +#ifdef CONFIG_CHECKPOINT_RESTORE
> +static long timerfd_ioctl(struct file *file, unsigned int cmd, unsigned long
> arg)
> +{
> + struct timerfd_ctx *ctx = f
On Wed, Jun 11, 2014 at 11:27:43AM +0400, Andrew Vagin wrote:
> > + case TFD_IOC_SET_TICKS: {
> > + u64 ticks;
> > +
> > + if (!capable(CAP_SYS_RESOURCE))
> > + return -EPERM;
>
> I think it is too strong. It will not work in userns.
>
> Why do we need to c
On Tue, Jun 10, 2014 at 08:35:30PM +0400, Cyrill Gorcunov wrote:
> On Thu, May 22, 2014 at 06:58:19AM +0900, Thomas Gleixner wrote:
> > >
> > > So what wakes a potential waiter in read/poll?
> >
> > And who is updating timerfd_create(2) ?
>
> Thomas, could you please take a look if the approach
On Tue, Jun 10, 2014 at 01:05:22PM -0700, Andy Lutomirski wrote:
> On Tue, Jun 10, 2014 at 1:03 PM, Michael Kerrisk (man-pages)
> wrote:
> > [CC += linux-api@]
Thanks Michael!
> > On Tue, Jun 10, 2014 at 6:35 PM, Cyrill Gorcunov wrote:
> >> On Thu, May 22, 2014 at 06:58:19AM +0900, Thomas Gleix
On Tue, Jun 10, 2014 at 1:03 PM, Michael Kerrisk (man-pages)
wrote:
> [CC += linux-api@]
>
> On Tue, Jun 10, 2014 at 6:35 PM, Cyrill Gorcunov wrote:
>> On Thu, May 22, 2014 at 06:58:19AM +0900, Thomas Gleixner wrote:
>>> >
>>> > So what wakes a potential waiter in read/poll?
>>>
>>> And who is up
[CC += linux-api@]
On Tue, Jun 10, 2014 at 6:35 PM, Cyrill Gorcunov wrote:
> On Thu, May 22, 2014 at 06:58:19AM +0900, Thomas Gleixner wrote:
>> >
>> > So what wakes a potential waiter in read/poll?
>>
>> And who is updating timerfd_create(2) ?
>
> Thomas, could you please take a look if the appr
On Thu, May 22, 2014 at 06:58:19AM +0900, Thomas Gleixner wrote:
> >
> > So what wakes a potential waiter in read/poll?
>
> And who is updating timerfd_create(2) ?
Thomas, could you please take a look if the approach below is acceptable?
If it will be fine I update manpage then.
---
From: Cyrill
On Thu, May 22, 2014 at 08:32:45AM +0200, Michael Kerrisk wrote:
> [Thomas, thanks for pinging me on this.]
>
> Hi Cyril
>
> Please CC linux-api on changes that affect kernel-user-space ABI/API.
Sure!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
[Thomas, thanks for pinging me on this.]
Hi Cyril
Please CC linux-api on changes that affect kernel-user-space ABI/API.
On Thu, May 22, 2014 at 12:35 AM, Cyrill Gorcunov wrote:
> On Thu, May 22, 2014 at 07:12:30AM +0900, Thomas Gleixner wrote:
>>
>> There is a world outside of checkpoint/restor
On Thu, May 22, 2014 at 08:30:04AM +0900, Thomas Gleixner wrote:
> >
> > > So what's the semantics of that write function? We really want to have
> > > that agreed on and documented in the man page.
> >
> > The idea was to provide a way to setup @ticks into (nonzero) value
> > which we get from s
On Thu, 22 May 2014, Cyrill Gorcunov wrote:
> On Thu, May 22, 2014 at 07:12:30AM +0900, Thomas Gleixner wrote:
> >
> > There is a world outside of checkpoint/restore, really.
>
> Yes, I simply don't know who else might use this write()
> functionality for other purpose, I mean i don't see a
> poi
On Thu, May 22, 2014 at 07:12:30AM +0900, Thomas Gleixner wrote:
>
> There is a world outside of checkpoint/restore, really.
Yes, I simply don't know who else might use this write()
functionality for other purpose, I mean i don't see a
point to use it for anything else.
> So what's the semantics
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)
> >
On Thu, 22 May 2014, 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;
> > +
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
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)
The read() of timerfd files allows to fetch the number of
timer ticks while there is no way to set it back from userspace.
To restore the timer state as it was at checkpoint moment we need
a way to setup ticks back. So as a counterpart of read() the write()
takes ticks number from the userspace an
The read() of timerfd files allows to fetch the number of
timer ticks while there is no way to set it back from userspace.
To restore the timer state as it was at checkpoint moment we need
a way to setup ticks back. So as a counterpart of read() the write()
takes ticks number from the userspace an
20 matches
Mail list logo
