lkml.org 
[lkml]   [2014]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC] time: drop do_sys_times spinlock
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 08/12/2014 03:12 PM, Oleg Nesterov wrote:
    > On 08/12, Rik van Riel wrote:
    >>
    >> Back in 2009, Spencer Candland pointed out there is a race with
    >> do_sys_times, where multiple threads calling do_sys_times can
    >> sometimes get decreasing results.
    >>
    >> https://lkml.org/lkml/2009/11/3/522
    >>
    >> As a result of that discussion, some of the code in do_sys_times
    >> was moved under a spinlock.
    >>
    >> However, that does not seem to actually make the race go away on
    >> larger systems. One obvious remaining race is that after one
    >> thread is about to return from do_sys_times, it is preempted by
    >> another thread, which also runs do_sys_times, and stores a larger
    >> value in the shared variable than what the first thread got.
    >>
    >> This race is on the kernel/userspace boundary, and not fixable
    >> with spinlocks.
    >
    > Not sure I understand...
    >
    > Afaics, the problem is that a single thread can observe the
    > decreasing (say) sum_exec_runtime if it calls do_sys_times() twice
    > without the lock.
    >
    > This is because it can account the exiting sub-thread twice if it
    > races with __exit_signal() which increments sig->sum_sched_runtime,
    > but this exiting thread can still be visible to
    > thread_group_cputime().
    >
    > IOW, it is not actually about decreasing, the problem is that the
    > lockless thread_group_cputime() can return the wrong result, and
    > the next ys_times() can show the right value.

    Hmmm, that is not what the test case does.

    The test case simply calls times() once in each thread, and saves
    the value in a global variable for the next thread to use.

    Does the seq_lock in task_cputime() prevent the problem you are
    describing, or does the exit/zombie reaping code need to block the
    seq_lock while it moves the stats from the zombie to the group?

    - --
    All rights reversed
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1

    iQEcBAEBAgAGBQJT6mmSAAoJEM553pKExN6D+EkH/2BexZ8XfKpHAKfkidIhPrOy
    nr5q8WhKU1mJmdEULNx6NQxAjRnpORTOfDElwRT1gzXqOyXrTxXZ207/anezhstU
    kyu5wRNBz/pilXPDzVsiF+DqTxoBnVOIc0eltQ00jmUden08eVEfEY5mjevCJalz
    2AbWFa8QQZgtGSCZB1UPaUF6NHTu/Z35u9UTEIkLirLCqfIYPz325Wdfs+W+fggS
    8vEgHhO50BrIAm9HCO/vgY8SCAU/0Pml73ABV3+4sB7dnYVgDkYXzS0iMimuAcZ/
    qL0NhRrKH4sRxGQXBlQv87GgMpR9Tr4RVFK6eH9xwjVwthYXnYeDTbYryjpmdco=
    =haSd
    -----END PGP SIGNATURE-----


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