lkml.org 
[lkml]   [2003]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Race between vmtruncate and mapped areas?

    --On Wednesday, May 14, 2003 08:06:53 -0700 William Lee Irwin III
    <wli@holomorphy.com> wrote:

    >> Which the application thinks is still part of the file, and will expect
    >> its changes to be written back. Granted, if the page fault occurred
    >> just after the truncate it'd get SIGBUS, so it's clearly not a robust
    >> assumption, but it will result in unexpected behavior. Note that if the
    >> application later extends the file to include this page it could result
    >> in a corrupted file, since all the pages around it will be written
    >> properly.
    >
    > Well, for this one I'd say the app loses; it was its own failure to
    > synchronize truncation vs. access, at least given that the kernel
    > doesn't oops.

    I think allowing a race condition that can randomly leave corrupted files
    is a really bad idea, even if the app is doing something stupid. We know
    what the race is. We should be able to prevent it.

    Dave

    ======================================================================
    Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
    dmccr@us.ibm.com T/L 678-3059

    -
    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: 2005-03-22 13:35    [W:0.024 / U:0.012 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site