lkml.org 
[lkml]   [2006]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: How is Code in do_sys_settimeofday() safe in case of SMP and Nest Kernel Path?
    2006/10/1, Nick Piggin <nickpiggin@yahoo.com.au>:
    > It is in an unlikely path though. How many apps actually pass in a
    > non NULL value for the timezone? Those that don't won't be affected.
    > Even for those that do, it doesn't introduce any atomic ops or
    > unpredictable branches, or cacheline pressure (because xtime lock is
    > already touched by do_gettimeofday). IOW: I'm sure it would be
    > unmeasurable.

    I agree the above. Normally the unlikely path is not invoked after boot.

    >
    > OTOH, to be completely correct, it seems like the same xtime_lock
    > read section should cover both the calculation of ktv, and that of
    > ktz. So if it is going to be fixed at all, it should be done
    > properly and looks like it needs to be a bit more intrusive (but
    > no more expensive).
    >

    That means either 1. Move the seq lock from within do_gettimeofday()
    to out of do_gettimeofday(), or 2. pass ktz into do_gettimeofday() and
    compute it in the preexisting read section in do_gettimeofday().

    The first changes the semantic of do_gettimeofday() so it would be
    unacceptable since the function is invoked from many places. The
    second changes the signature of the function so every caller need to
    be changed to passing an extra NULL pointer in order to satisfy the
    changed invocation agreement.

    I think the race condition is not unacceptable so long as comments is
    changed to state the situation clearly. To move everything into the
    same read (and write) section (respectively) is a bit bigger work but
    it does not introduce performance penalty at run time. Or perhaps we
    could tolerate some middle point, that is, as the initial patch, still
    protect ktz and ktv in separated section and let the comments state
    the not-so-perfect situation clearly.
    -
    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/

    \
     
     \ /
      Last update: 2006-10-01 14:27    [W:0.021 / U:0.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site