1. 29 Apr, 2019 1 commit
    • Joel Fernandes (Google)'s avatar
      Provide in-kernel headers to make extending kernel easier · 43d8ce9d
      Joel Fernandes (Google) authored
      Introduce in-kernel headers which are made available as an archive
      through proc (/proc/kheaders.tar.xz file). This archive makes it
      possible to run eBPF and other tracing programs that need to extend the
      kernel for tracing purposes without any dependency on the file system
      having headers.
      
      A github PR is sent for the corresponding BCC patch at:
      https://github.com/iovisor/bcc/pull/2312
      
      On Android and embedded systems, it is common to switch kernels but not
      have kernel headers available on the file system. Further once a
      different kernel is booted, any headers stored on the file system will
      no longer be useful. This is an issue even well known to distros.
      By storing the headers as a compressed archive within the kernel, we can
      avoid these issues that have been a hindrance for a long time.
      
      The best way to use this feature is by building it in. Several users
      have a need for this, when they switch debug kernels, they do not want to
      update the filesystem or worry about it where to store the headers on
      it. However, the feature is also buildable as a module in case the user
      desires it not being part of the kernel image. This makes it possible to
      load and unload the headers from memory on demand. A tracing program can
      load the module, do its operations, and then unload the module to save
      kernel memory. The total memory needed is 3.3MB.
      
      By having the archive available at a fixed location independent of
      filesystem dependencies and conventions, all debugging tools can
      directly refer to the fixed location for the archive, without concerning
      with where the headers on a typical filesystem which significantly
      simplifies tooling that needs kernel headers.
      
      The code to read the headers is based on /proc/config.gz code and uses
      the same technique to embed the headers.
      
      Other approaches were discussed such as having an in-memory mountable
      filesystem, but that has drawbacks such as requiring an in-kernel xz
      decompressor which we don't have today, and requiring usage of 42 MB of
      kernel memory to host the decompressed headers at anytime. Also this
      approach is simpler than such approaches.
      Reviewed-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43d8ce9d
  2. 28 Apr, 2019 2 commits
  3. 25 Apr, 2019 20 commits
  4. 04 Apr, 2019 14 commits
  5. 01 Apr, 2019 3 commits
    • Tetsuo Handa's avatar
      kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice. · c03a0fd0
      Tetsuo Handa authored
      syzbot is hitting use-after-free bug in uinput module [1]. This is because
      kobject_uevent(KOBJ_REMOVE) is called again due to commit 0f4dafc0
      ("Kobject: auto-cleanup on final unref") after memory allocation fault
      injection made kobject_uevent(KOBJ_REMOVE) from device_del() from
      input_unregister_device() fail, while uinput_destroy_device() is expecting
      that kobject_uevent(KOBJ_REMOVE) is not called after device_del() from
      input_unregister_device() completed.
      
      That commit intended to catch cases where nobody even attempted to send
      "remove" uevents. But there is no guarantee that an event will ultimately
      be sent. We are at the point of no return as far as the rest of the kernel
      is concerned; there are no repeats or do-overs.
      
      Also, it is not clear whether some subsystem depends on that commit.
      If no subsystem depends on that commit, it will be better to remove
      the state_{add,remove}_uevent_sent logic. But we don't want to risk
      a regression (in a patch which will be backported) by trying to remove
      that logic. Therefore, as a first step, let's avoid the use-after-free bug
      by making sure that kobject_uevent(KOBJ_REMOVE) won't be triggered twice.
      
      [1] https://syzkaller.appspot.com/bug?id=8b17c134fe938bbddd75a45afaa9e68af43a362dReported-by: default avatarsyzbot <syzbot+f648cfb7e0b52bf7ae32@syzkaller.appspotmail.com>
      Analyzed-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Fixes: 0f4dafc0 ("Kobject: auto-cleanup on final unref")
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c03a0fd0
    • Geert Uytterhoeven's avatar
      driver: base: Disable CONFIG_UEVENT_HELPER by default · 1be01d4a
      Geert Uytterhoeven authored
      Since commit 7934779a ("Driver-Core: disable /sbin/hotplug by
      default"), the help text for the /sbin/hotplug fork-bomb says
      "This should not be used today [...] creates a high system load, or
      [...] out-of-memory situations during bootup".  The rationale for this
      was that no recent mainstream system used this anymore (in 2010!).
      
      A few years later, the complete uevent helper support was made optional
      in commit 86d56134 ("kobject: Make support for uevent_helper
      optional.").  However, if was still left enabled by default, to support
      ancient userland.
      
      Time passed by, and nothing should use this anymore, so it can be
      disabled by default.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1be01d4a
    • Greg Kroah-Hartman's avatar
      device.h: reorganize struct device · 159ef31e
      Greg Kroah-Hartman authored
      struct device is big, around 760 bytes on x86_64.  It's not a critical
      structure, but it is embedded everywhere, so making it smaller is always
      a good thing.
      
      With a recent patch that moved a field from struct device to the private
      structure, some benchmarks showed a very odd regression, despite this
      structure having nothing to do with those benchmarks.  That caused me to
      look into the layout of the structure.  Using 'pahole', it showed a
      number of holes and ways that the structure could be reordered in order
      to align some cachelines better, as well as reduce the size of the
      overall structure.
      
      Move 'struct kobj' to the start of the structure, to keep that access
      in the first cacheline, and try to organize things a bit more compactly
      where possible
      
      By doing these few moves, the result removes at least 8 bytes from
      'struct device' on a 64bit system.  Given we know there are systems with
      at least 30k devices in memory at once, every little byte counts, and
      this change could be a savings of 240k of kernel memory for them.  On
      "normal" systems the overall memory savings would be much less.
      
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Cc: Johan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      159ef31e