20 Oct, 2018

40 commits

  • Greg Kroah-Hartman
     
  • commit b4a4957d3d1c328b733fce783b7264996f866ad2 upstream.

    rvt_destroy_qp() cannot complete until all in process packets have
    been released from the underlying hardware. If a link down event
    occurs, an application can hang with a kernel stack similar to:

    cat /proc//stack
    quiesce_qp+0x178/0x250 [hfi1]
    rvt_reset_qp+0x23d/0x400 [rdmavt]
    rvt_destroy_qp+0x69/0x210 [rdmavt]
    ib_destroy_qp+0xba/0x1c0 [ib_core]
    nvme_rdma_destroy_queue_ib+0x46/0x80 [nvme_rdma]
    nvme_rdma_free_queue+0x3c/0xd0 [nvme_rdma]
    nvme_rdma_destroy_io_queues+0x88/0xd0 [nvme_rdma]
    nvme_rdma_error_recovery_work+0x52/0xf0 [nvme_rdma]
    process_one_work+0x17a/0x440
    worker_thread+0x126/0x3c0
    kthread+0xcf/0xe0
    ret_from_fork+0x58/0x90
    0xffffffffffffffff

    quiesce_qp() waits until all outstanding packets have been freed.
    This wait should be momentary. During a link down event, the cleanup
    handling does not ensure that all packets caught by the link down are
    flushed properly.

    This is caused by the fact that the freeze path and the link down
    event is handled the same. This is not correct. The freeze path
    waits until the HFI is unfrozen and then restarts PIO. A link down
    is not a freeze event. The link down path cannot restart the PIO
    until link is restored. If the PIO path is restarted before the link
    comes up, the application (QP) using the PIO path will hang (until
    link is restored).

    Fix by separating the linkdown path from the freeze path and use the
    link down path for link down events.

    Close a race condition sc_disable() by acquiring both the progress
    and release locks.

    Close a race condition in sc_stop() by moving the setting of the flag
    bits under the alloc lock.

    Cc: # 4.9.x+
    Fixes: 7724105686e7 ("IB/hfi1: add driver files")
    Reviewed-by: Mike Marciniszyn
    Signed-off-by: Michael J. Ruhl
    Signed-off-by: Dennis Dalessandro
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Greg Kroah-Hartman

    Michael J. Ruhl
     
  • commit 2b16fd63059ab9a46d473620749672dc342e1d21 upstream.

    On Gen3, we can only do RXDMA once per transfer reliably. For that, we
    must reset the device, then we can have RXDMA once. This patch
    implements this. When there is no reset controller or the reset fails,
    RXDMA will be blocked completely. Otherwise, it will be disabled after
    the first RXDMA transfer. Based on a commit from the BSP by Hiromitsu
    Yamasaki, yet completely refactored to handle multiple read messages
    within one transfer.

    Signed-off-by: Wolfram Sang
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Wolfram Sang
    Cc: stable@kernel.org
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Wolfram Sang
     
  • commit 0ca9488193e61ec5f31a631d8147f74525629e8a upstream.

    On GLK NUC platforms the HDMI retiming buffer needs additional disabled
    time to correctly sync to a faster incoming signal.

    When measured on a scope the highspeed lines of the HDMI clock turn off
    for ~400uS during a normal resolution change. The HDMI retimer on the
    GLK NUC appears to require at least a full frame of quiet time before a
    new faster clock can be correctly sync'd. Wait 100ms due to msleep
    inaccuracies while waiting for a completed frame. Add a quirk to the
    driver for GLK boards that use ITE66317 HDMI retimers.

    V2: Add more devices to the quirk list
    V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
    V4: crtc type check extended to include _DDI and whitespace fixes
    v5: Fix white spaces, remove the macro for delay. Revert the crtc type
    check introduced in v4.

    Cc: Imre Deak
    Cc: # v4.14+
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
    Signed-off-by: Clint Taylor
    Tested-by: Daniel Scheller
    Signed-off-by: Radhakrishna Sripada
    Signed-off-by: Imre Deak
    Reviewed-by: Imre Deak
    Link: https://patchwork.freedesktop.org/patch/msgid/20180710200205.1478-1-radhakrishna.sripada@intel.com
    (cherry picked from commit 90c3e2198777aaa355b6994a31a79c636c8d4306)
    Signed-off-by: Rodrigo Vivi
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Clint Taylor
     
  • commit 15d36fecd0bdc7510b70a0e5ec6671140b3fce0c upstream.

    When pmem namespaces created are smaller than section size, this can
    cause an issue during removal and gpf was observed:

    general protection fault: 0000 1 SMP PTI
    CPU: 36 PID: 3941 Comm: ndctl Tainted: G W 4.14.28-1.el7uek.x86_64 #2
    task: ffff88acda150000 task.stack: ffffc900233a4000
    RIP: 0010:__put_page+0x56/0x79
    Call Trace:
    devm_memremap_pages_release+0x155/0x23a
    release_nodes+0x21e/0x260
    devres_release_all+0x3c/0x48
    device_release_driver_internal+0x15c/0x207
    device_release_driver+0x12/0x14
    unbind_store+0xba/0xd8
    drv_attr_store+0x27/0x31
    sysfs_kf_write+0x3f/0x46
    kernfs_fop_write+0x10f/0x18b
    __vfs_write+0x3a/0x16d
    vfs_write+0xb2/0x1a1
    SyS_write+0x55/0xb9
    do_syscall_64+0x79/0x1ae
    entry_SYSCALL_64_after_hwframe+0x3d/0x0

    Add code to check whether we have a mapping already in the same section
    and prevent additional mappings from being created if that is the case.

    Link: http://lkml.kernel.org/r/152909478401.50143.312364396244072931.stgit@djiang5-desk3.ch.intel.com
    Signed-off-by: Dave Jiang
    Cc: Dan Williams
    Cc: Robert Elliott
    Cc: Jeff Moyer
    Cc: Matthew Wilcox
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Dave Jiang
     
  • commit 2f7caf6b02145bd9cd9d0b56204f51a5fefe7790 upstream.

    If we ran out of DMA pool buffers, we get into the unmap
    code path with a NULL before. Deal with this by checking
    the virtual mapping is not NULL.

    Cc: stable@vger.kernel.org
    Signed-off-by: Gilad Ben-Yossef
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Gilad Ben-Yossef
     
  • commit 05c72e77ccda89ff624108b1b59a0fc43843f343 upstream.

    We broke the LVDS notifier resume thing in (presumably) commit
    e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as
    we no longer duplicate the current state in the LVDS notifier and
    thus we never resume it properly either.

    Instead of trying to fix it again let's just kill off the lid
    notifier entirely. None of the machines tested thus far have
    apparently needed it. Originally the lid notifier was added to
    work around cases where the VBIOS was clobbering some of the
    hardware state behind the driver's back, mostly on Thinkpads.
    We now have a few report of Thinkpads working just fine without
    the notifier. So maybe it was misdiagnosed originally, or
    something else has changed (ACPI video stuff perhaps?).

    If we do end up finding a machine where the VBIOS is still causing
    problems I would suggest that we first try setting various bits in
    the VBIOS scratch registers. There are several to choose from that
    may instruct the VBIOS to steer clear.

    With the notifier gone we'll also stop looking at the panel status
    in ->detect().

    v2: Nuke enum modeset_restore (Rodrigo)

    Cc: stable@vger.kernel.org
    Cc: Wolfgang Draxinger
    Cc: Vito Caputo
    Cc: kitsunyan
    Cc: Joonas Saarinen
    Tested-by: Vito Caputo # Thinkapd X61s
    Tested-by: kitsunyan # ThinkPad X200
    Tested-by: Joonas Saarinen # Fujitsu Siemens U9210
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902
    References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html
    References: https://bugs.freedesktop.org/show_bug.cgi?id=21230
    Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
    Signed-off-by: Ville Syrjälä
    Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com
    Reviewed-by: Rodrigo Vivi
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Ville Syrjälä
     
  • Commit b6cc0ba2cbf4 (HID: add support for Apple Magic Keyboards)
    backported support for the Magic Keyboard over Bluetooth, but did not
    add the BT_VENDOR_ID_APPLE to hid_have_special_driver[] so the hid-apple
    driver is never loaded and Fn key does not work at all.

    Adding BT_VENDOR_ID_APPLE to hid_have_special_driver[] is not needed
    after commit e04a0442d33b (HID: core: remove the absolute need of
    hid_have_special_driver[]), so 4.16 kernels and newer does not need it.

    Fixes: b6cc0ba2cbf4 (HID: add support for Apple Magic Keyboards)
    Bugzilla-id: https://bugzilla.kernel.org/show_bug.cgi?id=99881
    Signed-off-by: Natanael Copa
    Acked-by: Benjamin Tissoires
    Signed-off-by: Greg Kroah-Hartman

    Natanael Copa
     
  • commit 40660f1fcee8d524a60b5101538e42b1f39f106d upstream.

    There's not much sense in doing that because if user or
    his build-system didn't set CROSS_COMPILE we still may
    very well make incorrect guess.

    But as it turned out setting CROSS_COMPILE is not as harmless
    as one may think: with recent changes that implemented automatic
    discovery of __host__ gcc features unconditional setup of
    CROSS_COMPILE leads to failures on execution of "make xxx_defconfig"
    with absent cross-compiler, for more info see [1].

    Set CROSS_COMPILE as well gets in the way if we want only to build
    .dtb's (again with absent cross-compiler which is not really needed
    for building .dtb's), see [2].

    Note, we had to change LIBGCC assignment type from ":=" to "="
    so that is is resolved on its usage, otherwise if it is resolved
    at declaration time with missing CROSS_COMPILE we're getting this
    error message from host GCC:

    | gcc: error: unrecognized command line option -mmedium-calls
    | gcc: error: unrecognized command line option -mno-sdata

    [1] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004308.html
    [2] http://lists.infradead.org/pipermail/linux-snps-arc/2018-September/004320.html

    Signed-off-by: Alexey Brodkin
    Cc: Masahiro Yamada
    Cc: Rob Herring
    Signed-off-by: Vineet Gupta
    Signed-off-by: Greg Kroah-Hartman

    Alexey Brodkin
     
  • commit 615f64458ad890ef94abc879a66d8b27236e733a upstream.

    This check is very naive: we simply test if GCC invoked without
    "-mcpu=XXX" has ARC700 define set. In that case we think that GCC
    was built with "--with-cpu=arc700" and has libgcc built for ARC700.

    Otherwise if ARC700 is not defined we think that everythng was built
    for ARCv2.

    But in reality our life is much more interesting.

    1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu"
    it may generate code for any ARC core).

    2. libgcc might be built with explicitly specified "--mcpu=YYY"

    That's exactly what happens in case of multilibbed toolchains:
    - GCC is configured with default settings
    - All the libs built for many different CPU flavors

    I.e. that check gets in the way of usage of multilibbed
    toolchains. And even non-multilibbed toolchains are affected.
    OpenEmbedded also builds GCC without "--with-cpu" because
    each and every target component later is compiled with explicitly
    set "-mcpu=ZZZ".

    Acked-by: Rob Herring
    Signed-off-by: Alexey Brodkin
    Signed-off-by: Vineet Gupta
    Signed-off-by: Greg Kroah-Hartman

    Alexey Brodkin
     
  • commit eb66ae030829605d61fbef1909ce310e29f78821 upstream.

    Jann Horn points out that our TLB flushing was subtly wrong for the
    mremap() case. What makes mremap() special is that we don't follow the
    usual "add page to list of pages to be freed, then flush tlb, and then
    free pages". No, mremap() obviously just _moves_ the page from one page
    table location to another.

    That matters, because mremap() thus doesn't directly control the
    lifetime of the moved page with a freelist: instead, the lifetime of the
    page is controlled by the page table locking, that serializes access to
    the entry.

    As a result, we need to flush the TLB not just before releasing the lock
    for the source location (to avoid any concurrent accesses to the entry),
    but also before we release the destination page table lock (to avoid the
    TLB being flushed after somebody else has already done something to that
    page).

    This also makes the whole "need_flush" logic unnecessary, since we now
    always end up flushing the TLB for every valid entry.

    Reported-and-tested-by: Jann Horn
    Acked-by: Will Deacon
    Tested-by: Ingo Molnar
    Acked-by: Peter Zijlstra (Intel)
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Linus Torvalds
     
  • This reverts commit 4f4374a9bd25b333971e6f2656b642d29e2efe7b which was
    commit a6795a585929d94ca3e931bc8518f8deb8bbe627 upstream.

    Turns out this causes problems and was to fix a patch only in the 4.19
    and newer tree.

    Reported-by: Amir Goldstein
    Cc: Miklos Szeredi
    Cc: Christoph Hellwig
    Cc: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • commit 8183d99f4a22c2abbc543847a588df3666ef0c0c upstream.

    feature fixups need to use patch_instruction() early in the boot,
    even before the code is relocated to its final address, requiring
    patch_instruction() to use PTRRELOC() in order to address data.

    But feature fixups applies on code before it is set to read only,
    even for modules. Therefore, feature fixups can use
    raw_patch_instruction() instead.

    Signed-off-by: Christophe Leroy
    Signed-off-by: Michael Ellerman
    Reported-by: David Gounaris
    Tested-by: David Gounaris
    Signed-off-by: Greg Kroah-Hartman

    Christophe Leroy
     
  • [ Upstream commit 5ebb1bc2d63d90dd204169e21fd7a0b4bb8c776e ]

    ACPI HID devices do not actually have an alias for
    them in the IVRS. But dev_data->alias is still used
    for indexing into the IOMMU device table for devices
    being handled by the IOMMU. So for ACPI HID devices,
    we simply return the corresponding devid as an alias,
    as parsed from IVRS table.

    Signed-off-by: Arindam Nath
    Fixes: 2bf9a0a12749 ('iommu/amd: Add iommu support for ACPI HID devices')
    Signed-off-by: Joerg Roedel
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Arindam Nath
     
  • [ Upstream commit 96dc89d526ef77604376f06220e3d2931a0bfd58 ]

    Current we store the userspace r1 to PACATMSCRATCH before finally
    saving it to the thread struct.

    In theory an exception could be taken here (like a machine check or
    SLB miss) that could write PACATMSCRATCH and hence corrupt the
    userspace r1. The SLB fault currently doesn't touch PACATMSCRATCH, but
    others do.

    We've never actually seen this happen but it's theoretically
    possible. Either way, the code is fragile as it is.

    This patch saves r1 to the kernel stack (which can't fault) before we
    turn MSR[RI] back on. PACATMSCRATCH is still used but only with
    MSR[RI] off. We then copy r1 from the kernel stack to the thread
    struct once we have MSR[RI] back on.

    Suggested-by: Breno Leitao
    Signed-off-by: Michael Neuling
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Neuling
     
  • [ Upstream commit cf13435b730a502e814c63c84d93db131e563f5f ]

    When we treclaim we store the userspace checkpointed r13 to a scratch
    SPR and then later save the scratch SPR to the user thread struct.

    Unfortunately, this doesn't work as accessing the user thread struct
    can take an SLB fault and the SLB fault handler will write the same
    scratch SPRG that now contains the userspace r13.

    To fix this, we store r13 to the kernel stack (which can't fault)
    before we access the user thread struct.

    Found by running P8 guest + powervm + disable_1tb_segments + TM. Seen
    as a random userspace segfault with r13 looking like a kernel address.

    Signed-off-by: Michael Neuling
    Reviewed-by: Breno Leitao
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Neuling
     
  • [ Upstream commit 4451d3f59f2a6f95e5d205c2d04ea072955d080d ]

    Currently, the aspeed MATCH1 register is updated to in set_next_event handler, with the assumption that COUNT
    register value is preserved when the timer is disabled and it continues
    decrementing after the timer is enabled. But the assumption is wrong:
    RELOAD register is loaded into COUNT register when the aspeed timer is
    enabled, which means the next event may be delayed because timer
    interrupt won't be generated until .

    The problem can be fixed by updating RELOAD register to , and
    COUNT register will be re-loaded when the timer is enabled and interrupt
    is generated when COUNT register overflows.

    The test result on Facebook Backpack-CMM BMC hardware (AST2500) shows
    the issue is fixed: without the patch, usleep(100) suspends the process
    for several milliseconds (and sometimes even over 40 milliseconds);
    after applying the fix, usleep(100) takes averagely 240 microseconds to
    return under the same workload level.

    Signed-off-by: Tao Ren
    Reviewed-by: Linus Walleij
    Tested-by: Lei YU
    Signed-off-by: Daniel Lezcano
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Tao Ren
     
  • [ Upstream commit 8ac1ee6f4d62e781e3b3fd8b9c42b70371427669 ]

    Clang warns that the address of a pointer will always evaluated as true
    in a boolean context:

    drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of
    array 'eq->affinity_mask' will always evaluate to 'true'
    [-Wpointer-bool-conversion]
    if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask))
    ~~~~~^~~~~~~~~~~~~
    1 warning generated.

    Use cpumask_available, introduced in commit f7e30f01a9e2 ("cpumask: Add
    helper cpumask_available()"), which does the proper checking and avoids
    this warning.

    Link: https://github.com/ClangBuiltLinux/linux/issues/86
    Signed-off-by: Nathan Chancellor
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Nathan Chancellor
     
  • [ Upstream commit f1f1fadacaf08b7cf11714c0c29f8fa4d4ef68a9 ]

    When sd_init_command() get's a command with a unknown req_op() it crashes the
    system via BUG().

    This makes debugging the actual reason for the broken request cmd_flags pretty
    hard as the system is down before it's able to write out debugging data on the
    serial console or the trace buffer.

    Change the BUG() to a WARN_ON() and return BLKPREP_KILL to fail gracefully and
    return an I/O error to the producer of the request.

    Signed-off-by: Johannes Thumshirn
    Cc: Hannes Reinecke
    Cc: Bart Van Assche
    Cc: Christoph Hellwig
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Bart Van Assche
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Johannes Thumshirn
     
  • [ Upstream commit 318ddb34b2052f838aa243d07173e2badf3e630e ]

    While dlpar adding primary ipr adapter back, driver goes through adapter
    initialization then schedule ipr_worker_thread to start te disk scan by
    dropping the host lock, calling scsi_add_device. Then get the adapter reset
    request again, so driver does scsi_block_requests, this will cause the
    scsi_add_device get hung until we unblock. But we can't run ipr_worker_thread
    to do the unblock because its stuck in scsi_add_device.

    This patch fixes the issue.

    [mkp: typo and whitespace fixes]

    Signed-off-by: Wen Xiong
    Acked-by: Brian King
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Wen Xiong
     
  • [ Upstream commit 69be1984ded00a11b1ed0888c6d8e4f35370372f ]

    Currently, if userspace calls drm_wait_vblank before the crtc is
    activated the crtc vblank_enable hook is called, which in case of
    malidp driver triggers some warninngs. This happens because on
    device init we don't inform the drm core about the vblank state
    by calling drm_crtc_vblank_on/off/reset which together with
    drm_vblank_get have some magic that prevents calling drm_vblank_enable
    when crtc is off.

    Signed-off-by: Alexandru Gheorghe
    Acked-by: Liviu Dudau
    Signed-off-by: Liviu Dudau
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Alexandru Gheorghe
     
  • [ Upstream commit 9024143e700f89d74b8cdaf316a3499d74fc56fe ]

    When programming the inbound/outbound ATUs, we call usleep_range() after
    each checking PCIE_ATU_ENABLE bit. Unfortunately, the ATU programming
    can be executed in atomic context:

    inbound ATU programming could be called through
    pci_epc_write_header()
    =>dw_pcie_ep_write_header()
    =>dw_pcie_prog_inbound_atu()

    outbound ATU programming could be called through
    pci_bus_read_config_dword()
    =>dw_pcie_rd_conf()
    =>dw_pcie_prog_outbound_atu()

    Fix this issue by calling mdelay() instead.

    Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
    Fixes: d8bbeb39fbf3 ("PCI: designware: Wait for iATU enable")
    Signed-off-by: Jisheng Zhang
    [lorenzo.pieralisi@arm.com: commit log update]
    Signed-off-by: Lorenzo Pieralisi
    Signed-off-by: Bjorn Helgaas
    Acked-by: Gustavo Pimentel
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jisheng Zhang
     
  • [ Upstream commit 2fe397a3959de8a472f165e6d152f64cb77fa2cc ]

    EtherAVB hardware requires 0 to be written to status register bits in
    order to clear them, however, care must be taken not to:

    1. Clear other bits, by writing zero to them
    2. Write one to reserved bits

    This patch corrects the ravb driver with respect to the second point above.
    This is done by defining reserved bit masks for the affected registers and,
    after auditing the code, ensure all sites that may write a one to a
    reserved bit use are suitably masked.

    Signed-off-by: Kazuya Mizuguchi
    Signed-off-by: Simon Horman
    Reviewed-by: Sergei Shtylyov
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Kazuya Mizuguchi
     
  • [ Upstream commit 08e39982ef64f800fd1f9b9b92968d14d5fafa82 ]

    On the Netgear WNDAP620, the emac ethernet isn't receiving nor
    xmitting any frames from/to the RTL8363SB (identifies itself
    as a RTL8367RB).

    This is caused by the emac hardware not knowing the forced link
    parameters for speed, duplex, pause, etc.

    This begs the question, how this was working on the original
    driver code, when it was necessary to set the phy_address and
    phy_map to 0xffffffff. But I guess without access to the old
    PPC405/440/460 hardware, it's not possible to know.

    Signed-off-by: Christian Lamparter
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Christian Lamparter
     
  • [ Upstream commit 52d2c7bf7c90217fbe875d2d76f310979c48eb83 ]

    The CapsLock key on Atari keyboards is not a toggle, it does send the
    normal make and break scancodes.

    Drop the CapsLock toggle handling code, which did cause the CapsLock
    key to merely act as a Shift key.

    Tested-by: Michael Schmitz
    Signed-off-by: Michael Schmitz
    Signed-off-by: Andreas Schwab
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Michael Schmitz
     
  • [ Upstream commit 9e62df51be993035c577371ffee5477697a56aad ]

    Fix errors in Atari keymap (mostly in keypad, help and undo keys).

    Patch provided on debian-68k ML by Andreas Schwab ,
    keymap array size and unhandled scancode limit adjusted to 0x73 by me.

    Tested-by: Michael Schmitz
    Signed-off-by: Michael Schmitz
    Signed-off-by: Andreas Schwab
    Signed-off-by: Dmitry Torokhov
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Andreas Schwab
     
  • [ Upstream commit 59d08d00d43c644ee2011d7ff1807bdd69f31fe0 ]

    This adds Intel(R) Trace Hub PCI ID for Ice Lake PCH.

    Signed-off-by: Alexander Shishkin
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Alexander Shishkin
     
  • [ Upstream commit adad633af7b970bfa5dd1b624a4afc83cac9b235 ]

    While reviewing another part of the code, Kees noticed that the strncpy of the
    partition name might not always be NUL terminated. Switch to using strscpy
    which does this safely.

    Reported-by: Kees Cook
    Signed-off-by: Laura Abbott
    Reviewed-by: Kees Cook
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Laura Abbott
     
  • [ Upstream commit d792d4c4fc866ae224b0b0ca2aabd87d23b4d6cc ]

    There's currently a warning about string overflow with strncat:

    drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c: In function 'ibmvscsis_probe':
    drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c:3479:2: error: 'strncat' specified
    bound 64 equals destination size [-Werror=stringop-overflow=]
    strncat(vscsi->eye, vdev->name, MAX_EYE);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Switch to a single snprintf instead of a strcpy + strcat to handle this
    cleanly.

    Signed-off-by: Laura Abbott
    Suggested-by: Kees Cook
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Laura Abbott
     
  • [ Upstream commit 3b7d96a0dbb6b630878597a1838fc39f808b761b ]

    The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
    add the flag for all the other SoCs.

    Reported-by: Tony Lindgren
    Signed-off-by: Keerthy
    Acked-by: Tony Lindgren
    Signed-off-by: Daniel Lezcano
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Keerthy
     
  • [ Upstream commit 4c4af6900844ab04c9434c972021d7b48610e06a ]

    The hardif_neigh refcounter is to be decreased by the queued work and
    currently is never decreased if the queue_work() call fails.
    Fix by checking the queue_work() return value and decrease refcount
    if necessary.

    Signed-off-by: Marek Lindner
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Marek Lindner
     
  • [ Upstream commit 5af96b9c59c72fb2af2d19c5cc2f3cdcee391dff ]

    The backbone_gw refcounter is to be decreased by the queued work and
    currently is never decreased if the queue_work() call fails.
    Fix by checking the queue_work() return value and decrease refcount
    if necessary.

    Signed-off-by: Marek Lindner
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Marek Lindner
     
  • [ Upstream commit ae3cdc97dc10c7a3b31f297dab429bfb774c9ccb ]

    The function batadv_tvlv_handler_register is responsible for adding new
    tvlv_handler to the handler_list. It first checks whether the entry
    already is in the list or not. If it is, then the creation of a new entry
    is aborted.

    But the lock for the list is only held when the list is really modified.
    This could lead to duplicated entries because another context could create
    an entry with the same key between the check and the list manipulation.

    The check and the manipulation of the list must therefore be in the same
    locked code section.

    Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure")
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit e7136e48ffdfb9f37b0820f619380485eb407361 ]

    The function batadv_tt_global_orig_entry_add is responsible for adding new
    tt_orig_list_entry to the orig_list. It first checks whether the entry
    already is in the list or not. If it is, then the creation of a new entry
    is aborted.

    But the lock for the list is only held when the list is really modified.
    This could lead to duplicated entries because another context could create
    an entry with the same key between the check and the list manipulation.

    The check and the manipulation of the list must therefore be in the same
    locked code section.

    Fixes: d657e621a0f5 ("batman-adv: add reference counting for type batadv_tt_orig_list_entry")
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit 94cb82f594ed86be303398d6dfc7640a6f1d45d4 ]

    The function batadv_softif_vlan_get is responsible for adding new
    softif_vlan to the softif_vlan_list. It first checks whether the entry
    already is in the list or not. If it is, then the creation of a new entry
    is aborted.

    But the lock for the list is only held when the list is really modified.
    This could lead to duplicated entries because another context could create
    an entry with the same key between the check and the list manipulation.

    The check and the manipulation of the list must therefore be in the same
    locked code section.

    Fixes: 5d2c05b21337 ("batman-adv: add per VLAN interface attribute framework")
    Signed-off-by: Sven Eckelmann
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit fa122fec8640eb7186ce5a41b83a4c1744ceef8f ]

    The function batadv_nc_get_nc_node is responsible for adding new nc_nodes
    to the in_coding_list and out_coding_list. It first checks whether the
    entry already is in the list or not. If it is, then the creation of a new
    entry is aborted.

    But the lock for the list is only held when the list is really modified.
    This could lead to duplicated entries because another context could create
    an entry with the same key between the check and the list manipulation.

    The check and the manipulation of the list must therefore be in the same
    locked code section.

    Fixes: d56b1705e28c ("batman-adv: network coding - detect coding nodes and remove these after timeout")
    Signed-off-by: Sven Eckelmann
    Acked-by: Marek Lindner
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit dff9bc42ab0b2d38c5e90ddd79b238fed5b4c7ad ]

    The function batadv_gw_node_add is responsible for adding new gw_node to
    the gateway_list. It is expecting that the caller already checked that
    there is not already an entry with the same key or not.

    But the lock for the list is only held when the list is really modified.
    This could lead to duplicated entries because another context could create
    an entry with the same key between the check and the list manipulation.

    The check and the manipulation of the list must therefore be in the same
    locked code section.

    Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
    Signed-off-by: Sven Eckelmann
    Acked-by: Marek Lindner
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit a25bab9d723a08bd0bdafb1529faf9094c690b70 ]

    The per hardif sysfs file "batman_adv/elp_interval" is using the generic
    functions to store/show uint values. The helper __batadv_store_uint_attr
    requires the softif net_device as parameter to print the resulting change
    as info text when the users writes to this file. It uses the helper
    function batadv_info to add it at the same time to the kernel ring buffer
    and to the batman-adv debug log (when CONFIG_BATMAN_ADV_DEBUG is enabled).

    The function batadv_info requires as first parameter the batman-adv softif
    net_device. This parameter is then used to find the private buffer which
    contains the debug log for this batman-adv interface. But
    batadv_store_throughput_override used as first argument the slave
    net_device. This slave device doesn't have the batadv_priv private data
    which is access by batadv_info.

    Writing to this file with CONFIG_BATMAN_ADV_DEBUG enabled can either lead
    to a segfault or to memory corruption.

    Fixes: 0744ff8fa8fa ("batman-adv: Add hard_iface specific sysfs wrapper macros for UINT")
    Signed-off-by: Sven Eckelmann
    Acked-by: Marek Lindner
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit b9fd14c20871e6189f635e49b32d7789e430b3c8 ]

    The per hardif sysfs file "batman_adv/throughput_override" prints the
    resulting change as info text when the users writes to this file. It uses
    the helper function batadv_info to add it at the same time to the kernel
    ring buffer and to the batman-adv debug log (when CONFIG_BATMAN_ADV_DEBUG
    is enabled).

    The function batadv_info requires as first parameter the batman-adv softif
    net_device. This parameter is then used to find the private buffer which
    contains the debug log for this batman-adv interface. But
    batadv_store_throughput_override used as first argument the slave
    net_device. This slave device doesn't have the batadv_priv private data
    which is access by batadv_info.

    Writing to this file with CONFIG_BATMAN_ADV_DEBUG enabled can either lead
    to a segfault or to memory corruption.

    Fixes: 0b5ecc6811bd ("batman-adv: add throughput override attribute to hard_ifaces")
    Signed-off-by: Sven Eckelmann
    Acked-by: Marek Lindner
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann
     
  • [ Upstream commit 88d0895d0ea9d4431507d576c963f2ff9918144d ]

    The probe ELPs for WiFi interfaces are expanded to contain at least
    BATADV_ELP_MIN_PROBE_SIZE bytes. This is usually a lot more than the
    number of bytes which the template ELP packet requires.

    These extra padding bytes were not initialized and thus could contain data
    which were previously stored at the same location. It is therefore required
    to set it to some predefined or random values to avoid leaking private
    information from the system transmitting these kind of packets.

    Fixes: e4623c913508 ("batman-adv: Avoid probe ELP information leak")
    Signed-off-by: Sven Eckelmann
    Acked-by: Antonio Quartulli
    Signed-off-by: Simon Wunderlich
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Sven Eckelmann