lkml.org 
[lkml]   [2019]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: INFO: rcu detected stall in ext4_write_checks
    On Sun, Jul 14, 2019 at 03:05:22PM -0400, Theodore Ts'o wrote:
    > On Sun, Jul 14, 2019 at 05:48:00PM +0300, Dmitry Vyukov wrote:
    > > But short term I don't see any other solution than stop testing
    > > sched_setattr because it does not check arguments enough to prevent
    > > system misbehavior. Which is a pity because syzkaller has found some
    > > bad misconfigurations that were oversight on checking side.
    > > Any other suggestions?
    >
    > Or maybe syzkaller can put its own limitations on what parameters are
    > sent to sched_setattr? In practice, there are any number of ways a
    > root user can shoot themselves in the foot when using sched_setattr or
    > sched_setaffinity, for that matter. I imagine there must be some such
    > constraints already --- or else syzkaller might have set a kernel
    > thread to run with priority SCHED_BATCH, with similar catastrophic
    > effects --- or do similar configurations to make system threads
    > completely unschedulable.
    >
    > Real time administrators who know what they are doing --- and who know
    > that their real-time threads are well behaved --- will always want to
    > be able to do things that will be catastrophic if the real-time thread
    > is *not* well behaved. I don't it is possible to add safety checks
    > which would allow the kernel to automatically detect and reject unsafe
    > configurations.
    >
    > An apt analogy might be civilian versus military aircraft. Most
    > airplanes are designed to be "inherently stable"; that way, modulo
    > buggy/insane control systems like on the 737 Max, the airplane will
    > automatically return to straight and level flight. On the other hand,
    > some military planes (for example, the F-16, F-22, F-36, the
    > Eurofighter, etc.) are sometimes designed to be unstable, since that
    > way they can be more maneuverable.
    >
    > There are use cases for real-time Linux where this flexibility/power
    > vs. stability tradeoff is going to argue for giving root the
    > flexibility to crash the system. Some of these systems might
    > literally involve using real-time Linux in military applications,
    > something for which Paul and I have had some experience. :-)
    >
    > Speaking of sched_setaffinity, one thing which we can do is have
    > syzkaller move all of the system threads to they run on the "system
    > CPU's", and then move the syzkaller processes which are testing the
    > kernel to be on the "system under test CPU's". Then regardless of
    > what priority the syzkaller test programs try to run themselves at,
    > they can't crash the system.
    >
    > Some real-time systems do actually run this way, and it's a
    > recommended configuration which is much safer than letting the
    > real-time threads take over the whole system:
    >
    > http://linuxrealtime.org/index.php/Improving_the_Real-Time_Properties#Isolating_the_Application

    Good point! We might still have issues with some per-CPU kthreads,
    but perhaps use of nohz_full would help at least reduce these sorts
    of problems. (There could still be issues on CPUs with more than
    one runnable threads.)

    Thanx, Paul

    \
     
     \ /
      Last update: 2019-07-14 21:30    [W:5.757 / U:0.676 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site