lkml.org 
[lkml]   [2014]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH RFC] time,signal: protect resource use statistics with seqlock
    From
    2014-08-14 3:57 GMT+02:00 Rik van Riel <riel@redhat.com>:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
    >> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
    >>> --- a/kernel/time/posix-cpu-timers.c +++
    >>> b/kernel/time/posix-cpu-timers.c @@ -272,22 +272,8 @@ static int
    >>> posix_cpu_clock_get_task(struct task_struct *tsk, if
    >>> (same_thread_group(tsk, current)) err =
    >>> cpu_clock_sample(which_clock, tsk, &rtn); } else { - unsigned
    >>> long flags; - struct sighand_struct *sighand; - - /* - *
    >>> while_each_thread() is not yet entirely RCU safe, - * keep
    >>> locking the group while sampling process - * clock for now. -
    >>> */ - sighand = lock_task_sighand(tsk, &flags); - if (!sighand)
    >>> - return err; - if (tsk == current ||
    >>> thread_group_leader(tsk)) err =
    >>> cpu_clock_sample_group(which_clock, tsk, &rtn); - -
    >>> unlock_task_sighand(tsk, &flags); }
    >>
    >> I'm worried about such lockless solution based on RCU or read
    >> seqcount because we lose the guarantee that an update is
    >> immediately visible by all subsequent readers.
    >>
    >> Say CPU 0 updates the thread time and both CPU 1 and CPU 2 right
    >> after that call clock_gettime(), with the spinlock we were
    >> guaranteed to see the new update. Now with a pure seqlock read
    >> approach, we guarantee a read sequence coherency but we don't
    >> guarantee the freshest update result.
    >>
    >> So that looks like a source of non monotonic results.
    >
    > Which update are you worried about, specifically?
    >
    > The seq_write_lock to update the usage stat in p->signal will lock out
    > the seqlock read side used to check those results.
    >
    > Is there another kind of thing read by cpu_clock_sample_group that you
    > believe is not excluded by the seq_lock?

    I mean the read side doesn't use a lock with seqlocks. It's only made
    of barriers and sequence numbers to ensure the reader doesn't read
    some half-complete update. But other than that it can as well see the
    update n - 1 since barriers don't enforce latest results.


    \
     
     \ /
      Last update: 2014-08-14 15:41    [W:2.531 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site