Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755572AbaFJUWh (ORCPT ); Tue, 10 Jun 2014 16:22:37 -0400 Received: from mail-la0-f45.google.com ([209.85.215.45]:47472 "EHLO mail-la0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755460AbaFJUWe (ORCPT ); Tue, 10 Jun 2014 16:22:34 -0400 Date: Wed, 11 Jun 2014 00:22:26 +0400 From: Cyrill Gorcunov To: Andy Lutomirski Cc: Michael Kerrisk-manpages , Thomas Gleixner , LKML , Andrew Morton , Andrey Vagin , Pavel Emelyanov , vdavydov@parallels.com, Linux API Subject: Re: [patch 3/3] timerfd: Implement write method Message-ID: <20140610202226.GG2243@moon> References: <20140428212517.200264067@openvz.org> <20140428213301.507657833@openvz.org> <20140610163530.GF2243@moon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 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 Gorcunov > >> Subject: timerfd: Implement timerfd_ioctl method to restore timerfd_ctx::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's state as it was at checkpoint moment we need > >> a path to bring @ticks back. Initially I thought about writing ticks > >> back via write() interface but it seems such API is somehow obscure. > >> > >> Instead implement timerfd_ioctl() method with TFD_IOC_SET_TICKS > >> command which requires CAP_SYS_RESOURCE capability to be able to > >> set @ticks into arbitrary value. Note this command doesn't wake > >> up readers/waiters and its purpose only to serve C/R needs > >> (for same sake I wrapped code with CONFIG_CHECKPOINT_RESTORE). > >> Still if needed the ioctl may be extended for new commands > >> and CONFIG_CHECKPOINT_RESTORE dropped off. > > Why does this need CAP_SYS_RESOURCE? Because I think this interface should not be used by a regular applications, the only purpose is to restore the @ticks after checkpoint. Requiring CAP_SYS_RESOURCE means that at least program which use it knows what it's doing. Still if someone has a scenarion where we might need this intarface out of this cap requirement -- we always can drop it of without breaking existing users, but not the reverse. P.S. I remember Thomas' words about existence of the other word out of c/r, still I treat this ioctl as exception (as in prctl codes we use for c/r). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/