1. 20 9月, 2020 2 次提交
  2. 18 9月, 2020 2 次提交
    • L
      mm: allow a controlled amount of unfairness in the page lock · 5ef64cc8
      Linus Torvalds 提交于
      Commit 2a9127fc ("mm: rewrite wait_on_page_bit_common() logic") made
      the page locking entirely fair, in that if a waiter came in while the
      lock was held, the lock would be transferred to the lockers strictly in
      order.
      
      That was intended to finally get rid of the long-reported watchdog
      failures that involved the page lock under extreme load, where a process
      could end up waiting essentially forever, as other page lockers stole
      the lock from under it.
      
      It also improved some benchmarks, but it ended up causing huge
      performance regressions on others, simply because fair lock behavior
      doesn't end up giving out the lock as aggressively, causing better
      worst-case latency, but potentially much worse average latencies and
      throughput.
      
      Instead of reverting that change entirely, this introduces a controlled
      amount of unfairness, with a sysctl knob to tune it if somebody needs
      to.  But the default value should hopefully be good for any normal load,
      allowing a few rounds of lock stealing, but enforcing the strict
      ordering before the lock has been stolen too many times.
      
      There is also a hint from Matthieu Baerts that the fair page coloring
      may end up exposing an ABBA deadlock that is hidden by the usual
      optimistic lock stealing, and while the unfairness doesn't fix the
      fundamental issue (and I'm still looking at that), it avoids it in
      practice.
      
      The amount of unfairness can be modified by writing a new value to the
      'sysctl_page_lock_unfairness' variable (default value of 5, exposed
      through /proc/sys/vm/page_lock_unfairness), but that is hopefully
      something we'd use mainly for debugging rather than being necessary for
      any deep system tuning.
      
      This whole issue has exposed just how critical the page lock can be, and
      how contended it gets under certain locks.  And the main contention
      doesn't really seem to be anything related to IO (which was the origin
      of this lock), but for things like just verifying that the page file
      mapping is stable while faulting in the page into a page table.
      
      Link: https://lore.kernel.org/linux-fsdevel/ed8442fd-6f54-dd84-cd4a-941e8b7ee603@MichaelLarabel.com/
      Link: https://www.phoronix.com/scan.php?page=article&item=linux-50-59&num=1
      Link: https://lore.kernel.org/linux-fsdevel/c560a38d-8313-51fb-b1ec-e904bd8836bc@tessares.net/Reported-and-tested-by: NMichael Larabel <Michael@michaellarabel.com>
      Tested-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Chris Mason <clm@fb.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Amir Goldstein <amir73il@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ef64cc8
    • A
      arm64: paravirt: Initialize steal time when cpu is online · 75df529b
      Andrew Jones 提交于
      Steal time initialization requires mapping a memory region which
      invokes a memory allocation. Doing this at CPU starting time results
      in the following trace when CONFIG_DEBUG_ATOMIC_SLEEP is enabled:
      
      BUG: sleeping function called from invalid context at mm/slab.h:498
      in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/1
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.9.0-rc5+ #1
      Call trace:
       dump_backtrace+0x0/0x208
       show_stack+0x1c/0x28
       dump_stack+0xc4/0x11c
       ___might_sleep+0xf8/0x130
       __might_sleep+0x58/0x90
       slab_pre_alloc_hook.constprop.101+0xd0/0x118
       kmem_cache_alloc_node_trace+0x84/0x270
       __get_vm_area_node+0x88/0x210
       get_vm_area_caller+0x38/0x40
       __ioremap_caller+0x70/0xf8
       ioremap_cache+0x78/0xb0
       memremap+0x9c/0x1a8
       init_stolen_time_cpu+0x54/0xf0
       cpuhp_invoke_callback+0xa8/0x720
       notify_cpu_starting+0xc8/0xd8
       secondary_start_kernel+0x114/0x180
      CPU1: Booted secondary processor 0x0000000001 [0x431f0a11]
      
      However we don't need to initialize steal time at CPU starting time.
      We can simply wait until CPU online time, just sacrificing a bit of
      accuracy by returning zero for steal time until we know better.
      
      While at it, add __init to the functions that are only called by
      pv_time_init() which is __init.
      Signed-off-by: NAndrew Jones <drjones@redhat.com>
      Fixes: e0685fa2 ("arm64: Retrieve stolen time as paravirtualized guest")
      Cc: stable@vger.kernel.org
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Link: https://lore.kernel.org/r/20200916154530.40809-1-drjones@redhat.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      75df529b
  3. 17 9月, 2020 1 次提交
  4. 16 9月, 2020 1 次提交
    • J
      serial: core: fix console port-lock regression · e0830dbf
      Johan Hovold 提交于
      Fix the port-lock initialisation regression introduced by commit
      a3cb39d2 ("serial: core: Allow detach and attach serial device for
      console") by making sure that the lock is again initialised during
      console setup.
      
      The console may be registered before the serial controller has been
      probed in which case the port lock needs to be initialised during
      console setup by a call to uart_set_options(). The console-detach
      changes introduced a regression in several drivers by effectively
      removing that initialisation by not initialising the lock when the port
      is used as a console (which is always the case during console setup).
      
      Add back the early lock initialisation and instead use a new
      console-reinit flag to handle the case where a console is being
      re-attached through sysfs.
      
      The question whether the console-detach interface should have been added
      in the first place is left for another discussion.
      
      Note that the console-enabled check in uart_set_options() is not
      redundant because of kgdboc, which can end up reinitialising an already
      enabled console (see commit 42b6a1ba ("serial_core: Don't
      re-initialize a previously initialized spinlock.")).
      
      Fixes: a3cb39d2 ("serial: core: Allow detach and attach serial device for console")
      Cc: stable <stable@vger.kernel.org>     # 5.7
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Link: https://lore.kernel.org/r/20200909143101.15389-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0830dbf
  5. 11 9月, 2020 3 次提交
  6. 09 9月, 2020 1 次提交
  7. 07 9月, 2020 1 次提交
  8. 06 9月, 2020 1 次提交
  9. 05 9月, 2020 2 次提交
  10. 04 9月, 2020 3 次提交
  11. 03 9月, 2020 2 次提交
  12. 01 9月, 2020 1 次提交
    • M
      HID: core: Sanitize event code and type when mapping input · 35556bed
      Marc Zyngier 提交于
      When calling into hid_map_usage(), the passed event code is
      blindly stored as is, even if it doesn't fit in the associated bitmap.
      
      This event code can come from a variety of sources, including devices
      masquerading as input devices, only a bit more "programmable".
      
      Instead of taking the event code at face value, check that it actually
      fits the corresponding bitmap, and if it doesn't:
      - spit out a warning so that we know which device is acting up
      - NULLify the bitmap pointer so that we catch unexpected uses
      
      Code paths that can make use of untrusted inputs can now check
      that the mapping was indeed correct and bail out if not.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMarc Zyngier <maz@kernel.org>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
      35556bed
  13. 29 8月, 2020 3 次提交
  14. 27 8月, 2020 4 次提交
  15. 26 8月, 2020 5 次提交
  16. 25 8月, 2020 1 次提交
  17. 24 8月, 2020 3 次提交
  18. 21 8月, 2020 3 次提交
  19. 20 8月, 2020 1 次提交
    • F
      netfilter: conntrack: allow sctp hearbeat after connection re-use · cc5453a5
      Florian Westphal 提交于
      If an sctp connection gets re-used, heartbeats are flagged as invalid
      because their vtag doesn't match.
      
      Handle this in a similar way as TCP conntrack when it suspects that the
      endpoints and conntrack are out-of-sync.
      
      When a HEARTBEAT request fails its vtag validation, flag this in the
      conntrack state and accept the packet.
      
      When a HEARTBEAT_ACK is received with an invalid vtag in the reverse
      direction after we allowed such a HEARTBEAT through, assume we are
      out-of-sync and re-set the vtag info.
      
      v2: remove left-over snippet from an older incarnation that moved
          new_state/old_state assignments, thats not needed so keep that
          as-is.
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      cc5453a5