1. 03 6月, 2020 13 次提交
  2. 01 6月, 2020 3 次提交
  3. 31 5月, 2020 11 次提交
  4. 30 5月, 2020 1 次提交
  5. 29 5月, 2020 6 次提交
  6. 28 5月, 2020 3 次提交
    • G
      hwmon: Add notification support · 1597b374
      Guenter Roeck 提交于
      For hwmon drivers using the hwmon_device_register_with_info() API, it
      is desirable to have a generic notification mechanism available. This
      mechanism can be used to notify userspace as well as the thermal
      subsystem if the driver experiences any events, such as warning or
      critical alarms.
      
      Implement hwmon_notify_event() to provide this mechanism. The function
      generates a sysfs event and a udev event. If the device is registered
      with the thermal subsystem and the event is associated with a temperature
      sensor, also notify the thermal subsystem that a thermal event occurred.
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
      Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: linux-mips@vger.kernel.org
      Cc: devicetree@vger.kernel.org
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      1597b374
    • J
      RDMA/core: Fix double destruction of uobject · c85f4abe
      Jason Gunthorpe 提交于
      Fix use after free when user user space request uobject concurrently for
      the same object, within the RCU grace period.
      
      In that case, remove_handle_idr_uobject() is called twice and we will have
      an extra put on the uobject which cause use after free.  Fix it by leaving
      the uobject write locked after it was removed from the idr.
      
      Call to rdma_lookup_put_uobject with UVERBS_LOOKUP_DESTROY instead of
      UVERBS_LOOKUP_WRITE will do the work.
      
        refcount_t: underflow; use-after-free.
        WARNING: CPU: 0 PID: 1381 at lib/refcount.c:28 refcount_warn_saturate+0xfe/0x1a0
        Kernel panic - not syncing: panic_on_warn set ...
        CPU: 0 PID: 1381 Comm: syz-executor.0 Not tainted 5.5.0-rc3 #8
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
        Call Trace:
         dump_stack+0x94/0xce
         panic+0x234/0x56f
         __warn+0x1cc/0x1e1
         report_bug+0x200/0x310
         fixup_bug.part.11+0x32/0x80
         do_error_trap+0xd3/0x100
         do_invalid_op+0x31/0x40
         invalid_op+0x1e/0x30
        RIP: 0010:refcount_warn_saturate+0xfe/0x1a0
        Code: 0f 0b eb 9b e8 23 f6 6d ff 80 3d 6c d4 19 03 00 75 8d e8 15 f6 6d ff 48 c7 c7 c0 02 55 bd c6 05 57 d4 19 03 01 e8 a2 58 49 ff <0f> 0b e9 6e ff ff ff e8 f6 f5 6d ff 80 3d 42 d4 19 03 00 0f 85 5c
        RSP: 0018:ffffc90002df7b98 EFLAGS: 00010282
        RAX: 0000000000000000 RBX: ffff88810f6a193c RCX: ffffffffba649009
        RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88811b0283cc
        RBP: 0000000000000003 R08: ffffed10236060e3 R09: ffffed10236060e3
        R10: 0000000000000001 R11: ffffed10236060e2 R12: ffff88810f6a193c
        R13: ffffc90002df7d60 R14: 0000000000000000 R15: ffff888116ae6a08
         uverbs_uobject_put+0xfd/0x140
         __uobj_perform_destroy+0x3d/0x60
         ib_uverbs_close_xrcd+0x148/0x170
         ib_uverbs_write+0xaa5/0xdf0
         __vfs_write+0x7c/0x100
         vfs_write+0x168/0x4a0
         ksys_write+0xc8/0x200
         do_syscall_64+0x9c/0x390
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x465b49
        Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
        RSP: 002b:00007f759d122c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
        RAX: ffffffffffffffda RBX: 000000000073bfa8 RCX: 0000000000465b49
        RDX: 000000000000000c RSI: 0000000020000080 RDI: 0000000000000003
        RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000246 R12: 00007f759d1236bc
        R13: 00000000004ca27c R14: 000000000070de40 R15: 00000000ffffffff
        Dumping ftrace buffer:
           (ftrace buffer empty)
        Kernel Offset: 0x39400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      
      Fixes: 7452a3c7 ("IB/uverbs: Allow RDMA_REMOVE_DESTROY to work concurrently with disassociate")
      Link: https://lore.kernel.org/r/20200527135534.482279-1-leon@kernel.orgSigned-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      c85f4abe
    • A
      fanotify: turn off support for FAN_DIR_MODIFY · f1793699
      Amir Goldstein 提交于
      FAN_DIR_MODIFY has been enabled by commit 44d705b0 ("fanotify:
      report name info for FAN_DIR_MODIFY event") in 5.7-rc1. Now we are
      planning further extensions to the fanotify API and during that we
      realized that FAN_DIR_MODIFY may behave slightly differently to be more
      consistent with extensions we plan. So until we finalize these
      extensions, let's not bind our hands with exposing FAN_DIR_MODIFY to
      userland.
      Signed-off-by: NAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: NJan Kara <jack@suse.cz>
      f1793699
  7. 27 5月, 2020 3 次提交