lkml.org 
[lkml]   [2022]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v9 12/27] rust: add `kernel` crate
    On Mon, Sep 19, 2022 at 7:07 AM Wedson Almeida Filho <wedsonaf@gmail.com> wrote:
    >
    > For GFP_ATOMIC, we could use preempt_count except that it isn't always
    > enabled. Conveniently, it is already separated out into its own config.
    > How do people feel about removing CONFIG_PREEMPT_COUNT and having the
    > count always enabled?
    >
    > We would then have a way to reliably detect when we are in atomic
    > context [..]

    No.

    First off, it's not true. There are non-preempt atomic contexts too,
    like interrupts disabled etc. Can you enumerate all those? Possibly.

    But more importantly, doing "depending on context, I silently and
    automatically do different things" is simply WRONG. Don't do it. It's
    a disaster.

    Doing that for *debugging* is fine. So having a

    WARN_ON_ONCE(in_atomic_context());

    is a perfectly fine debug check to find people who do bad bad things,
    and we have lots of variations of that theme (ie might_sleep(), but
    also things like lockdep_assert_held() and friends that assert other
    constraints entirely).

    But having *behavior changes* depending on context is a total
    disaster. And that's invariably why people want this disgusting thing.

    They want to do broken things like "I want to allocate memory, and I
    don't want to care where I am, so I want the memory allocator to just
    do the whole GFP_ATOMIC for me".

    And that is FUNDAMENTALLY BROKEN.

    If you want to allocate memory, and you don't want to care about what
    context you are in, or whether you are holding spinlocks etc, then you
    damn well shouldn't be doing kernel programming. Not in C, and not in
    Rust.

    It really is that simple. Contexts like this ("I am in a critical
    region, I must not do memory allocation or use sleeping locks") is
    *fundamental* to kernel programming. It has nothing to do with the
    language, and everything to do with the problem space.

    So don't go down this "let's have the allocator just know if you're in
    an atomic context automatically" path. It's wrong. It's complete
    garbage. It may generate kernel code that superficially "works", but
    one that is fundamentally broken, and will fail and becaome unreliable
    under memory pressure.

    The thing is, when you do kernel programming, and you're holding a
    spinlock and need to allocate memory, you generally shouldn't allocate
    memory at all, you should go "Oh, maybe I need to do the allocation
    *before* getting the lock".

    And it's not just locks. It's also "I'm in a hardware interrupt", but
    now the solution is fundamentally different. Maybe you still want to
    do pre-allocation, but now you're a driver interrupt and the
    pre-allocation has to happen in another code sequence entirely,
    because obviously the interrupt itself is asynchronous.

    But more commonly, you just want to use GFP_ATOMIC, and go "ok, I know
    the VM layer tries to keep a _limited_ set of pre-allocated buffers
    around".

    But it needs to be explicit, because that GFP_ATOMIC pool of
    allocations really is very limited, and you as the allocator need to
    make it *explicit* that yeah, now you're not just doing a random
    allocation, you are doing one of these *special* allocations that will
    eat into that very limited global pool of allocations.

    So no, you cannot and MUST NOT have an allocator that silently just
    dips into that special pool, without the user being aware or
    requesting it.

    That really is very very fundamental. Allocators that "just work" in
    different contexts are broken garbage within the context of a kernel.

    Please just accept this, and really *internalize* it. Because this
    isn't actually just about allocators. Allocators may be one very
    common special case of this kind of issue, and they come up quite
    often as a result, but this whole "your code needs to *understand* the
    special restrictions that the kernel is under" is something that is
    quite fundamental in general.

    It shows up in various other situations too, like "Oh, this code can
    run in an interrupt handler" (which is *different* from the atomicity
    of just "while holding a lock", because it implies a level of random
    nesting that is very relevant for locking).

    Or sometimes it's subtler things than just correctness, ie "I'm
    running under a critical lock, so I must be very careful because there
    are scalability issues". The code may *work* just fine, but things
    like tasklist_lock are very very special.

    So embrace that kernel requirement. Kernels are special. We do things,
    and we have constraints that pretty much no other environment has.

    It is often what makes kernel programming interesting - because it's
    challenging. We have a very limited stack. We have some very direct
    and deep interactions with the CPU, with things like IO and
    interrupts. Some constraints are always there, and others are
    context-dependent.

    The whole "really know what context this code is running within" is
    really important. You may want to write very explicit comments about
    it.

    And you definitely should always write your code knowing about it.

    Linus

    \
     
     \ /
      Last update: 2022-09-19 18:11    [W:6.529 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site