lkml.org 
[lkml]   [2017]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: WARNING in get_pi_state
    On Tue, Oct 31, 2017 at 1:08 PM, Peter Zijlstra <peterz@infradead.org> wrote:
    > On Tue, Oct 31, 2017 at 12:29:50PM +0300, Dmitry Vyukov wrote:
    >> I understand your sentiment, but it's definitely not _at all_. The
    >> system compiled this exact code, run it and triggered the bug on it.
    >> Do you have suggestions on how to make this code more portable? How
    >> does this setup would look on your system?
    >
    > So I don't see the point of that tun stuff; what was is supposed to do?
    >
    > All it ever did after creation was flush_tun(), which reads until empty.
    > But given nobody would ever write into it, that's an 'expensive' NO-OP.

    See the text below.
    It does try to minimize both programs and features used (e.g. also
    these clunky NONFAILING macros, and filesystem business). But if it
    takes 100 seconds to reproduce, then it's hard to do minimization.
    Consider that you are trying to bisect such bugs, that also will be
    hard and unreliable, and you can get a wrong commit in the end.

    See this for an example for much more tidy reproducer:
    https://groups.google.com/forum/#!topic/syzkaller-bugs/9nYn7hpNpEk
    But that's a single threaded bug that instantly triggers each time you
    run the program.


    >> We do try hard to get rid of unnecessary stuff in reproducers. I think
    >> what happened in this case is the following. This is a hard to
    >> reproduce race. The bot was able to reproduce the crash on initial
    >> program that uses tun, then tried to get rid of tun code and
    >> re-reproduce it, but it did not reproduce this time, so it concluded
    >> that tun code is somehow necessary here. That's unfortunate
    >> consequence of testing complex concurrent code. May become somewhat
    >> better once we have KTSAN, the race detector.
    >
    > I ripped out the tun bits and it reproduced in ~100 seconds. I've now
    > got it running for well over 30m on the fixed kernel while I'm trying to
    > come up with a comprehensible Changelog ;-)

    \
     
     \ /
      Last update: 2017-10-31 11:22    [W:2.538 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site