Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split deep vmem_alloc()/vmem_xalloc() stacks #94

Merged

Commits on Jul 25, 2021

  1. Split deep vmem_alloc()/vmem_xalloc() stacks

    In openzfsonosx#90
    a user reported panics on an M1 with the message
    
    "Invalid kernel stack pointer (probable overflow)."
    
    In at least several of these a deep multi-arena allocation
    was in progress (several vmem_alloc/vmem_xalloc reaching
    all the way down through vmem_bucket_alloc,
    xnu_alloc_throttled, and ultimately to osif_malloc).
    
    The stack frames above the first vmem_alloc were also fairly large.
    
    This commit sets a dynamically sysctl-tunable threshold
    (8k default) for remaining stack size as reported by xnu.
    If we do not have more bytes than that when vmem_alloc()
    is called, then the actual allocation will be done in a
    separate worker thread which will start with a nearly
    empty stack that is much more likely to hold the various
    frames all the way through our code boundary with the
    kernel and beyond.
    
    The xnu / mach thread_call API (osfmk/kern/thread_call.h)
    is used to avoid circular dependencies with taskq, and the
    mechanism is per-arena costing a quick stack-depth check
    per vmem_alloc() but allowing for wildly varying stack
    depths above the first vmem_alloc() call.
    
    Vmem arenas now have two further kstats: the lowest amount
    of available stack space seen at a vmem_alloc() into it,
    and the number of times the allocation work has been done
    in a thread_call worker.
    
    * some spl_vmem.c functions are given inline hints
    
    These are small functions with no or very few automatic
    variables that were good candidates for clang/llvm's
    inlining heuristics before we switched to building
    the kext with -finline-hint-functions.
    
    * remove some (unrelated) unused variables which escaped
    previous commits, eliminating a couple compile-time
    warnings.
    rottegift committed Jul 25, 2021
    Configuration menu
    Copy the full SHA
    6a150c6 View commit details
    Browse the repository at this point in the history