1. 29 4月, 2019 2 次提交
  2. 26 4月, 2019 19 次提交
  3. 25 4月, 2019 1 次提交
  4. 05 4月, 2019 14 次提交
  5. 01 4月, 2019 4 次提交
    • T
      kobject: Don't trigger kobject_uevent(KOBJ_REMOVE) twice. · c03a0fd0
      Tetsuo Handa 提交于
      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: Nsyzbot <syzbot+f648cfb7e0b52bf7ae32@syzkaller.appspotmail.com>
      Analyzed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Fixes: 0f4dafc0 ("Kobject: auto-cleanup on final unref")
      Cc: Kay Sievers <kay@vrfy.org>
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c03a0fd0
    • G
      driver: base: Disable CONFIG_UEVENT_HELPER by default · 1be01d4a
      Geert Uytterhoeven 提交于
      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: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1be01d4a
    • G
      device.h: reorganize struct device · 159ef31e
      Greg Kroah-Hartman 提交于
      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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      159ef31e
    • L
      Linux 5.1-rc3 · 79a3aaa7
      Linus Torvalds 提交于
      79a3aaa7