1. 29 10月, 2019 40 次提交
    • F
      mmc: cqhci: Commit descriptors before setting the doorbell · 01a44055
      Faiz Abbas 提交于
      commit c07d0073b9ec80a139d07ebf78e9c30d2a28279e upstream.
      
      Add a write memory barrier to make sure that descriptors are actually
      written to memory, before ringing the doorbell.
      Signed-off-by: NFaiz Abbas <faiz_abbas@ti.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      01a44055
    • D
      fs/proc/page.c: don't access uninitialized memmaps in fs/proc/page.c · 6ea856ef
      David Hildenbrand 提交于
      commit aad5f69bc161af489dbb5934868bd347282f0764 upstream.
      
      There are three places where we access uninitialized memmaps, namely:
      - /proc/kpagecount
      - /proc/kpageflags
      - /proc/kpagecgroup
      
      We have initialized memmaps either when the section is online or when the
      page was initialized to the ZONE_DEVICE.  Uninitialized memmaps contain
      garbage and in the worst case trigger kernel BUGs, especially with
      CONFIG_PAGE_POISONING.
      
      For example, not onlining a DIMM during boot and calling /proc/kpagecount
      with CONFIG_PAGE_POISONING:
      
        :/# cat /proc/kpagecount > tmp.test
        BUG: unable to handle page fault for address: fffffffffffffffe
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 114616067 P4D 114616067 PUD 114618067 PMD 0
        Oops: 0000 [#1] SMP NOPTI
        CPU: 0 PID: 469 Comm: cat Not tainted 5.4.0-rc1-next-20191004+ #11
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.4
        RIP: 0010:kpagecount_read+0xce/0x1e0
        Code: e8 09 83 e0 3f 48 0f a3 02 73 2d 4c 89 e7 48 c1 e7 06 48 03 3d ab 51 01 01 74 1d 48 8b 57 08 480
        RSP: 0018:ffffa14e409b7e78 EFLAGS: 00010202
        RAX: fffffffffffffffe RBX: 0000000000020000 RCX: 0000000000000000
        RDX: 0000000000000001 RSI: 00007f76b5595000 RDI: fffff35645000000
        RBP: 00007f76b5595000 R08: 0000000000000001 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000140000
        R13: 0000000000020000 R14: 00007f76b5595000 R15: ffffa14e409b7f08
        FS:  00007f76b577d580(0000) GS:ffff8f41bd400000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: fffffffffffffffe CR3: 0000000078960000 CR4: 00000000000006f0
        Call Trace:
         proc_reg_read+0x3c/0x60
         vfs_read+0xc5/0x180
         ksys_read+0x68/0xe0
         do_syscall_64+0x5c/0xa0
         entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      For now, let's drop support for ZONE_DEVICE from the three pseudo files
      in order to fix this.  To distinguish offline memory (with garbage
      memmap) from ZONE_DEVICE memory with properly initialized memmaps, we
      would have to check get_dev_pagemap() and pfn_zone_device_reserved()
      right now.  The usage of both (especially, special casing devmem) is
      frowned upon and needs to be reworked.
      
      The fundamental issue we have is:
      
      	if (pfn_to_online_page(pfn)) {
      		/* memmap initialized */
      	} else if (pfn_valid(pfn)) {
      		/*
      		 * ???
      		 * a) offline memory. memmap garbage.
      		 * b) devmem: memmap initialized to ZONE_DEVICE.
      		 * c) devmem: reserved for driver. memmap garbage.
      		 * (d) devmem: memmap currently initializing - garbage)
      		 */
      	}
      
      We'll leave the pfn_zone_device_reserved() check in stable_page_flags()
      in place as that function is also used from memory failure.  We now no
      longer dump information about pages that are not in use anymore -
      offline.
      
      Link: http://lkml.kernel.org/r/20191009142435.3975-2-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Reported-by: NQian Cai <cai@lca.pw>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Toshiki Fukasawa <t-fukasawa@vx.jp.nec.com>
      Cc: Pankaj gupta <pagupta@redhat.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Anthony Yznaga <anthony.yznaga@oracle.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
      Cc: <stable@vger.kernel.org>	[4.13+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ea856ef
    • D
      drivers/base/memory.c: don't access uninitialized memmaps in soft_offline_page_store() · 43a2a6c2
      David Hildenbrand 提交于
      commit 641fe2e9387a36f9ee01d7c69382d1fe147a5e98 upstream.
      
      Uninitialized memmaps contain garbage and in the worst case trigger kernel
      BUGs, especially with CONFIG_PAGE_POISONING.  They should not get touched.
      
      Right now, when trying to soft-offline a PFN that resides on a memory
      block that was never onlined, one gets a misleading error with
      CONFIG_PAGE_POISONING:
      
        :/# echo 5637144576 > /sys/devices/system/memory/soft_offline_page
        [   23.097167] soft offline: 0x150000 page already poisoned
      
      But the actual result depends on the garbage in the memmap.
      
      soft_offline_page() can only work with online pages, it returns -EIO in
      case of ZONE_DEVICE.  Make sure to only forward pages that are online
      (iow, managed by the buddy) and, therefore, have an initialized memmap.
      
      Add a check against pfn_to_online_page() and similarly return -EIO.
      
      Link: http://lkml.kernel.org/r/20191010141200.8985-1-david@redhat.com
      Fixes: f1dd2cd1 ("mm, memory_hotplug: do not associate hotadded memory to zones until online")	[visible after d0dc12e8]
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Acked-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rafael@kernel.org>
      Cc: <stable@vger.kernel.org>	[4.13+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43a2a6c2
    • H
      drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1 · 4d5307c0
      Hans de Goede 提交于
      commit 984d7a929ad68b7be9990fc9c5cfa5d5c9fc7942 upstream.
      
      Bail from the pci_driver probe function instead of from the drm_driver
      load function.
      
      This avoid /dev/dri/card0 temporarily getting registered and then
      unregistered again, sending unwanted add / remove udev events to
      userspace.
      
      Specifically this avoids triggering the (userspace) bug fixed by this
      plymouth merge-request:
      https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59
      
      Note that despite that being a userspace bug, not sending unnecessary
      udev events is a good idea in general.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d5307c0
    • T
      drm/ttm: Restore ttm prefaulting · 11377c3e
      Thomas Hellstrom 提交于
      commit 941f2f72dbbe0cf8c2d6e0b180a8021a0ec477fa upstream.
      
      Commit 4daa4fba ("gpu: drm: ttm: Adding new return type vm_fault_t")
      broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
      VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
      
      Restore (almost) the original behaviour. Unfortunately we can no longer
      with the new vm_fault_t return type determine whether a prefaulting
      PTE insertion hit an already populated PTE, and terminate the insertion
      loop. Instead we continue with the pre-determined number of prefaults.
      
      Fixes: 4daa4fba ("gpu: drm: ttm: Adding new return type vm_fault_t")
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Cc: Christian König <christian.koenig@amd.com>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org # v4.19+
      Signed-off-by: NChristian König <christian.koenig@amd.com>
      Link: https://patchwork.freedesktop.org/patch/330387/Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      11377c3e
    • K
      drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50 · 33af2a8e
      Kai-Heng Feng 提交于
      commit 11bcf5f78905b90baae8fb01e16650664ed0cb00 upstream.
      
      Another panel that needs 6BPC quirk.
      
      BugLink: https://bugs.launchpad.net/bugs/1819968
      Cc: <stable@vger.kernel.org> # v4.8+
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190402033037.21877-1-kai.heng.feng@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33af2a8e
    • W
      mac80211: Reject malformed SSID elements · 24ca6289
      Will Deacon 提交于
      commit 4152561f5da3fca92af7179dd538ea89e248f9d0 upstream.
      
      Although this shouldn't occur in practice, it's a good idea to bounds
      check the length field of the SSID element prior to using it for things
      like allocations or memcpy operations.
      
      Cc: <stable@vger.kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Reported-by: NNicolas Waisman <nico@semmle.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20191004095132.15777-1-will@kernel.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24ca6289
    • W
      cfg80211: wext: avoid copying malformed SSIDs · 73c066a9
      Will Deacon 提交于
      commit 4ac2813cc867ae563a1ba5a9414bfb554e5796fa upstream.
      
      Ensure the SSID element is bounds-checked prior to invoking memcpy()
      with its length field, when copying to userspace.
      
      Cc: <stable@vger.kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Reported-by: NNicolas Waisman <nico@semmle.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Link: https://lore.kernel.org/r/20191004095132.15777-2-will@kernel.org
      [adjust commit log a bit]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73c066a9
    • J
      ACPI: CPPC: Set pcc_data[pcc_ss_id] to NULL in acpi_cppc_processor_exit() · 83dc1670
      John Garry 提交于
      commit 56a0b978d42f58c7e3ba715cf65af487d427524d upstream.
      
      When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN
      warning:
      
      [   20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8
      [   20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1
      [   20.884826]
      [   20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289
      [   20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
      [   20.903505] Call trace:
      [   20.905942]  dump_backtrace+0x0/0x200
      [   20.909593]  show_stack+0x14/0x20
      [   20.912899]  dump_stack+0xd4/0x130
      [   20.916291]  print_address_description.isra.9+0x6c/0x3b8
      [   20.921592]  __kasan_report+0x12c/0x23c
      [   20.925417]  kasan_report+0xc/0x18
      [   20.928808]  __asan_load4+0x94/0xb8
      [   20.932286]  pcc_data_alloc+0x40/0xb8
      [   20.935938]  acpi_cppc_processor_probe+0x4e8/0xb08
      [   20.940717]  __acpi_processor_start+0x48/0xb0
      [   20.945062]  acpi_processor_start+0x40/0x60
      [   20.949235]  really_probe+0x118/0x548
      [   20.952887]  driver_probe_device+0x7c/0x148
      [   20.957059]  device_driver_attach+0x94/0xa0
      [   20.961231]  __driver_attach+0xa4/0x110
      [   20.965055]  bus_for_each_dev+0xe8/0x158
      [   20.968966]  driver_attach+0x30/0x40
      [   20.972531]  bus_add_driver+0x234/0x2f0
      [   20.976356]  driver_register+0xbc/0x1d0
      [   20.980182]  acpi_processor_driver_init+0x40/0xe4
      [   20.984875]  do_one_initcall+0xb4/0x254
      [   20.988700]  kernel_init_freeable+0x24c/0x2f8
      [   20.993047]  kernel_init+0x10/0x118
      [   20.996524]  ret_from_fork+0x10/0x18
      [   21.000087]
      [   21.001567] Allocated by task 1:
      [   21.004785]  save_stack+0x28/0xc8
      [   21.008089]  __kasan_kmalloc.isra.9+0xbc/0xd8
      [   21.012435]  kasan_kmalloc+0xc/0x18
      [   21.015913]  pcc_data_alloc+0x94/0xb8
      [   21.019564]  acpi_cppc_processor_probe+0x4e8/0xb08
      [   21.024343]  __acpi_processor_start+0x48/0xb0
      [   21.028689]  acpi_processor_start+0x40/0x60
      [   21.032860]  really_probe+0x118/0x548
      [   21.036512]  driver_probe_device+0x7c/0x148
      [   21.040684]  device_driver_attach+0x94/0xa0
      [   21.044855]  __driver_attach+0xa4/0x110
      [   21.048680]  bus_for_each_dev+0xe8/0x158
      [   21.052591]  driver_attach+0x30/0x40
      [   21.056155]  bus_add_driver+0x234/0x2f0
      [   21.059980]  driver_register+0xbc/0x1d0
      [   21.063805]  acpi_processor_driver_init+0x40/0xe4
      [   21.068497]  do_one_initcall+0xb4/0x254
      [   21.072322]  kernel_init_freeable+0x24c/0x2f8
      [   21.076667]  kernel_init+0x10/0x118
      [   21.080144]  ret_from_fork+0x10/0x18
      [   21.083707]
      [   21.085186] Freed by task 1:
      [   21.088056]  save_stack+0x28/0xc8
      [   21.091360]  __kasan_slab_free+0x118/0x180
      [   21.095445]  kasan_slab_free+0x10/0x18
      [   21.099183]  kfree+0x80/0x268
      [   21.102139]  acpi_cppc_processor_exit+0x1a8/0x1b8
      [   21.106832]  acpi_processor_stop+0x70/0x80
      [   21.110917]  really_probe+0x174/0x548
      [   21.114568]  driver_probe_device+0x7c/0x148
      [   21.118740]  device_driver_attach+0x94/0xa0
      [   21.122912]  __driver_attach+0xa4/0x110
      [   21.126736]  bus_for_each_dev+0xe8/0x158
      [   21.130648]  driver_attach+0x30/0x40
      [   21.134212]  bus_add_driver+0x234/0x2f0
      [   21.0x10/0x18
      [   21.161764]
      [   21.163244] The buggy address belongs to the object at ffff00236cdeb600
      [   21.163244]  which belongs to the cache kmalloc-256 of size 256
      [   21.175750] The buggy address is located 132 bytes inside of
      [   21.175750]  256-byte region [ffff00236cdeb600, ffff00236cdeb700)
      [   21.187473] The buggy address belongs to the page:
      [   21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0
      [   21.202331] flags: 0x1ffff00000010200(slab|head)
      [   21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00
      [   21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
      [   21.222400] page dumped because: kasan: bad access detected
      [   21.227959]
      [   21.229438] Memory state around the buggy address:
      [   21.234218]  ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   21.241427]  ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.255845]                    ^
      [   21.259062]  ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      [   21.266272]  ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [   21.273480] ==================================================================
      
      It seems that global pcc_data[pcc_ss_id] can be freed in
      acpi_cppc_processor_exit(), but we may later reference this value, so
      NULLify it when freed.
      
      Also remove the useless setting of data "pcc_channel_acquired", which
      we're about to free.
      
      Fixes: 85b1407b ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs")
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      83dc1670
    • J
      ASoC: rsnd: Reinitialize bit clock inversion flag for every format setting · 8e367b02
      Junya Monden 提交于
      commit 22e58665a01006d05f0239621f7d41cacca96cc4 upstream.
      
      Unlike other format-related DAI parameters, rdai->bit_clk_inv flag
      is not properly re-initialized when setting format for new stream
      processing. The inversion, if requested, is then applied not to default,
      but to a previous value, which leads to SCKP bit in SSICR register being
      set incorrectly.
      Fix this by re-setting the flag to its initial value, determined by format.
      
      Fixes: 1a7889ca ("ASoC: rsnd: fixup SND_SOC_DAIFMT_xB_xF behavior")
      Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com>
      Cc: Jiada Wang <jiada_wang@mentor.com>
      Cc: Timo Wischer <twischer@de.adit-jv.com>
      Cc: stable@vger.kernel.org # v3.17+
      Signed-off-by: NJunya Monden <jmonden@jp.adit-jv.com>
      Signed-off-by: NEugeniu Rosca <erosca@de.adit-jv.com>
      Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/20191016124255.7442-1-erosca@de.adit-jv.comSigned-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e367b02
    • E
      Input: synaptics-rmi4 - avoid processing unknown IRQs · b0dd6a24
      Evan Green 提交于
      commit 363c53875aef8fce69d4a2d0873919ccc7d9e2ad upstream.
      
      rmi_process_interrupt_requests() calls handle_nested_irq() for
      each interrupt status bit it finds. If the irq domain mapping for
      this bit had not yet been set up, then it ends up calling
      handle_nested_irq(0), which causes a NULL pointer dereference.
      
      There's already code that masks the irq_status bits coming out of the
      hardware with current_irq_mask, presumably to avoid this situation.
      However current_irq_mask seems to more reflect the actual mask set
      in the hardware rather than the IRQs software has set up and registered
      for. For example, in rmi_driver_reset_handler(), the current_irq_mask
      is initialized based on what is read from the hardware. If the reset
      value of this mask enables IRQs that Linux has not set up yet, then
      we end up in this situation.
      
      There appears to be a third unused bitmask that used to serve this
      purpose, fn_irq_bits. Use that bitmask instead of current_irq_mask
      to avoid calling handle_nested_irq() on IRQs that have not yet been
      set up.
      Signed-off-by: NEvan Green <evgreen@chromium.org>
      Reviewed-by: NAndrew Duggan <aduggan@synaptics.com>
      Link: https://lore.kernel.org/r/20191008223657.163366-1-evgreen@chromium.org
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0dd6a24
    • M
      Input: da9063 - fix capability and drop KEY_SLEEP · aa9402c1
      Marco Felsch 提交于
      commit afce285b859cea91c182015fc9858ea58c26cd0e upstream.
      
      Since commit f889beaa ("Input: da9063 - report KEY_POWER instead of
      KEY_SLEEP during power key-press") KEY_SLEEP isn't supported anymore. This
      caused input device to not generate any events if "dlg,disable-key-power"
      is set.
      
      Fix this by unconditionally setting KEY_POWER capability, and not
      declaring KEY_SLEEP.
      
      Fixes: f889beaa ("Input: da9063 - report KEY_POWER instead of KEY_SLEEP during power key-press")
      Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa9402c1
    • B
      scsi: ch: Make it possible to open a ch device multiple times again · e254d435
      Bart Van Assche 提交于
      commit 6a0990eaa768dfb7064f06777743acc6d392084b upstream.
      
      Clearing ch->device in ch_release() is wrong because that pointer must
      remain valid until ch_remove() is called. This patch fixes the following
      crash the second time a ch device is opened:
      
      BUG: kernel NULL pointer dereference, address: 0000000000000790
      RIP: 0010:scsi_device_get+0x5/0x60
      Call Trace:
       ch_open+0x4c/0xa0 [ch]
       chrdev_open+0xa2/0x1c0
       do_dentry_open+0x13a/0x380
       path_openat+0x591/0x1470
       do_filp_open+0x91/0x100
       do_sys_open+0x184/0x220
       do_syscall_64+0x5f/0x1a0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 085e5676 ("scsi: ch: add refcounting")
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191009173536.247889-1-bvanassche@acm.orgReported-by: NRob Turk <robtu@rtist.nl>
      Suggested-by: NRob Turk <robtu@rtist.nl>
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e254d435
    • Y
      scsi: core: try to get module before removing device · 0c690519
      Yufen Yu 提交于
      commit 77c301287ebae86cc71d03eb3806f271cb14da79 upstream.
      
      We have a test case like block/001 in blktests, which will create a scsi
      device by loading scsi_debug module and then try to delete the device by
      sysfs interface. At the same time, it may remove the scsi_debug module.
      
      And getting a invalid paging request BUG_ON as following:
      
      [   34.625854] BUG: unable to handle page fault for address: ffffffffa0016bb8
      [   34.629189] Oops: 0000 [#1] SMP PTI
      [   34.629618] CPU: 1 PID: 450 Comm: bash Tainted: G        W         5.4.0-rc3+ #473
      [   34.632524] RIP: 0010:scsi_proc_hostdir_rm+0x5/0xa0
      [   34.643555] CR2: ffffffffa0016bb8 CR3: 000000012cd88000 CR4: 00000000000006e0
      [   34.644545] Call Trace:
      [   34.644907]  scsi_host_dev_release+0x6b/0x1f0
      [   34.645511]  device_release+0x74/0x110
      [   34.646046]  kobject_put+0x116/0x390
      [   34.646559]  put_device+0x17/0x30
      [   34.647041]  scsi_target_dev_release+0x2b/0x40
      [   34.647652]  device_release+0x74/0x110
      [   34.648186]  kobject_put+0x116/0x390
      [   34.648691]  put_device+0x17/0x30
      [   34.649157]  scsi_device_dev_release_usercontext+0x2e8/0x360
      [   34.649953]  execute_in_process_context+0x29/0x80
      [   34.650603]  scsi_device_dev_release+0x20/0x30
      [   34.651221]  device_release+0x74/0x110
      [   34.651732]  kobject_put+0x116/0x390
      [   34.652230]  sysfs_unbreak_active_protection+0x3f/0x50
      [   34.652935]  sdev_store_delete.cold.4+0x71/0x8f
      [   34.653579]  dev_attr_store+0x1b/0x40
      [   34.654103]  sysfs_kf_write+0x3d/0x60
      [   34.654603]  kernfs_fop_write+0x174/0x250
      [   34.655165]  __vfs_write+0x1f/0x60
      [   34.655639]  vfs_write+0xc7/0x280
      [   34.656117]  ksys_write+0x6d/0x140
      [   34.656591]  __x64_sys_write+0x1e/0x30
      [   34.657114]  do_syscall_64+0xb1/0x400
      [   34.657627]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   34.658335] RIP: 0033:0x7f156f337130
      
      During deleting scsi target, the scsi_debug module have been removed. Then,
      sdebug_driver_template belonged to the module cannot be accessd, resulting
      in scsi_proc_hostdir_rm() BUG_ON.
      
      To fix the bug, we add scsi_device_get() in sdev_store_delete() to try to
      increase refcount of module, avoiding the module been removed.
      
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191015130556.18061-1-yuyufen@huawei.comSigned-off-by: NYufen Yu <yuyufen@huawei.com>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c690519
    • D
      scsi: core: save/restore command resid for error handling · 2a675e73
      Damien Le Moal 提交于
      commit 8f8fed0cdbbd6cdbf28d9ebe662f45765d2f7d39 upstream.
      
      When a non-passthrough command is terminated with CHECK CONDITION, request
      sense is executed by hijacking the command descriptor. Since
      scsi_eh_prep_cmnd() and scsi_eh_restore_cmnd() do not save/restore the
      original command resid, the value returned on failure of the original
      command is lost and replaced with the value set by the execution of the
      request sense command. This value may in many instances be unaligned to the
      device sector size, causing sd_done() to print a warning message about the
      incorrect unaligned resid before the command is retried.
      
      Fix this problem by saving the original command residual in struct
      scsi_eh_save using scsi_eh_prep_cmnd() and restoring it in
      scsi_eh_restore_cmnd(). In addition, to make sure that the request sense
      command is executed with a correctly initialized command structure, also
      reset the residual to 0 in scsi_eh_prep_cmnd() after saving the original
      command value in struct scsi_eh_save.
      
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191001074839.1994-1-damien.lemoal@wdc.comSigned-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a675e73
    • O
      scsi: sd: Ignore a failure to sync cache due to lack of authorization · 0cea86f2
      Oliver Neukum 提交于
      commit 21e3d6c81179bbdfa279efc8de456c34b814cfd2 upstream.
      
      I've got a report about a UAS drive enclosure reporting back Sense: Logical
      unit access not authorized if the drive it holds is password protected.
      While the drive is obviously unusable in that state as a mass storage
      device, it still exists as a sd device and when the system is asked to
      perform a suspend of the drive, it will be sent a SYNCHRONIZE CACHE. If
      that fails due to password protection, the error must be ignored.
      
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20190903101840.16483-1-oneukum@suse.comSigned-off-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0cea86f2
    • S
      scsi: zfcp: fix reaction on bit error threshold notification · 3638ccda
      Steffen Maier 提交于
      commit 2190168aaea42c31bff7b9a967e7b045f07df095 upstream.
      
      On excessive bit errors for the FCP channel ingress fibre path, the channel
      notifies us.  Previously, we only emitted a kernel message and a trace
      record.  Since performance can become suboptimal with I/O timeouts due to
      bit errors, we now stop using an FCP device by default on channel
      notification so multipath on top can timely failover to other paths.  A new
      module parameter zfcp.ber_stop can be used to get zfcp old behavior.
      
      User explanation of new kernel message:
      
       * Description:
       * The FCP channel reported that its bit error threshold has been exceeded.
       * These errors might result from a problem with the physical components
       * of the local fibre link into the FCP channel.
       * The problem might be damage or malfunction of the cable or
       * cable connection between the FCP channel and
       * the adjacent fabric switch port or the point-to-point peer.
       * Find details about the errors in the HBA trace for the FCP device.
       * The zfcp device driver closed down the FCP device
       * to limit the performance impact from possible I/O command timeouts.
       * User action:
       * Check for problems on the local fibre link, ensure that fibre optics are
       * clean and functional, and all cables are properly plugged.
       * After the repair action, you can manually recover the FCP device by
       * writing "0" into its "failed" sysfs attribute.
       * If recovery through sysfs is not possible, set the CHPID of the device
       * offline and back online on the service element.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: <stable@vger.kernel.org> #2.6.30+
      Link: https://lore.kernel.org/r/20191001104949.42810-1-maier@linux.ibm.comReviewed-by: NJens Remus <jremus@linux.ibm.com>
      Reviewed-by: NBenjamin Block <bblock@linux.ibm.com>
      Signed-off-by: NSteffen Maier <maier@linux.ibm.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3638ccda
    • C
      staging: wlan-ng: fix exit return when sme->key_idx >= NUM_WEPKEYS · d07c028d
      Colin Ian King 提交于
      commit 153c5d8191c26165dbbd2646448ca7207f7796d0 upstream.
      
      Currently the exit return path when sme->key_idx >= NUM_WEPKEYS is via
      label 'exit' and this checks if result is non-zero, however result has
      not been initialized and contains garbage.  Fix this by replacing the
      goto with a return with the error code.
      
      Addresses-Coverity: ("Uninitialized scalar variable")
      Fixes: 0ca6d8e7 ("Staging: wlan-ng: replace switch-case statements with macro")
      Signed-off-by: NColin Ian King <colin.king@canonical.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191014110201.9874-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d07c028d
    • P
      MIPS: tlbex: Fix build_restore_pagemask KScratch restore · 4034a503
      Paul Burton 提交于
      commit b42aa3fd5957e4daf4b69129e5ce752a2a53e7d6 upstream.
      
      build_restore_pagemask() will restore the value of register $1/$at when
      its restore_scratch argument is non-zero, and aims to do so by filling a
      branch delay slot. Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0
      -> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier)
      prior to restoring $1 from a KScratch register, in order to resolve a
      hazard that can result in stale values of the KScratch register being
      observed. In particular, P-class CPUs from MIPS with out of order
      execution pipelines such as the P5600 & P6600 are affected.
      
      Unfortunately this EHB instruction was inserted in the branch delay slot
      causing the MFC0 instruction which performs the restoration to no longer
      execute along with the branch. The result is that the $1 register isn't
      actually restored, ie. the TLB refill exception handler clobbers it -
      which is exactly the problem the EHB is meant to avoid for the P-class
      CPUs.
      
      Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when
      its mode argument equals refill_scratch, and suffers from the same
      problem.
      
      Fix this by in both cases moving the EHB earlier in the emitted code.
      There's no reason it needs to immediately precede the MFC0 - it simply
      needs to be between the MTC0 & MFC0.
      
      This bug only affects Cavium Octeon systems which use
      build_fast_tlb_refill_handler().
      Signed-off-by: NPaul Burton <paulburton@kernel.org>
      Fixes: 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
      Cc: Dmitry Korotin <dkorotin@wavecomp.com>
      Cc: stable@vger.kernel.org # v3.15+
      Cc: linux-mips@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4034a503
    • J
      USB: ldusb: fix read info leaks · 9f7e1574
      Johan Hovold 提交于
      commit 7a6f22d7479b7a0b68eadd308a997dd64dda7dae upstream.
      
      Fix broken read implementation, which could be used to trigger slab info
      leaks.
      
      The driver failed to check if the custom ring buffer was still empty
      when waking up after having waited for more data. This would happen on
      every interrupt-in completion, even if no data had been added to the
      ring buffer (e.g. on disconnect events).
      
      Due to missing sanity checks and uninitialised (kmalloced) ring-buffer
      entries, this meant that huge slab info leaks could easily be triggered.
      
      Note that the empty-buffer check after wakeup is enough to fix the info
      leak on disconnect, but let's clear the buffer on allocation and add a
      sanity check to read() to prevent further leaks.
      
      Fixes: 2824bd25 ("[PATCH] USB: add ldusb driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.13
      Reported-by: syzbot+6fe95b826644f7f12b0b@syzkaller.appspotmail.com
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191018151955.25135-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f7e1574
    • J
      USB: usblp: fix use-after-free on disconnect · 3b73a0e4
      Johan Hovold 提交于
      commit 7a759197974894213621aa65f0571b51904733d6 upstream.
      
      A recent commit addressing a runtime PM use-count regression, introduced
      a use-after-free by not making sure we held a reference to the struct
      usb_interface for the lifetime of the driver data.
      
      Fixes: 9a31535859bf ("USB: usblp: fix runtime PM after driver unbind")
      Cc: stable <stable@vger.kernel.org>
      Reported-by: syzbot+cd24df4d075c319ebfc5@syzkaller.appspotmail.com
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191015175522.18490-1-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b73a0e4
    • J
      USB: ldusb: fix memleak on disconnect · 28ab2c5f
      Johan Hovold 提交于
      commit b14a39048c1156cfee76228bf449852da2f14df8 upstream.
      
      If disconnect() races with release() after a process has been
      interrupted, release() could end up returning early and the driver would
      fail to free its driver data.
      
      Fixes: 2824bd25 ("[PATCH] USB: add ldusb driver")
      Cc: stable <stable@vger.kernel.org>     # 2.6.13
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191010125835.27031-2-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      28ab2c5f
    • J
      USB: serial: ti_usb_3410_5052: fix port-close races · edd3e9c7
      Johan Hovold 提交于
      commit 6f1d1dc8d540a9aa6e39b9cb86d3a67bbc1c8d8d upstream.
      
      Fix races between closing a port and opening or closing another port on
      the same device which could lead to a failure to start or stop the
      shared interrupt URB. The latter could potentially cause a
      use-after-free or worse in the completion handler on driver unbind.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edd3e9c7
    • G
      usb: udc: lpc32xx: fix bad bit shift operation · 068fcbe8
      Gustavo A. R. Silva 提交于
      commit b987b66ac3a2bc2f7b03a0ba48a07dc553100c07 upstream.
      
      It seems that the right variable to use in this case is *i*, instead of
      *n*, otherwise there is an undefined behavior when right shifiting by more
      than 31 bits when multiplying n by 8; notice that *n* can take values
      equal or greater than 4 (4, 8, 16, ...).
      
      Also, notice that under the current conditions (bl = 3), we are skiping
      the handling of bytes 3, 7, 31... So, fix this by updating this logic
      and limit *bl* up to 4 instead of up to 3.
      
      This fix is based on function udc_stuff_fifo().
      
      Addresses-Coverity-ID: 1454834 ("Bad bit shift operation")
      Fixes: 24a28e42 ("USB: gadget driver for LPC32xx")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Link: https://lore.kernel.org/r/20191014191830.GA10721@embeddedorSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      068fcbe8
    • L
      ALSA: hda - Force runtime PM on Nvidia HDMI codecs · 7ed43d2e
      Lukas Wunner 提交于
      commit 94989e318b2f11e217e86bee058088064fa9a2e9 upstream.
      
      Przemysław Kopa reports that since commit b516ea586d71 ("PCI: Enable
      NVIDIA HDA controllers"), the discrete GPU Nvidia GeForce GT 540M on his
      2011 Samsung laptop refuses to runtime suspend, resulting in a power
      regression and excessive heat.
      
      Rivera Valdez witnesses the same issue with a GeForce GT 525M (GF108M)
      of the same era, as does another Arch Linux user named "R0AR" with a
      more recent GeForce GTX 1050 Ti (GP107M).
      
      The commit exposes the discrete GPU's HDA controller and all four codecs
      on the controller do not set the CLKSTOP and EPSS bits in the Supported
      Power States Response.  They also do not set the PS-ClkStopOk bit in the
      Get Power State Response.  hda_codec_runtime_suspend() therefore does
      not call snd_hdac_codec_link_down(), which prevents each codec and the
      PCI device from runtime suspending.
      
      The same issue is present on some AMD discrete GPUs and we addressed it
      by forcing runtime PM despite the bits not being set, see commit
      57cb54e5 ("ALSA: hda - Force to link down at runtime suspend on
      ATI/AMD HDMI").
      
      Do the same for Nvidia HDMI codecs.
      
      Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers")
      Link: https://bbs.archlinux.org/viewtopic.php?pid=1865512
      Link: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c81Reported-by: NPrzemysław Kopa <prymoo@gmail.com>
      Reported-by: NRivera Valdez <riveravaldez@ysinembargo.com>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Cc: Daniel Drake <dan@reactivated.net>
      Cc: stable@vger.kernel.org # v5.3+
      Link: https://lore.kernel.org/r/3086bc75135c1e3567c5bc4f3cc4ff5cbf7a56c2.1571324194.git.lukas@wunner.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ed43d2e
    • S
      ALSA: usb-audio: Disable quirks for BOSS Katana amplifiers · 7dda7481
      Szabolcs Szőke 提交于
      commit 7571b6a17fcc5e4f6903f065a82d0e38011346ed upstream.
      
      BOSS Katana amplifiers cannot be used for recording or playback if quirks
      are applied
      
      BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223Signed-off-by: NSzabolcs Szőke <szszoke.code@gmail.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191011171937.8013-1-szszoke.code@gmail.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7dda7481
    • D
      ALSA: hda/realtek - Enable headset mic on Asus MJ401TA · 6c8a9a46
      Daniel Drake 提交于
      commit 8c8967a7dc01a25f57a0757fdca10987773cd1f2 upstream.
      
      On Asus MJ401TA (with Realtek ALC256), the headset mic is connected to
      pin 0x19, with default configuration value 0x411111f0 (indicating no
      physical connection).
      
      Enable this by quirking the pin. Mic jack detection was also tested and
      found to be working.
      
      This enables use of the headset mic on this product.
      Signed-off-by: NDaniel Drake <drake@endlessm.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191017081501.17135-1-drake@endlessm.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c8a9a46
    • K
      ALSA: hda/realtek - Add support for ALC711 · 30a83eb0
      Kailang Yang 提交于
      commit 83629532ce45ef9df1f297b419b9ea112045685d upstream.
      
      Support new codec ALC711.
      Signed-off-by: NKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      30a83eb0
    • J
      USB: legousbtower: fix memleak on disconnect · 5366778b
      Johan Hovold 提交于
      commit b6c03e5f7b463efcafd1ce141bd5a8fc4e583ae2 upstream.
      
      If disconnect() races with release() after a process has been
      interrupted, release() could end up returning early and the driver would
      fail to free its driver data.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Link: https://lore.kernel.org/r/20191010125835.27031-3-johan@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5366778b
    • M
      memfd: Fix locking when tagging pins · 99b45e7a
      Matthew Wilcox (Oracle) 提交于
      The RCU lock is insufficient to protect the radix tree iteration as
      a deletion from the tree can occur before we take the spinlock to
      tag the entry.  In 4.19, this has manifested as a bug with the following
      trace:
      
      kernel BUG at lib/radix-tree.c:1429!
      invalid opcode: 0000 [#1] SMP KASAN PTI
      CPU: 7 PID: 6935 Comm: syz-executor.2 Not tainted 4.19.36 #25
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      RIP: 0010:radix_tree_tag_set+0x200/0x2f0 lib/radix-tree.c:1429
      Code: 00 00 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 89 44 24 10 e8 a3 29 7e fe 48 8b 44 24 10 48 0f ab 03 e9 d2 fe ff ff e8 90 29 7e fe <0f> 0b 48 c7 c7 e0 5a 87 84 e8 f0 e7 08 ff 4c 89 ef e8 4a ff ac fe
      RSP: 0018:ffff88837b13fb60 EFLAGS: 00010016
      RAX: 0000000000040000 RBX: ffff8883c5515d58 RCX: ffffffff82cb2ef0
      RDX: 0000000000000b72 RSI: ffffc90004cf2000 RDI: ffff8883c5515d98
      RBP: ffff88837b13fb98 R08: ffffed106f627f7e R09: ffffed106f627f7e
      R10: 0000000000000001 R11: ffffed106f627f7d R12: 0000000000000004
      R13: ffffea000d7fea80 R14: 1ffff1106f627f6f R15: 0000000000000002
      FS:  00007fa1b8df2700(0000) GS:ffff8883e2fc0000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fa1b8df1db8 CR3: 000000037d4d2001 CR4: 0000000000160ee0
      Call Trace:
       memfd_tag_pins mm/memfd.c:51 [inline]
       memfd_wait_for_pins+0x2c5/0x12d0 mm/memfd.c:81
       memfd_add_seals mm/memfd.c:215 [inline]
       memfd_fcntl+0x33d/0x4a0 mm/memfd.c:247
       do_fcntl+0x589/0xeb0 fs/fcntl.c:421
       __do_sys_fcntl fs/fcntl.c:463 [inline]
       __se_sys_fcntl fs/fcntl.c:448 [inline]
       __x64_sys_fcntl+0x12d/0x180 fs/fcntl.c:448
       do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:293
      
      The problem does not occur in mainline due to the XArray rewrite which
      changed the locking to exclude modification of the tree during iteration.
      At the time, nobody realised this was a bugfix.  Backport the locking
      changes to stable.
      
      Cc: stable@vger.kernel.org
      Reported-by: Nzhong jiang <zhongjiang@huawei.com>
      Signed-off-by: NMatthew Wilcox (Oracle) <willy@infradead.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      99b45e7a
    • X
      sctp: change sctp_prot .no_autobind with true · 2770f80a
      Xin Long 提交于
      [ Upstream commit 63dfb7938b13fa2c2fbcb45f34d065769eb09414 ]
      
      syzbot reported a memory leak:
      
        BUG: memory leak, unreferenced object 0xffff888120b3d380 (size 64):
        backtrace:
      
          [...] slab_alloc mm/slab.c:3319 [inline]
          [...] kmem_cache_alloc+0x13f/0x2c0 mm/slab.c:3483
          [...] sctp_bucket_create net/sctp/socket.c:8523 [inline]
          [...] sctp_get_port_local+0x189/0x5a0 net/sctp/socket.c:8270
          [...] sctp_do_bind+0xcc/0x200 net/sctp/socket.c:402
          [...] sctp_bindx_add+0x4b/0xd0 net/sctp/socket.c:497
          [...] sctp_setsockopt_bindx+0x156/0x1b0 net/sctp/socket.c:1022
          [...] sctp_setsockopt net/sctp/socket.c:4641 [inline]
          [...] sctp_setsockopt+0xaea/0x2dc0 net/sctp/socket.c:4611
          [...] sock_common_setsockopt+0x38/0x50 net/core/sock.c:3147
          [...] __sys_setsockopt+0x10f/0x220 net/socket.c:2084
          [...] __do_sys_setsockopt net/socket.c:2100 [inline]
      
      It was caused by when sending msgs without binding a port, in the path:
      inet_sendmsg() -> inet_send_prepare() -> inet_autobind() ->
      .get_port/sctp_get_port(), sp->bind_hash will be set while bp->port is
      not. Later when binding another port by sctp_setsockopt_bindx(), a new
      bucket will be created as bp->port is not set.
      
      sctp's autobind is supposed to call sctp_autobind() where it does all
      things including setting bp->port. Since sctp_autobind() is called in
      sctp_sendmsg() if the sk is not yet bound, it should have skipped the
      auto bind.
      
      THis patch is to avoid calling inet_autobind() in inet_send_prepare()
      by changing sctp_prot .no_autobind with true, also remove the unused
      .get_port.
      
      Reported-by: syzbot+d44f7bbebdea49dbc84a@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2770f80a
    • B
      net: stmmac: disable/enable ptp_ref_clk in suspend/resume flow · cd8c21ca
      Biao Huang 提交于
      [ Upstream commit e497c20e203680aba9ccf7bb475959595908ca7e ]
      
      disable ptp_ref_clk in suspend flow, and enable it in resume flow.
      
      Fixes: f573c0b9 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure")
      Signed-off-by: NBiao Huang <biao.huang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cd8c21ca
    • X
      net: ipv6: fix listify ip6_rcv_finish in case of forwarding · da4f0aed
      Xin Long 提交于
      [ Upstream commit c7a42eb49212f93a800560662d17d5293960d3c3 ]
      
      We need a similar fix for ipv6 as Commit 0761680d ("net: ipv4: fix
      listify ip_rcv_finish in case of forwarding") does for ipv4.
      
      This issue can be reprocuded by syzbot since Commit 323ebb61e32b ("net:
      use listified RX for handling GRO_NORMAL skbs") on net-next. The call
      trace was:
      
        kernel BUG at include/linux/skbuff.h:2225!
        RIP: 0010:__skb_pull include/linux/skbuff.h:2225 [inline]
        RIP: 0010:skb_pull+0xea/0x110 net/core/skbuff.c:1902
        Call Trace:
          sctp_inq_pop+0x2f1/0xd80 net/sctp/inqueue.c:202
          sctp_endpoint_bh_rcv+0x184/0x8d0 net/sctp/endpointola.c:385
          sctp_inq_push+0x1e4/0x280 net/sctp/inqueue.c:80
          sctp_rcv+0x2807/0x3590 net/sctp/input.c:256
          sctp6_rcv+0x17/0x30 net/sctp/ipv6.c:1049
          ip6_protocol_deliver_rcu+0x2fe/0x1660 net/ipv6/ip6_input.c:397
          ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:438
          NF_HOOK include/linux/netfilter.h:305 [inline]
          NF_HOOK include/linux/netfilter.h:299 [inline]
          ip6_input+0xe4/0x3f0 net/ipv6/ip6_input.c:447
          dst_input include/net/dst.h:442 [inline]
          ip6_sublist_rcv_finish+0x98/0x1e0 net/ipv6/ip6_input.c:84
          ip6_list_rcv_finish net/ipv6/ip6_input.c:118 [inline]
          ip6_sublist_rcv+0x80c/0xcf0 net/ipv6/ip6_input.c:282
          ipv6_list_rcv+0x373/0x4b0 net/ipv6/ip6_input.c:316
          __netif_receive_skb_list_ptype net/core/dev.c:5049 [inline]
          __netif_receive_skb_list_core+0x5fc/0x9d0 net/core/dev.c:5097
          __netif_receive_skb_list net/core/dev.c:5149 [inline]
          netif_receive_skb_list_internal+0x7eb/0xe60 net/core/dev.c:5244
          gro_normal_list.part.0+0x1e/0xb0 net/core/dev.c:5757
          gro_normal_list net/core/dev.c:5755 [inline]
          gro_normal_one net/core/dev.c:5769 [inline]
          napi_frags_finish net/core/dev.c:5782 [inline]
          napi_gro_frags+0xa6a/0xea0 net/core/dev.c:5855
          tun_get_user+0x2e98/0x3fa0 drivers/net/tun.c:1974
          tun_chr_write_iter+0xbd/0x156 drivers/net/tun.c:2020
      
      Fixes: d8269e2c ("net: ipv6: listify ipv6_rcv() and ip6_rcv_finish()")
      Fixes: 323ebb61e32b ("net: use listified RX for handling GRO_NORMAL skbs")
      Reported-by: syzbot+eb349eeee854e389c36d@syzkaller.appspotmail.com
      Reported-by: syzbot+4a0643a653ac375612d1@syzkaller.appspotmail.com
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da4f0aed
    • C
      net/ibmvnic: Fix EOI when running in XIVE mode. · cc2d858b
      Cédric Le Goater 提交于
      [ Upstream commit 11d49ce9f7946dfed4dcf5dbde865c78058b50ab ]
      
      pSeries machines on POWER9 processors can run with the XICS (legacy)
      interrupt mode or with the XIVE exploitation interrupt mode. These
      interrupt contollers have different interfaces for interrupt
      management : XICS uses hcalls and XIVE loads and stores on a page.
      H_EOI being a XICS interface the enable_scrq_irq() routine can fail
      when the machine runs in XIVE mode.
      
      Fix that by calling the EOI handler of the interrupt chip.
      
      Fixes: f23e0643 ("ibmvnic: Clear pending interrupt after device reset")
      Signed-off-by: NCédric Le Goater <clg@kaod.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc2d858b
    • T
      net: i82596: fix dma_alloc_attr for sni_82596 · 3f9d4e3c
      Thomas Bogendoerfer 提交于
      [ Upstream commit 61c1d33daf7b5146f44d4363b3322f8cda6a6c43 ]
      
      Commit 7f683b92 ("i825xx: switch to switch to dma_alloc_attrs")
      switched dma allocation over to dma_alloc_attr, but didn't convert
      the SNI part to request consistent DMA memory. This broke sni_82596
      since driver doesn't do dma_cache_sync for performance reasons.
      Fix this by using different DMA_ATTRs for lasi_82596 and sni_82596.
      
      Fixes: 7f683b92 ("i825xx: switch to switch to dma_alloc_attrs")
      Signed-off-by: NThomas Bogendoerfer <tbogendoerfer@suse.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3f9d4e3c
    • F
      net: bcmgenet: Set phydev->dev_flags only for internal PHYs · da0baae9
      Florian Fainelli 提交于
      [ Upstream commit 92696286f3bb37ba50e4bd8d1beb24afb759a799 ]
      
      phydev->dev_flags is entirely dependent on the PHY device driver which
      is going to be used, setting the internal GENET PHY revision in those
      bits only makes sense when drivers/net/phy/bcm7xxx.c is the PHY driver
      being used.
      
      Fixes: 487320c5 ("net: bcmgenet: communicate integrated PHY revision to PHY driver")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NDoug Berger <opendmb@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      da0baae9
    • F
      net: bcmgenet: Fix RGMII_MODE_EN value for GENET v1/2/3 · c0f5839a
      Florian Fainelli 提交于
      [ Upstream commit efb86fede98cdc70b674692ff617b1162f642c49 ]
      
      The RGMII_MODE_EN bit value was 0 for GENET versions 1 through 3, and
      became 6 for GENET v4 and above, account for that difference.
      
      Fixes: aa09677c ("net: bcmgenet: add MDIO routines")
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Acked-by: NDoug Berger <opendmb@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0f5839a
    • E
      net: avoid potential infinite loop in tc_ctl_action() · 16d67aca
      Eric Dumazet 提交于
      [ Upstream commit 39f13ea2f61b439ebe0060393e9c39925c9ee28c ]
      
      tc_ctl_action() has the ability to loop forever if tcf_action_add()
      returns -EAGAIN.
      
      This special case has been done in case a module needed to be loaded,
      but it turns out that tcf_add_notify() could also return -EAGAIN
      if the socket sk_rcvbuf limit is hit.
      
      We need to separate the two cases, and only loop for the module
      loading case.
      
      While we are at it, add a limit of 10 attempts since unbounded
      loops are always scary.
      
      syzbot repro was something like :
      
      socket(PF_NETLINK, SOCK_RAW|SOCK_NONBLOCK, NETLINK_ROUTE) = 3
      write(3, ..., 38) = 38
      setsockopt(3, SOL_SOCKET, SO_RCVBUF, [0], 4) = 0
      sendmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{..., 388}], msg_controllen=0, msg_flags=0x10}, ...)
      
      NMI backtrace for cpu 0
      CPU: 0 PID: 1054 Comm: khungtaskd Not tainted 5.4.0-rc1+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       nmi_cpu_backtrace.cold+0x70/0xb2 lib/nmi_backtrace.c:101
       nmi_trigger_cpumask_backtrace+0x23b/0x28b lib/nmi_backtrace.c:62
       arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
       trigger_all_cpu_backtrace include/linux/nmi.h:146 [inline]
       check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
       watchdog+0x9d0/0xef0 kernel/hung_task.c:289
       kthread+0x361/0x430 kernel/kthread.c:255
       ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
      Sending NMI from CPU 0 to CPUs 1:
      NMI backtrace for cpu 1
      CPU: 1 PID: 8859 Comm: syz-executor910 Not tainted 5.4.0-rc1+ #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:arch_local_save_flags arch/x86/include/asm/paravirt.h:751 [inline]
      RIP: 0010:lockdep_hardirqs_off+0x1df/0x2e0 kernel/locking/lockdep.c:3453
      Code: 5c 08 00 00 5b 41 5c 41 5d 5d c3 48 c7 c0 58 1d f3 88 48 ba 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 0f 85 d3 00 00 00 <48> 83 3d 21 9e 99 07 00 0f 84 b9 00 00 00 9c 58 0f 1f 44 00 00 f6
      RSP: 0018:ffff8880a6f3f1b8 EFLAGS: 00000046
      RAX: 1ffffffff11e63ab RBX: ffff88808c9c6080 RCX: 0000000000000000
      RDX: dffffc0000000000 RSI: 0000000000000000 RDI: ffff88808c9c6914
      RBP: ffff8880a6f3f1d0 R08: ffff88808c9c6080 R09: fffffbfff16be5d1
      R10: fffffbfff16be5d0 R11: 0000000000000003 R12: ffffffff8746591f
      R13: ffff88808c9c6080 R14: ffffffff8746591f R15: 0000000000000003
      FS:  00000000011e4880(0000) GS:ffff8880ae900000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffff600400 CR3: 00000000a8920000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       trace_hardirqs_off+0x62/0x240 kernel/trace/trace_preemptirq.c:45
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
       _raw_spin_lock_irqsave+0x6f/0xcd kernel/locking/spinlock.c:159
       __wake_up_common_lock+0xc8/0x150 kernel/sched/wait.c:122
       __wake_up+0xe/0x10 kernel/sched/wait.c:142
       netlink_unlock_table net/netlink/af_netlink.c:466 [inline]
       netlink_unlock_table net/netlink/af_netlink.c:463 [inline]
       netlink_broadcast_filtered+0x705/0xb80 net/netlink/af_netlink.c:1514
       netlink_broadcast+0x3a/0x50 net/netlink/af_netlink.c:1534
       rtnetlink_send+0xdd/0x110 net/core/rtnetlink.c:714
       tcf_add_notify net/sched/act_api.c:1343 [inline]
       tcf_action_add+0x243/0x370 net/sched/act_api.c:1362
       tc_ctl_action+0x3b5/0x4bc net/sched/act_api.c:1410
       rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5386
       netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
       rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5404
       netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
       netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
       netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
       sock_sendmsg_nosec net/socket.c:637 [inline]
       sock_sendmsg+0xd7/0x130 net/socket.c:657
       ___sys_sendmsg+0x803/0x920 net/socket.c:2311
       __sys_sendmsg+0x105/0x1d0 net/socket.c:2356
       __do_sys_sendmsg net/socket.c:2365 [inline]
       __se_sys_sendmsg net/socket.c:2363 [inline]
       __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
       do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x440939
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: syzbot+cf0adbb9c28c8866c788@syzkaller.appspotmail.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      16d67aca
    • S
      ipv4: Return -ENETUNREACH if we can't create route but saddr is valid · 2fa80e64
      Stefano Brivio 提交于
      [ Upstream commit 595e0651d0296bad2491a4a29a7a43eae6328b02 ]
      
      ...instead of -EINVAL. An issue was found with older kernel versions
      while unplugging a NFS client with pending RPCs, and the wrong error
      code here prevented it from recovering once link is back up with a
      configured address.
      
      Incidentally, this is not an issue anymore since commit 4f8943f80883
      ("SUNRPC: Replace direct task wakeups from softirq context"), included
      in 5.2-rc7, had the effect of decoupling the forwarding of this error
      by using SO_ERROR in xs_wake_error(), as pointed out by Benjamin
      Coddington.
      
      To the best of my knowledge, this isn't currently causing any further
      issue, but the error code doesn't look appropriate anyway, and we
      might hit this in other paths as well.
      
      In detail, as analysed by Gonzalo Siero, once the route is deleted
      because the interface is down, and can't be resolved and we return
      -EINVAL here, this ends up, courtesy of inet_sk_rebuild_header(),
      as the socket error seen by tcp_write_err(), called by
      tcp_retransmit_timer().
      
      In turn, tcp_write_err() indirectly calls xs_error_report(), which
      wakes up the RPC pending tasks with a status of -EINVAL. This is then
      seen by call_status() in the SUN RPC implementation, which aborts the
      RPC call calling rpc_exit(), instead of handling this as a
      potentially temporary condition, i.e. as a timeout.
      
      Return -EINVAL only if the input parameters passed to
      ip_route_output_key_hash_rcu() are actually invalid (this is the case
      if the specified source address is multicast, limited broadcast or
      all zeroes), but return -ENETUNREACH in all cases where, at the given
      moment, the given source address doesn't allow resolving the route.
      
      While at it, drop the initialisation of err to -ENETUNREACH, which
      was added to __ip_route_output_key() back then by commit
      0315e382 ("net: Fix behaviour of unreachable, blackhole and
      prohibit routes"), but actually had no effect, as it was, and is,
      overwritten by the fib_lookup() return code assignment, and anyway
      ignored in all other branches, including the if (fl4->saddr) one:
      I find this rather confusing, as it would look like -ENETUNREACH is
      the "default" error, while that statement has no effect.
      
      Also note that after commit fc75fc83 ("ipv4: dont create routes
      on down devices"), we would get -ENETUNREACH if the device is down,
      but -EINVAL if the source address is specified and we can't resolve
      the route, and this appears to be rather inconsistent.
      Reported-by: NStefan Walter <walteste@inf.ethz.ch>
      Analysed-by: NBenjamin Coddington <bcodding@redhat.com>
      Analysed-by: NGonzalo Siero <gsierohu@redhat.com>
      Signed-off-by: NStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2fa80e64
    • W
      ipv4: fix race condition between route lookup and invalidation · 2ec0df4e
      Wei Wang 提交于
      [ Upstream commit 5018c59607a511cdee743b629c76206d9c9e6d7b ]
      
      Jesse and Ido reported the following race condition:
      <CPU A, t0> - Received packet A is forwarded and cached dst entry is
      taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set()
      
      <t1> - Given Jesse has busy routers ("ingesting full BGP routing tables
      from multiple ISPs"), route is added / deleted and rt_cache_flush() is
      called
      
      <CPU B, t2> - Received packet B tries to use the same cached dst entry
      from t0, but rt_cache_valid() is no longer true and it is replaced in
      rt_cache_route() by the newer one. This calls dst_dev_put() on the
      original dst entry which assigns the blackhole netdev to 'dst->dev'
      
      <CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due
      to 'dst->dev' being the blackhole netdev
      
      There are 2 issues in the v4 routing code:
      1. A per-netns counter is used to do the validation of the route. That
      means whenever a route is changed in the netns, users of all routes in
      the netns needs to redo lookup. v6 has an implementation of only
      updating fn_sernum for routes that are affected.
      2. When rt_cache_valid() returns false, rt_cache_route() is called to
      throw away the current cache, and create a new one. This seems
      unnecessary because as long as this route does not change, the route
      cache does not need to be recreated.
      
      To fully solve the above 2 issues, it probably needs quite some code
      changes and requires careful testing, and does not suite for net branch.
      
      So this patch only tries to add the deleted cached rt into the uncached
      list, so user could still be able to use it to receive packets until
      it's done.
      
      Fixes: 95c47f9c ("ipv4: call dst_dev_put() properly")
      Signed-off-by: NWei Wang <weiwan@google.com>
      Reported-by: NIdo Schimmel <idosch@idosch.org>
      Reported-by: NJesse Hathaway <jesse@mbuki-mvuki.org>
      Tested-by: NJesse Hathaway <jesse@mbuki-mvuki.org>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Cc: David Ahern <dsahern@gmail.com>
      Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ec0df4e