Skip to content
  • Luis R. Rodriguez's avatar
    printk: move power of 2 practice of ring buffer size to a helper · c0a318a3
    Luis R. Rodriguez authored
    
    
    In practice the power of 2 practice of the size of the kernel ring
    buffer remains purely historical but not a requirement, specially now
    that we have LOG_ALIGN and use it for both static and dynamic
    allocations.  It could have helped with implicit alignment back in the
    days given the even the dynamically sized ring buffer was guaranteed to
    be aligned so long as CONFIG_LOG_BUF_SHIFT was set to produce a
    __LOG_BUF_LEN which is architecture aligned, since log_buf_len=n would
    be allowed only if it was > __LOG_BUF_LEN and we always ended up
    rounding the log_buf_len=n to the next power of 2 with
    roundup_pow_of_two(), any multiple of 2 then should be also architecture
    aligned.  These assumptions of course relied heavily on
    CONFIG_LOG_BUF_SHIFT producing an aligned value but users can always
    change this.
    
    We now have precise alignment requirements set for the log buffer size
    for both static and dynamic allocations, but lets upkeep the old
    practice of using powers of 2 for its size to help with easy expected
    scalable values and the allocators for dynamic allocations.  We'll reuse
    this later so move this into a helper.
    
    Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Stephen Warren <swarren@wwwdotorg.org>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Michal Hocko <mhocko@suse.cz>
    Cc: Petr Mladek <pmladek@suse.cz>
    Cc: Joe Perches <joe@perches.com>
    Cc: Arun KS <arunks.linux@gmail.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Davidlohr Bueso <davidlohr@hp.com>
    Cc: Chris Metcalf <cmetcalf@tilera.com>
    Cc: Jan Kara <jack@suse.cz>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    c0a318a3