Список изменений в Linux 4.14.294

 
drm/msm/rd: Fix FIFO-full deadlock [+ + +]
Author: Rob Clark <robdclark@chromium.org>
Date:   Sun Aug 7 09:09:01 2022 -0700

    drm/msm/rd: Fix FIFO-full deadlock
    
    [ Upstream commit 174974d8463b77c2b4065e98513adb204e64de7d ]
    
    If the previous thing cat'ing $debugfs/rd left the FIFO full, then
    subsequent open could deadlock in rd_write() (because open is blocked,
    not giving a chance for read() to consume any data in the FIFO).  Also
    it is generally a good idea to clear out old data from the FIFO.
    
    Signed-off-by: Rob Clark <robdclark@chromium.org>
    Patchwork: https://patchwork.freedesktop.org/patch/496706/
    Link: https://lore.kernel.org/r/20220807160901.2353471-2-robdclark@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo [+ + +]
Author: Jason Wang <wangborong@cdjrlc.com>
Date:   Thu Aug 4 08:58:14 2022 +0800

    HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
    
    [ Upstream commit 94553f8a218540d676efbf3f7827ed493d1057cf ]
    
    The double `like' is duplicated in the comment, remove one.
    
    Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ieee802154: cc2520: add rc code in cc2520_tx() [+ + +]
Author: Li Qiong <liqiong@nfschina.com>
Date:   Mon Aug 29 15:12:59 2022 +0800

    ieee802154: cc2520: add rc code in cc2520_tx()
    
    [ Upstream commit ffd7bdddaab193c38416fd5dd416d065517d266e ]
    
    The rc code is 0 at the error path "status & CC2520_STATUS_TX_UNDERFLOW".
    Assign rc code with '-EINVAL' at this error path to fix it.
    
    Signed-off-by: Li Qiong <liqiong@nfschina.com>
    Link: https://lore.kernel.org/r/20220829071259.18330-1-liqiong@nfschina.com
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 4.14.294 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Sep 20 11:51:31 2022 +0200

    Linux 4.14.294
    
    Link: https://lore.kernel.org/r/20220916100441.528608977@linuxfoundation.org
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region() [+ + +]
Author: Jann Horn <jannh@google.com>
Date:   Thu Sep 15 16:25:19 2022 +0200

    mm: Fix TLB flush for not-first PFNMAP mappings in unmap_region()
    
    This is a stable-specific patch.
    I botched the stable-specific rewrite of
    commit b67fbebd4cf98 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"):
    As Hugh pointed out, unmap_region() actually operates on a list of VMAs,
    and the variable "vma" merely points to the first VMA in that list.
    So if we want to check whether any of the VMAs we're operating on is
    PFNMAP or MIXEDMAP, we have to iterate through the list and check each VMA.
    
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes [+ + +]
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Aug 29 18:35:44 2022 +0200

    platform/x86: acer-wmi: Acer Aspire One AOD270/Packard Bell Dot keymap fixes
    
    [ Upstream commit c3b82d26bc85f5fc2fef5ec8cce17c89633a55a8 ]
    
    2 keymap fixes for the Acer Aspire One AOD270 and the same hardware
    rebranded as Packard Bell Dot SC:
    
    1. The F2 key is marked with a big '?' symbol on the Packard Bell Dot SC,
    this sends WMID_HOTKEY_EVENTs with a scancode of 0x27 add a mapping
    for this.
    
    2. Scancode 0x61 is KEY_SWITCHVIDEOMODE. Usually this is a duplicate
    input event with the "Video Bus" input device events. But on these devices
    the "Video Bus" does not send events for this key. Map 0x61 to KEY_UNKNOWN
    instead of using KE_IGNORE so that udev/hwdb can override it on these devs.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20220829163544.5288-1-hdegoede@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tg3: Disable tg3 device on system reboot to avoid triggering AER [+ + +]
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Fri Aug 26 08:25:30 2022 +0800

    tg3: Disable tg3 device on system reboot to avoid triggering AER
    
    [ Upstream commit 2ca1c94ce0b65a2ce7512b718f3d8a0fe6224bca ]
    
    Commit d60cd06331a3 ("PM: ACPI: reboot: Use S5 for reboot") caused a
    reboot hang on one Dell servers so the commit was reverted.
    
    Someone managed to collect the AER log and it's caused by MSI:
    [ 148.762067] ACPI: Preparing to enter system sleep state S5
    [ 148.794638] {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 5
    [ 148.803731] {1}[Hardware Error]: event severity: recoverable
    [ 148.810191] {1}[Hardware Error]: Error 0, type: fatal
    [ 148.816088] {1}[Hardware Error]: section_type: PCIe error
    [ 148.822391] {1}[Hardware Error]: port_type: 0, PCIe end point
    [ 148.829026] {1}[Hardware Error]: version: 3.0
    [ 148.834266] {1}[Hardware Error]: command: 0x0006, status: 0x0010
    [ 148.841140] {1}[Hardware Error]: device_id: 0000:04:00.0
    [ 148.847309] {1}[Hardware Error]: slot: 0
    [ 148.852077] {1}[Hardware Error]: secondary_bus: 0x00
    [ 148.857876] {1}[Hardware Error]: vendor_id: 0x14e4, device_id: 0x165f
    [ 148.865145] {1}[Hardware Error]: class_code: 020000
    [ 148.870845] {1}[Hardware Error]: aer_uncor_status: 0x00100000, aer_uncor_mask: 0x00010000
    [ 148.879842] {1}[Hardware Error]: aer_uncor_severity: 0x000ef030
    [ 148.886575] {1}[Hardware Error]: TLP Header: 40000001 0000030f 90028090 00000000
    [ 148.894823] tg3 0000:04:00.0: AER: aer_status: 0x00100000, aer_mask: 0x00010000
    [ 148.902795] tg3 0000:04:00.0: AER: [20] UnsupReq (First)
    [ 148.910234] tg3 0000:04:00.0: AER: aer_layer=Transaction Layer, aer_agent=Requester ID
    [ 148.918806] tg3 0000:04:00.0: AER: aer_uncor_severity: 0x000ef030
    [ 148.925558] tg3 0000:04:00.0: AER: TLP Header: 40000001 0000030f 90028090 00000000
    
    The MSI is probably raised by incoming packets, so power down the device
    and disable bus mastering to stop the traffic, as user confirmed this
    approach works.
    
    In addition to that, be extra safe and cancel reset task if it's running.
    
    Cc: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/all/b8db79e6857c41dab4ef08bdf826ea7c47e3bafc.1615947283.git.josef@toxicpanda.com/
    BugLink: https://bugs.launchpad.net/bugs/1917471
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20220826002530.1153296-1-kai.heng.feng@canonical.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tracefs: Only clobber mode/uid/gid on remount if asked [+ + +]
Author: Brian Norris <briannorris@chromium.org>
Date:   Fri Aug 26 17:44:17 2022 -0700

    tracefs: Only clobber mode/uid/gid on remount if asked
    
    commit 47311db8e8f33011d90dee76b39c8886120cdda4 upstream.
    
    Users may have explicitly configured their tracefs permissions; we
    shouldn't overwrite those just because a second mount appeared.
    
    Only clobber if the options were provided at mount time.
    
    Note: the previous behavior was especially surprising in the presence of
    automounted /sys/kernel/debug/tracing/.
    
    Existing behavior:
    
      ## Pre-existing status: tracefs is 0755.
      # stat -c '%A' /sys/kernel/tracing/
      drwxr-xr-x
    
      ## (Re)trigger the automount.
      # umount /sys/kernel/debug/tracing
      # stat -c '%A' /sys/kernel/debug/tracing/.
      drwx------
    
      ## Unexpected: the automount changed mode for other mount instances.
      # stat -c '%A' /sys/kernel/tracing/
      drwx------
    
    New behavior (after this change):
    
      ## Pre-existing status: tracefs is 0755.
      # stat -c '%A' /sys/kernel/tracing/
      drwxr-xr-x
    
      ## (Re)trigger the automount.
      # umount /sys/kernel/debug/tracing
      # stat -c '%A' /sys/kernel/debug/tracing/.
      drwxr-xr-x
    
      ## Expected: the automount does not change other mount instances.
      # stat -c '%A' /sys/kernel/tracing/
      drwxr-xr-x
    
    Link: https://lkml.kernel.org/r/20220826174353.2.Iab6e5ea57963d6deca5311b27fb7226790d44406@changeid
    
    Cc: stable@vger.kernel.org
    Fixes: 4282d60689d4f ("tracefs: Add new tracefs file system")
    Signed-off-by: Brian Norris <briannorris@chromium.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>