1. 26 1月, 2022 1 次提交
  2. 22 1月, 2022 2 次提交
    • V
      lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() · 2dba5eb1
      Vlastimil Babka 提交于
      Currently, enabling CONFIG_STACKDEPOT means its stack_table will be
      allocated from memblock, even if stack depot ends up not actually used.
      The default size of stack_table is 4MB on 32-bit, 8MB on 64-bit.
      
      This is fine for use-cases such as KASAN which is also a config option
      and has overhead on its own.  But it's an issue for functionality that
      has to be actually enabled on boot (page_owner) or depends on hardware
      (GPU drivers) and thus the memory might be wasted.  This was raised as
      an issue [1] when attempting to add stackdepot support for SLUB's debug
      object tracking functionality.  It's common to build kernels with
      CONFIG_SLUB_DEBUG and enable slub_debug on boot only when needed, or
      create only specific kmem caches with debugging for testing purposes.
      
      It would thus be more efficient if stackdepot's table was allocated only
      when actually going to be used.  This patch thus makes the allocation
      (and whole stack_depot_init() call) optional:
      
       - Add a CONFIG_STACKDEPOT_ALWAYS_INIT flag to keep using the current
         well-defined point of allocation as part of mem_init(). Make
         CONFIG_KASAN select this flag.
      
       - Other users have to call stack_depot_init() as part of their own init
         when it's determined that stack depot will actually be used. This may
         depend on both config and runtime conditions. Convert current users
         which are page_owner and several in the DRM subsystem. Same will be
         done for SLUB later.
      
       - Because the init might now be called after the boot-time memblock
         allocation has given all memory to the buddy allocator, change
         stack_depot_init() to allocate stack_table with kvmalloc() when
         memblock is no longer available. Also handle allocation failure by
         disabling stackdepot (could have theoretically happened even with
         memblock allocation previously), and don't unnecessarily align the
         memblock allocation to its own size anymore.
      
      [1] https://lore.kernel.org/all/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/
      
      Link: https://lkml.kernel.org/r/20211013073005.11351-1-vbabka@suse.czSigned-off-by: NVlastimil Babka <vbabka@suse.cz>
      Acked-by: NDmitry Vyukov <dvyukov@google.com>
      Reviewed-by: Marco Elver <elver@google.com> # stackdepot
      Cc: Marco Elver <elver@google.com>
      Cc: Vijayanand Jitta <vjitta@codeaurora.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Oliver Glitta <glittao@gmail.com>
      Cc: Imran Khan <imran.f.khan@oracle.com>
      From: Colin Ian King <colin.king@canonical.com>
      Subject: lib/stackdepot: fix spelling mistake and grammar in pr_err message
      
      There is a spelling mistake of the work allocation so fix this and
      re-phrase the message to make it easier to read.
      
      Link: https://lkml.kernel.org/r/20211015104159.11282-1-colin.king@canonical.comSigned-off-by: NColin Ian King <colin.king@canonical.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      From: Vlastimil Babka <vbabka@suse.cz>
      Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup
      
      On FLATMEM, we call page_ext_init_flatmem_late() just before
      kmem_cache_init() which means stack_depot_init() (called by page owner
      init) will not recognize properly it should use kvmalloc() and not
      memblock_alloc().  memblock_alloc() will also not issue a warning and
      return a block memory that can be invalid and cause kernel page fault when
      saving stacks, as reported by the kernel test robot [1].
      
      Fix this by moving page_ext_init_flatmem_late() below kmem_cache_init() so
      that slab_is_available() is true during stack_depot_init().  SPARSEMEM
      doesn't have this issue, as it doesn't do page_ext_init_flatmem_late(),
      but a different page_ext_init() even later in the boot process.
      
      Thanks to Mike Rapoport for pointing out the FLATMEM init ordering issue.
      
      While at it, also actually resolve a checkpatch warning in stack_depot_init()
      from DRM CI, which was supposed to be in the original patch already.
      
      [1] https://lore.kernel.org/all/20211014085450.GC18719@xsang-OptiPlex-9020/
      
      Link: https://lkml.kernel.org/r/6abd9213-19a9-6d58-cedc-2414386d2d81@suse.czSigned-off-by: NVlastimil Babka <vbabka@suse.cz>
      Reported-by: Nkernel test robot <oliver.sang@intel.com>
      Cc: Mike Rapoport <rppt@kernel.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      From: Vlastimil Babka <vbabka@suse.cz>
      Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup3
      
      Due to cd06ab2f ("drm/locking: add backtrace for locking contended
      locks without backoff") landing recently to -next adding a new stack depot
      user in drivers/gpu/drm/drm_modeset_lock.c we need to add an appropriate
      call to stack_depot_init() there as well.
      
      Link: https://lkml.kernel.org/r/2a692365-cfa1-64f2-34e0-8aa5674dce5e@suse.czSigned-off-by: NVlastimil Babka <vbabka@suse.cz>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Naresh Kamboju <naresh.kamboju@linaro.org>
      Cc: Marco Elver <elver@google.com>
      Cc: Vijayanand Jitta <vjitta@codeaurora.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Maxime Ripard <mripard@kernel.org>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Konovalov <andreyknvl@gmail.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Oliver Glitta <glittao@gmail.com>
      Cc: Imran Khan <imran.f.khan@oracle.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      From: Vlastimil Babka <vbabka@suse.cz>
      Subject: lib/stackdepot: allow optional init and stack_table allocation by kvmalloc() - fixup4
      
      Due to 4e66934e ("lib: add reference counting tracking
      infrastructure") landing recently to net-next adding a new stack depot
      user in lib/ref_tracker.c we need to add an appropriate call to
      stack_depot_init() there as well.
      
      Link: https://lkml.kernel.org/r/45c1b738-1a2f-5b5f-2f6d-86fab206d01c@suse.czSigned-off-by: NVlastimil Babka <vbabka@suse.cz>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Cc: Jiri Slab <jirislaby@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2dba5eb1
    • L
      i915: simplify subdirectory registration with register_sysctl() · e5a1fd99
      Luis Chamberlain 提交于
      There is no need to user boiler plate code to specify a set of base
      directories we're going to stuff sysctls under.  Simplify this by using
      register_sysctl() and specifying the directory path directly.
      
      // pycocci sysctl-subdir-register-sysctl-simplify.cocci PATH
      
      @c1@
      expression E1;
      identifier subdir, sysctls;
      @@
      
      static struct ctl_table subdir[] = {
      	{
      		.procname = E1,
      		.maxlen = 0,
      		.mode = 0555,
      		.child = sysctls,
      	},
      	{ }
      };
      
      @c2@
      identifier c1.subdir;
      
      expression E2;
      identifier base;
      @@
      
      static struct ctl_table base[] = {
      	{
      		.procname = E2,
      		.maxlen = 0,
      		.mode = 0555,
      		.child = subdir,
      	},
      	{ }
      };
      
      @c3@
      identifier c2.base;
      identifier header;
      @@
      
      header = register_sysctl_table(base);
      
      @r1 depends on c1 && c2 && c3@
      expression c1.E1;
      identifier c1.subdir, c1.sysctls;
      @@
      
      -static struct ctl_table subdir[] = {
      -	{
      -		.procname = E1,
      -		.maxlen = 0,
      -		.mode = 0555,
      -		.child = sysctls,
      -	},
      -	{ }
      -};
      
      @r2 depends on c1 && c2 && c3@
      identifier c1.subdir;
      
      expression c2.E2;
      identifier c2.base;
      @@
      -static struct ctl_table base[] = {
      -	{
      -		.procname = E2,
      -		.maxlen = 0,
      -		.mode = 0555,
      -		.child = subdir,
      -	},
      -	{ }
      -};
      
      @initialize:python@
      @@
      
      def make_my_fresh_expression(s1, s2):
        return '"' + s1.strip('"') + "/" + s2.strip('"') + '"'
      
      @r3 depends on c1 && c2 && c3@
      expression c1.E1;
      identifier c1.sysctls;
      expression c2.E2;
      identifier c2.base;
      identifier c3.header;
      fresh identifier E3 = script:python(E2, E1) { make_my_fresh_expression(E2, E1) };
      @@
      
      header =
      -register_sysctl_table(base);
      +register_sysctl(E3, sysctls);
      
      Generated-by: Coccinelle SmPL
      Link: https://lkml.kernel.org/r/20211123202422.819032-3-mcgrof@kernel.orgSigned-off-by: NLuis Chamberlain <mcgrof@kernel.org>
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Antti Palosaari <crope@iki.fi>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Benjamin LaHaise <bcrl@kvack.org>
      Cc: Clemens Ladisch <clemens@ladisch.de>
      Cc: David Airlie <airlied@linux.ie>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Iurii Zaikin <yzaikin@google.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Joseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Julia Lawall <julia.lawall@inria.fr>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Lukas Middendorf <kernel@tuxforce.de>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Phillip Potter <phil@philpotter.co.uk>
      Cc: Qing Wang <wangqing@vivo.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
      Cc: Stephen Kitt <steve@sk2.org>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Xiaoming Ni <nixiaoming@huawei.com>
      Cc: Douglas Gilbert <dgilbert@interlog.com>
      Cc: James E.J. Bottomley <jejb@linux.ibm.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: John Ogness <john.ogness@linutronix.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e5a1fd99
  3. 19 1月, 2022 3 次提交
  4. 17 1月, 2022 2 次提交
  5. 16 1月, 2022 1 次提交
  6. 15 1月, 2022 7 次提交
  7. 14 1月, 2022 3 次提交
  8. 12 1月, 2022 21 次提交