1. 05 10月, 2019 12 次提交
    • B
      RDMA/srpt: Postpone HCA removal until after configfs directory removal · 9b64f7d0
      Bart Van Assche 提交于
      A shortcoming of the SCSI target core is that it does not have an API
      for removing tpg or wwn objects. Wait until these directories have been
      removed before allowing HCA removal to finish.
      
      See also Bart Van Assche, "Re: Why using configfs as the only interface is
      wrong for a storage target", 2011-02-07
      (https://www.spinics.net/lists/linux-scsi/msg50248.html).
      
      This patch fixes the following kernel crash:
      
      ==================================================================
      BUG: KASAN: use-after-free in __configfs_open_file.isra.4+0x1a8/0x400
      Read of size 8 at addr ffff88811880b690 by task restart-lio-srp/1215
      
      CPU: 1 PID: 1215 Comm: restart-lio-srp Not tainted 5.3.0-dbg+ #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      Call Trace:
       dump_stack+0x86/0xca
       print_address_description+0x74/0x32d
       __kasan_report.cold.6+0x1b/0x36
       kasan_report+0x12/0x17
       __asan_load8+0x54/0x90
       __configfs_open_file.isra.4+0x1a8/0x400
       configfs_open_file+0x13/0x20
       do_dentry_open+0x2b1/0x770
       vfs_open+0x58/0x60
       path_openat+0x5fa/0x14b0
       do_filp_open+0x115/0x180
       do_sys_open+0x1d4/0x2a0
       __x64_sys_openat+0x59/0x70
       do_syscall_64+0x6b/0x2d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7f2f2bd3fcce
      Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 05 19 d7 0d 00 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
      RSP: 002b:00007ffd155f7850 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
      RAX: ffffffffffffffda RBX: 0000564609ba88e0 RCX: 00007f2f2bd3fcce
      RDX: 0000000000000241 RSI: 0000564609ba8cf0 RDI: 00000000ffffff9c
      RBP: 00007ffd155f7950 R08: 0000000000000000 R09: 0000000000000020
      R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000000
      R13: 0000000000000003 R14: 0000000000000001 R15: 0000564609ba8cf0
      
      Allocated by task 995:
       save_stack+0x21/0x90
       __kasan_kmalloc.constprop.9+0xc7/0xd0
       kasan_kmalloc+0x9/0x10
       __kmalloc+0x153/0x370
       srpt_add_one+0x4f/0x561 [ib_srpt]
       add_client_context+0x251/0x290 [ib_core]
       ib_register_client+0x1da/0x220 [ib_core]
       iblock_get_alignment_offset_lbas+0x6b/0x100 [target_core_iblock]
       do_one_initcall+0xcd/0x43a
       do_init_module+0x103/0x380
       load_module+0x3b77/0x3eb0
       __do_sys_finit_module+0x12d/0x1b0
       __x64_sys_finit_module+0x43/0x50
       do_syscall_64+0x6b/0x2d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 1221:
       save_stack+0x21/0x90
       __kasan_slab_free+0x139/0x190
       kasan_slab_free+0xe/0x10
       slab_free_freelist_hook+0x67/0x1e0
       kfree+0xcb/0x2a0
       srpt_remove_one+0x596/0x670 [ib_srpt]
       remove_client_context+0x9a/0xe0 [ib_core]
       disable_device+0x106/0x1b0 [ib_core]
       __ib_unregister_device+0x5f/0xf0 [ib_core]
       ib_unregister_driver+0x11a/0x170 [ib_core]
       0xffffffffa087f666
       __x64_sys_delete_module+0x1f8/0x2c0
       do_syscall_64+0x6b/0x2d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff88811880b300
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 912 bytes inside of
       4096-byte region [ffff88811880b300, ffff88811880c300)
      The buggy address belongs to the page:
      page:ffffea0004620200 refcount:1 mapcount:0 mapping:ffff88811ac0de00 index:0x0 compound_mapcount: 0
      flags: 0x2fff000000010200(slab|head)
      raw: 2fff000000010200 dead000000000100 dead000000000122 ffff88811ac0de00
      raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88811880b580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88811880b600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff88811880b680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                               ^
       ffff88811880b700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff88811880b780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Link: https://lore.kernel.org/r/20190930231707.48259-16-bvanassche@acm.orgSigned-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      9b64f7d0
    • B
      RDMA/srpt: Make the code for handling port identities more systematic · 3236fd61
      Bart Van Assche 提交于
      Introduce a new data structure for the information about an RDMA port
      name. This patch does not change any functionality.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-15-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      3236fd61
    • B
      RDMA/srpt: Rework the code that waits until an RDMA port is no longer in use · be408e65
      Bart Van Assche 提交于
      The current implementation does not wait until srpt_release_channel()
      has finished and hence can trigger a use-after-free. Rework
      srpt_release_sport() such that it waits until srpt_release_channel()
      has finished. This patch fixes the following KASAN complaint:
      
      ==================================================================
      BUG: KASAN: use-after-free in srpt_free_ioctx.part.23+0x42/0x100 [ib_srpt]
      Read of size 8 at addr ffff888115c71100 by task kworker/4:3/807
      
      CPU: 4 PID: 807 Comm: kworker/4:3 Not tainted 5.3.0-dbg+ #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
      Workqueue: events srpt_release_channel_work [ib_srpt]
      Call Trace:
       dump_stack+0x86/0xca
       print_address_description+0x74/0x32d
       __kasan_report.cold.6+0x1b/0x36
       kasan_report+0x12/0x17
       __asan_load8+0x54/0x90
       srpt_free_ioctx.part.23+0x42/0x100 [ib_srpt]
       srpt_free_ioctx_ring.part.24+0x50/0x80 [ib_srpt]
       srpt_release_channel_work+0x2ad/0x390 [ib_srpt]
       process_one_work+0x51a/0xa60
       worker_thread+0x67/0x5b0
       kthread+0x1dc/0x200
       ret_from_fork+0x24/0x30
      
      Allocated by task 984:
       save_stack+0x21/0x90
       __kasan_kmalloc.constprop.9+0xc7/0xd0
       kasan_kmalloc+0x9/0x10
       __kmalloc+0x153/0x370
       srpt_add_one+0x4f/0x570 [ib_srpt]
       add_client_context+0x251/0x290 [ib_core]
       ib_register_client+0x1da/0x220 [ib_core]
       iblock_get_alignment_offset_lbas+0x6b/0x100 [target_core_iblock]
       do_one_initcall+0xcd/0x43a
       do_init_module+0x103/0x380
       load_module+0x3b77/0x3eb0
       __do_sys_finit_module+0x12d/0x1b0
       __x64_sys_finit_module+0x43/0x50
       do_syscall_64+0x6b/0x2d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 1128:
       save_stack+0x21/0x90
       __kasan_slab_free+0x139/0x190
       kasan_slab_free+0xe/0x10
       slab_free_freelist_hook+0x67/0x1e0
       kfree+0xcb/0x2a0
       srpt_remove_one+0x569/0x5b0 [ib_srpt]
       remove_client_context+0x9a/0xe0 [ib_core]
       disable_device+0x106/0x1b0 [ib_core]
       __ib_unregister_device+0x5f/0xf0 [ib_core]
       ib_unregister_device_and_put+0x48/0x60 [ib_core]
       nldev_dellink+0x120/0x180 [ib_core]
       rdma_nl_rcv+0x287/0x480 [ib_core]
       netlink_unicast+0x2cc/0x370
       netlink_sendmsg+0x3b1/0x630
       __sys_sendto+0x1db/0x290
       __x64_sys_sendto+0x80/0xa0
       do_syscall_64+0x6b/0x2d0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888115c71100
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 0 bytes inside of
       4096-byte region [ffff888115c71100, ffff888115c72100)
      The buggy address belongs to the page:
      page:ffffea0004571c00 refcount:1 mapcount:0 mapping:ffff88811ac0de00 index:0xffff888115c70000 compound_mapcount: 0
      flags: 0x2fff000000010200(slab|head)
      raw: 2fff000000010200 ffffea00045ac408 ffffea0004593208 ffff88811ac0de00
      raw: ffff888115c70000 0000000000070002 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888115c71000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888115c71080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff888115c71100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                         ^
       ffff888115c71180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff888115c71200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Link: https://lore.kernel.org/r/20190930231707.48259-14-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      be408e65
    • B
      RDMA/srpt: Rework the approach for closing an RDMA channel · 6eaed91c
      Bart Van Assche 提交于
      Instead of relying on a waitqueue, report when the identity of an RDMA
      channel can be reused through a completion.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-13-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      6eaed91c
    • B
      RDMA/srpt: Improve a debug message · b5948cfd
      Bart Van Assche 提交于
      The ib_srpt driver uses two different identifiers while registering a
      session with the LIO core. Report both identifiers if the modified
      pr_debug() statement is enabled.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-12-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      b5948cfd
    • B
      RDMA/srpt: Fix handling of iWARP logins · cbca2442
      Bart Van Assche 提交于
      The path_rec pointer is NULL set for IB and RoCE logins but not for iWARP
      logins. Hence check the path_rec pointer before dereferencing it.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-11-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      cbca2442
    • B
      RDMA/srpt: Fix handling of SR-IOV and iWARP ports · 09f8a148
      Bart Van Assche 提交于
      Management datagrams (MADs) are not supported by SR-IOV VFs nor by iWARP
      ports. Support SR-IOV VFs and iWARP ports by only logging an error message
      if MAD handler registration fails.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-10-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      09f8a148
    • B
      RDMA/srp: Make route resolving error messages more informative · fdbcf5c0
      Bart Van Assche 提交于
      The IPv6 scope ID is essential when setting up an iWARP connection
      between IPv6 link-local addresses. Report the scope ID in error messages.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-9-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      fdbcf5c0
    • B
      RDMA/srp: Honor the max_send_sge device attribute · bf583470
      Bart Van Assche 提交于
      Instead of assuming that max_send_sge >= 3, restrict the number of scatter
      gather elements to what is supported by the RDMA adapter.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-8-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      bf583470
    • B
      RDMA/srp: Remove two casts · 14673778
      Bart Van Assche 提交于
      This patch does not change any functionality.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-7-bvanassche@acm.org
      Cc: Honggang LI <honli@redhat.com>
      Cc: Laurence Oberman <loberman@redhat.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      14673778
    • B
      RDMA/siw: Make node GUIDs valid EUI-64 identifiers · 934f05b0
      Bart Van Assche 提交于
      >From the IBTA: "GUID (Global Unique Identifier): A globally unique EUI-64
      compliant identifier." Make sure that siw GUIDs are valid EUI-64 identifiers.
      
      Link: https://lore.kernel.org/r/20190930231707.48259-6-bvanassche@acm.org
      Cc: Bernard Metzler <bmt@zurich.ibm.com>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      934f05b0
    • P
      RDMA/iw_cxgb3: Remove the iw_cxgb3 module from kernel · 30e0f6cf
      Potnuri Bharat Teja 提交于
      Remove iw_cxgb3 module from kernel as the corresponding HW Chelsio T3 has
      reached EOL.
      
      Link: https://lore.kernel.org/r/20190930074252.20133-1-bharat@chelsio.comSigned-off-by: NPotnuri Bharat Teja <bharat@chelsio.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      30e0f6cf
  2. 02 10月, 2019 3 次提交
  3. 01 10月, 2019 12 次提交
  4. 30 9月, 2019 13 次提交
    • K
      csky: Move static keyword to the front of declaration · 9af032a3
      Krzysztof Wilczynski 提交于
      Move the static keyword to the front of declaration of
      csky_pmu_of_device_ids, and resolve the following compiler
      warning that can be seen when building with warnings
      enabled (W=1):
      
      arch/csky/kernel/perf_event.c:1340:1: warning:
        ‘static’ is not at beginning of declaration [-Wold-style-declaration]
      Signed-off-by: NKrzysztof Wilczynski <kw@linux.com>
      Signed-off-by: NGuo Ren <guoren@kernel.org>
      9af032a3
    • V
      csky: entry: Remove unneeded need_resched() loop · a2139d3b
      Valentin Schneider 提交于
      Since the enabling and disabling of IRQs within preempt_schedule_irq()
      is contained in a need_resched() loop, we don't need the outer arch
      code loop.
      Signed-off-by: NValentin Schneider <valentin.schneider@arm.com>
      Signed-off-by: NGuo Ren <guoren@kernel.org>
      a2139d3b
    • L
      Merge tag 'char-misc-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc · 97f9a3c4
      Linus Torvalds 提交于
      Pull Documentation/process update from Greg KH:
       "Here are two small Documentation/process/embargoed-hardware-issues.rst
        file updates that missed my previous char/misc pull request.
      
        The first one adds an Intel representative for the process, and the
        second one cleans up the text a bit more when it comes to how the
        disclosure rules work, as it was a bit confusing to some companies"
      
      * tag 'char-misc-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
        Documentation/process: Clarify disclosure rules
        Documentation/process: Volunteer as the ambassador for Intel
      97f9a3c4
    • L
      Merge branch 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs · 1eb80d6f
      Linus Torvalds 提交于
      Pull more vfs updates from Al Viro:
       "A couple of misc patches"
      
      * 'work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
        afs dynroot: switch to simple_dir_operations
        fs/handle.c - fix up kerneldoc
      1eb80d6f
    • L
      Merge tag '5.4-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6 · 7edee522
      Linus Torvalds 提交于
      Pull more cifs updates from Steve French:
       "Fixes from the recent SMB3 Test events and Storage Developer
        Conference (held the last two weeks).
      
        Here are nine smb3 patches including an important patch for debugging
        traces with wireshark, with three patches marked for stable.
      
        Additional fixes from last week to better handle some newly discovered
        reparse points, and a fix the create/mkdir path for setting the mode
        more atomically (in SMB3 Create security descriptor context), and one
        for path name processing are still being tested so are not included
        here"
      
      * tag '5.4-rc-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
        CIFS: Fix oplock handling for SMB 2.1+ protocols
        smb3: missing ACL related flags
        smb3: pass mode bits into create calls
        smb3: Add missing reparse tags
        CIFS: fix max ea value size
        fs/cifs/sess.c: Remove set but not used variable 'capabilities'
        fs/cifs/smb2pdu.c: Make SMB2_notify_init static
        smb3: fix leak in "open on server" perf counter
        smb3: allow decryption keys to be dumped by admin for debugging
      7edee522
    • M
      csky: Fixup csky_pmu.max_period assignment · 3a09d8e2
      Mao Han 提交于
      The csky_pmu.max_period has type u64, and BIT() can only return
      32 bits unsigned long on C-SKY. The initialization for max_period
      will be incorrect when count_width is bigger than 32.
      
      Use BIT_ULL()
      Signed-off-by: NMao Han <han_mao@c-sky.com>
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      3a09d8e2
    • G
      csky: Fixup add zero_fp fixup perf backtrace panic · 48ede51f
      Guo Ren 提交于
      We need set fp zero to let backtrace know the end. The patch fixup perf
      callchain panic problem, because backtrace didn't know what is the end
      of fp.
      Signed-off-by: NGuo Ren <ren_guo@c-sky.com>
      Reported-by: NMao Han <han_mao@c-sky.com>
      48ede51f
    • M
      csky: Use generic free_initrd_mem() · fdbdcddc
      Mike Rapoport 提交于
      The csky implementation of free_initrd_mem() is an open-coded version of
      free_reserved_area() without poisoning.
      
      Remove it and make csky use the generic version of free_initrd_mem().
      Signed-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NGuo Ren <guoren@kernel.org>
      fdbdcddc
    • L
      Merge branch 'entropy' · 3f2dc279
      Linus Torvalds 提交于
      Merge active entropy generation updates.
      
      This is admittedly partly "for discussion".  We need to have a way
      forward for the boot time deadlocks where user space ends up waiting for
      more entropy, but no entropy is forthcoming because the system is
      entirely idle just waiting for something to happen.
      
      While this was triggered by what is arguably a user space bug with
      GDM/gnome-session asking for secure randomness during early boot, when
      they didn't even need any such truly secure thing, the issue ends up
      being that our "getrandom()" interface is prone to that kind of
      confusion, because people don't think very hard about whether they want
      to block for sufficient amounts of entropy.
      
      The approach here-in is to decide to not just passively wait for entropy
      to happen, but to start actively collecting it if it is missing.  This
      is not necessarily always possible, but if the architecture has a CPU
      cycle counter, there is a fair amount of noise in the exact timings of
      reasonably complex loads.
      
      We may end up tweaking the load and the entropy estimates, but this
      should be at least a reasonable starting point.
      
      As part of this, we also revert the revert of the ext4 IO pattern
      improvement that ended up triggering the reported lack of external
      entropy.
      
      * getrandom() active entropy waiting:
        Revert "Revert "ext4: make __ext4_get_inode_loc plug""
        random: try to actively add entropy rather than passively wait for it
      3f2dc279
    • L
      Revert "Revert "ext4: make __ext4_get_inode_loc plug"" · 02f03c42
      Linus Torvalds 提交于
      This reverts commit 72dbcf72.
      
      Instead of waiting forever for entropy that may just not happen, we now
      try to actively generate entropy when required, and are thus hopefully
      avoiding the problem that caused the nice ext4 IO pattern fix to be
      reverted.
      
      So revert the revert.
      
      Cc: Ahmed S. Darwish <darwish.07@gmail.com>
      Cc: Ted Ts'o <tytso@mit.edu>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Alexander E. Patrakov <patrakov@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      02f03c42
    • L
      random: try to actively add entropy rather than passively wait for it · 50ee7529
      Linus Torvalds 提交于
      For 5.3 we had to revert a nice ext4 IO pattern improvement, because it
      caused a bootup regression due to lack of entropy at bootup together
      with arguably broken user space that was asking for secure random
      numbers when it really didn't need to.
      
      See commit 72dbcf72 (Revert "ext4: make __ext4_get_inode_loc plug").
      
      This aims to solve the issue by actively generating entropy noise using
      the CPU cycle counter when waiting for the random number generator to
      initialize.  This only works when you have a high-frequency time stamp
      counter available, but that's the case on all modern x86 CPU's, and on
      most other modern CPU's too.
      
      What we do is to generate jitter entropy from the CPU cycle counter
      under a somewhat complex load: calling the scheduler while also
      guaranteeing a certain amount of timing noise by also triggering a
      timer.
      
      I'm sure we can tweak this, and that people will want to look at other
      alternatives, but there's been a number of papers written on jitter
      entropy, and this should really be fairly conservative by crediting one
      bit of entropy for every timer-induced jump in the cycle counter.  Not
      because the timer itself would be all that unpredictable, but because
      the interaction between the timer and the loop is going to be.
      
      Even if (and perhaps particularly if) the timer actually happens on
      another CPU, the cacheline interaction between the loop that reads the
      cycle counter and the timer itself firing is going to add perturbations
      to the cycle counter values that get mixed into the entropy pool.
      
      As Thomas pointed out, with a modern out-of-order CPU, even quite simple
      loops show a fair amount of hard-to-predict timing variability even in
      the absense of external interrupts.  But this tries to take that further
      by actually having a fairly complex interaction.
      
      This is not going to solve the entropy issue for architectures that have
      no CPU cycle counter, but it's not clear how (and if) that is solvable,
      and the hardware in question is largely starting to be irrelevant.  And
      by doing this we can at least avoid some of the even more contentious
      approaches (like making the entropy waiting time out in order to avoid
      the possibly unbounded waiting).
      
      Cc: Ahmed Darwish <darwish.07@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Nicholas Mc Guire <hofrat@opentech.at>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: Alexander E. Patrakov <patrakov@gmail.com>
      Cc: Lennart Poettering <mzxreary@0pointer.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      50ee7529
    • O
      Merge tag 'fixes-5.4-merge-window' of... · 9bfd7319
      Olof Johansson 提交于
      Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes
      
      Fixes for omap variants
      
      Few fixes for ti-sysc interconnect target module driver for no-idle
      quirks that caused nfsroot to fail on some dra7 boards.
      
      And let's fixes to get LCD working again for logicpd board that got
      broken a while back with removal of panel-dpi driver. We need to now
      use generic CONFIG_DRM_PANEL_SIMPLE instead.
      
      * tag 'fixes-5.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
        bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle()
        ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux
        ARM: dts: am3517-evm: Fix missing video
        ARM: dts: logicpd-torpedo-baseboard: Fix missing video
        ARM: omap2plus_defconfig: Fix missing video
        bus: ti-sysc: Fix handling of invalid clocks
        bus: ti-sysc: Fix clock handling for no-idle quirks
      
      Link: https://lore.kernel.org/r/pull-1568819401-72461@atomide.comSigned-off-by: NOlof Johansson <olof@lixom.net>
      9bfd7319
    • O
      Merge tag 'scmi-fixes-5.4' of... · a4207a1c
      Olof Johansson 提交于
      Merge tag 'scmi-fixes-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes
      
      ARM SCMI fixes for v5.4
      
      Couple of fixes: one in scmi reset driver initialising missed scmi handle
      and an other in scmi reset API implementation fixing the assignment of
      reset state
      
      * tag 'scmi-fixes-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
        reset: reset-scmi: add missing handle initialisation
        firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset
      
      Link: https://lore.kernel.org/r/20190918142139.GA4370@bogusSigned-off-by: NOlof Johansson <olof@lixom.net>
      a4207a1c