linux-stable.git, branch v5.4.153

Linux 5.4.153

2021-10-13T08:08:21+00:00

Link: https://lore.kernel.org/r/20211011134503.715740503@linuxfoundation.org
Tested-by: Florian Fainelli 
Tested-by: Shuah Khan 
Tested-by: Hulk Robot 
Link: https://lore.kernel.org/r/20211012064436.577746139@linuxfoundation.org
Link: https://lore.kernel.org/r/20211012093344.002301190@linuxfoundation.org
Tested-by: Jon Hunter 
Tested-by: Shuah Khan 
Tested-by: Linux Kernel Functional Testing 
Tested-by: Guenter Roeck 
Tested-by: Florian Fainelli 
Signed-off-by: Greg Kroah-Hartman

x86/Kconfig: Correct reference to MWINCHIP3D

2021-10-13T08:08:21+00:00

commit 225bac2dc5d192e55f2c50123ee539b1edf8a411 upstream.

Commit in Fixes intended to exclude the Winchip series and referred to
CONFIG_WINCHIP3D, but the config symbol is called CONFIG_MWINCHIP3D.

Hence, scripts/checkkconfigsymbols.py warns:

WINCHIP3D
Referencing files: arch/x86/Kconfig

Correct the reference to the intended config symbol.

Fixes: 69b8d3fcabdc ("x86/Kconfig: Exclude i586-class CPUs lacking PAE support from the HIGHMEM64G Kconfig group")
Suggested-by: Randy Dunlap 
Signed-off-by: Lukas Bulwahn 
Signed-off-by: Borislav Petkov 
Cc: 
Link: https://lkml.kernel.org/r/20210803113531.30720-4-lukas.bulwahn@gmail.com
[manually adjusted the change to the state on the v4.19.y and v5.4.y stable tree]
Signed-off-by: Lukas Bulwahn 
Signed-off-by: Greg Kroah-Hartman

x86/hpet: Use another crystalball to evaluate HPET usability

2021-10-13T08:08:21+00:00

commit 6e3cd95234dc1eda488f4f487c281bac8fef4d9b upstream.

On recent Intel systems the HPET stops working when the system reaches PC10
idle state.

The approach of adding PCI ids to the early quirks to disable HPET on
these systems is a whack a mole game which makes no sense.

Check for PC10 instead and force disable HPET if supported. The check is
overbroad as it does not take ACPI, intel_idle enablement and command
line parameters into account. That's fine as long as there is at least
PMTIMER available to calibrate the TSC frequency. The decision can be
overruled by adding "hpet=force" on the kernel command line.

Remove the related early PCI quirks for affected Ice Cake and Coffin Lake
systems as they are not longer required. That should also cover all
other systems, i.e. Tiger Rag and newer generations, which are most
likely affected by this as well.

Fixes: Yet another hardware trainwreck
Reported-by: Jakub Kicinski 
Signed-off-by: Thomas Gleixner 
Tested-by: Jakub Kicinski 
Reviewed-by: Rafael J. Wysocki 
Cc: stable@vger.kernel.org
Cc: Kai-Heng Feng 
Cc: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

x86/platform/olpc: Correct ifdef symbol to intended CONFIG_OLPC_XO15_SCI

2021-10-13T08:08:20+00:00

commit 4758fd801f919b8b9acad78d2e49a195ec2be46b upstream.

The refactoring in the commit in Fixes introduced an ifdef
CONFIG_OLPC_XO1_5_SCI, however the config symbol is actually called
"CONFIG_OLPC_XO15_SCI".

Fortunately, ./scripts/checkkconfigsymbols.py warns:

OLPC_XO1_5_SCI
Referencing files: arch/x86/platform/olpc/olpc.c

Correct this ifdef condition to the intended config symbol.

Fixes: ec9964b48033 ("Platform: OLPC: Move EC-specific functionality out from x86")
Suggested-by: Randy Dunlap 
Signed-off-by: Lukas Bulwahn 
Signed-off-by: Borislav Petkov 
Cc: 
Link: https://lkml.kernel.org/r/20210803113531.30720-3-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman

RISC-V: Include clone3() on rv32

2021-10-13T08:08:20+00:00

[ Upstream commit 59a4e0d5511ba61353ea9a4efdb1b86c23ecf134 ]

As far as I can tell this should be enabled on rv32 as well, I'm not
sure why it's rv64-only.  checksyscalls is complaining about our lack of
clone3() on rv32.

Fixes: 56ac5e213933 ("riscv: enable sys_clone3 syscall for rv64")
Signed-off-by: Palmer Dabbelt 
Reviewed-by: Arnd Bergmann 
Acked-by: Christian Brauner 
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Sasha Levin

bpf, s390: Fix potential memory leak about jit_data

2021-10-13T08:08:20+00:00

[ Upstream commit 686cb8b9f6b46787f035afe8fbd132a74e6b1bdd ]

Make sure to free jit_data through kfree() in the error path.

Fixes: 1c8f9b91c456 ("bpf: s390: add JIT support for multi-function programs")
Signed-off-by: Tiezhu Yang 
Acked-by: Ilya Leoshkevich 
Reviewed-by: Christian Borntraeger 
Signed-off-by: Christian Borntraeger 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Sasha Levin

i2c: acpi: fix resource leak in reconfiguration device addition

2021-10-13T08:08:20+00:00

[ Upstream commit 6558b646ce1c2a872fe1c2c7cb116f05a2c1950f ]

acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a
reference on the adapter which is never released which will result in a
reference count leak and render the adapter unremovable.  Make sure to
put the adapter after creating the client in the same manner that we do
for OF.

Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications")
Signed-off-by: Jamie Iles 
Acked-by: Mika Westerberg 
[wsa: fixed title]
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

net: prefer socket bound to interface when not in VRF

2021-10-13T08:08:20+00:00

[ Upstream commit 8d6c414cd2fb74aa6812e9bfec6178f8246c4f3a ]

The commit 6da5b0f027a8 ("net: ensure unbound datagram socket to be
chosen when not in a VRF") modified compute_score() so that a device
match is always made, not just in the case of an l3mdev skb, then
increments the score also for unbound sockets. This ensures that
sockets bound to an l3mdev are never selected when not in a VRF.
But as unbound and bound sockets are now scored equally, this results
in the last opened socket being selected if there are matches in the
default VRF for an unbound socket and a socket bound to a dev that is
not an l3mdev. However, handling prior to this commit was to always
select the bound socket in this case. Reinstate this handling by
incrementing the score only for bound sockets. The required isolation
due to choosing between an unbound socket and a socket bound to an
l3mdev remains in place due to the device match always being made.
The same approach is taken for compute_score() for stream sockets.

Fixes: 6da5b0f027a8 ("net: ensure unbound datagram socket to be chosen when not in a VRF")
Fixes: e78190581aff ("net: ensure unbound stream socket to be chosen when not in a VRF")
Signed-off-by: Mike Manning 
Reviewed-by: David Ahern 
Link: https://lore.kernel.org/r/cf0a8523-b362-1edf-ee78-eef63cbbb428@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin

i40e: Fix freeing of uninitialized misc IRQ vector

2021-10-13T08:08:20+00:00

[ Upstream commit 2e5a20573a926302b233b0c2e1077f5debc7ab2e ]

When VSI set up failed in i40e_probe() as part of PF switch set up
driver was trying to free misc IRQ vectors in
i40e_clear_interrupt_scheme and produced a kernel Oops:

   Trying to free already-free IRQ 266
   WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300
   Workqueue: events work_for_cpu_fn
   RIP: 0010:__free_irq+0x9a/0x300
   Call Trace:
   ? synchronize_irq+0x3a/0xa0
   free_irq+0x2e/0x60
   i40e_clear_interrupt_scheme+0x53/0x190 [i40e]
   i40e_probe.part.108+0x134b/0x1a40 [i40e]
   ? kmem_cache_alloc+0x158/0x1c0
   ? acpi_ut_update_ref_count.part.1+0x8e/0x345
   ? acpi_ut_update_object_reference+0x15e/0x1e2
   ? strstr+0x21/0x70
   ? irq_get_irq_data+0xa/0x20
   ? mp_check_pin_attr+0x13/0xc0
   ? irq_get_irq_data+0xa/0x20
   ? mp_map_pin_to_irq+0xd3/0x2f0
   ? acpi_register_gsi_ioapic+0x93/0x170
   ? pci_conf1_read+0xa4/0x100
   ? pci_bus_read_config_word+0x49/0x70
   ? do_pci_enable_device+0xcc/0x100
   local_pci_probe+0x41/0x90
   work_for_cpu_fn+0x16/0x20
   process_one_work+0x1a7/0x360
   worker_thread+0x1cf/0x390
   ? create_worker+0x1a0/0x1a0
   kthread+0x112/0x130
   ? kthread_flush_work_fn+0x10/0x10
   ret_from_fork+0x1f/0x40

The problem is that at that point misc IRQ vectors
were not allocated yet and we get a call trace
that driver is trying to free already free IRQ vectors.

Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED
PF state before calling i40e_free_misc_vector. This state is set only if
misc IRQ vectors were properly initialized.

Fixes: c17401a1dd21 ("i40e: use separate state bit for miscellaneous IRQ setup")
Reported-by: PJ Waskiewicz 
Signed-off-by: Sylwester Dziedziuch 
Signed-off-by: Mateusz Palczewski 
Tested-by: Dave Switzer 
Signed-off-by: Tony Nguyen 
Signed-off-by: Sasha Levin

i40e: fix endless loop under rtnl

2021-10-13T08:08:20+00:00

[ Upstream commit 857b6c6f665cca9828396d9743faf37fd09e9ac3 ]

The loop in i40e_get_capabilities can never end. The problem is that
although i40e_aq_discover_capabilities returns with an error if there's
a firmware problem, the returned error is not checked. There is a check for
pf->hw.aq.asq_last_status but that value is set to I40E_AQ_RC_OK on most
firmware problems.

When i40e_aq_discover_capabilities encounters a firmware problem, it will
encounter the same problem on its next invocation. As the result, the loop
becomes endless. We hit this with I40E_ERR_ADMIN_QUEUE_TIMEOUT but looking
at the code, it can happen with a range of other firmware errors.

I don't know what the correct behavior should be: whether the firmware
should be retried a few times, or whether pf->hw.aq.asq_last_status should
be always set to the encountered firmware error (but then it would be
pointless and can be just replaced by the i40e_aq_discover_capabilities
return value). However, the current behavior with an endless loop under the
rtnl mutex(!) is unacceptable and Intel has not submitted a fix, although we
explained the bug to them 7 months ago.

This may not be the best possible fix but it's better than hanging the whole
system on a firmware bug.

Fixes: 56a62fc86895 ("i40e: init code and hardware support")
Tested-by: Stefan Assmann 
Signed-off-by: Jiri Benc 
Reviewed-by: Jesse Brandeburg 
Tested-by: Dave Switzer 
Signed-off-by: Tony Nguyen 
Signed-off-by: Sasha Levin