linux.git, branch v5.4.246

Linux 5.4.246

2023-06-09T08:29:04+00:00

Link: https://lore.kernel.org/r/20230607200900.195572674@linuxfoundation.org
Tested-by: Florian Fainelli 
Tested-by: Shuah Khan 
Tested-by: Chris Paterson (CIP) 
Tested-by: Harshit Mogalapalli 
Tested-by: Guenter Roeck 
Tested-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman

drm/edid: fix objtool warning in drm_cvt_modes()

2023-06-09T08:29:04+00:00

commit d652d5f1eeeb06046009f4fcb9b4542249526916 upstream.

Commit 991fcb77f490 ("drm/edid: Fix uninitialized variable in
drm_cvt_modes()") just replaced one warning with another.

The original warning about a possibly uninitialized variable was due to
the compiler not being smart enough to see that the case statement
actually enumerated all possible cases.  And the initial fix was just to
add a "default" case that had a single "unreachable()", just to tell the
compiler that that situation cannot happen.

However, that doesn't actually fix the fundamental reason for the
problem: the compiler still doesn't see that the existing case
statements enumerate all possibilities, so the compiler will still
generate code to jump to that unreachable case statement.  It just won't
complain about an uninitialized variable any more.

So now the compiler generates code to our inline asm marker that we told
it would not fall through, and end end result is basically random.  We
have created a bridge to nowhere.

And then, depending on the random details of just exactly what the
compiler ends up doing, 'objtool' might end up complaining about the
conditional branches (for conditions that cannot happen, and that thus
will never be taken - but if the compiler was not smart enough to figure
that out, we can't expect objtool to do so) going off in the weeds.

So depending on how the compiler has laid out the result, you might see
something like this:

    drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_mode_detailed.isra.0()

and now you have a truly inscrutable warning that makes no sense at all
unless you start looking at whatever random code the compiler happened
to generate for our bare "unreachable()" statement.

IOW, don't use "unreachable()" unless you have an _active_ operation
that generates code that actually makes it obvious that something is not
reachable (ie an UD instruction or similar).

Solve the "compiler isn't smart enough" problem by just marking one of
the cases as "default", so that even when the compiler doesn't otherwise
see that we've enumerated all cases, the compiler will feel happy and
safe about there always being a valid case that initializes the 'width'
variable.

This also generates better code, since now the compiler doesn't generate
comparisons for five different possibilities (the four real ones and the
one that can't happen), but just for the three real ones and "the rest"
(which is that last one).

A smart enough compiler that sees that we cover all the cases won't care.

Cc: Lyude Paul 
Cc: Ilia Mirkin 
Cc: Josh Poimboeuf 
Cc: Peter Zijlstra 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

wifi: rtlwifi: 8192de: correct checking of IQK reload

2023-06-09T08:29:04+00:00

commit 93fbc1ebd978cf408ef5765e9c1630fce9a8621b upstream.

Since IQK could spend time, we make a cache of IQK result matrix that looks
like iqk_matrix[channel_idx].val[x][y], and we can reload the matrix if we
have made a cache. To determine a cache is made, we check
iqk_matrix[channel_idx].val[0][0].

The initial commit 7274a8c22980 ("rtlwifi: rtl8192de: Merge phy routines")
make a mistake that checks incorrect iqk_matrix[channel_idx].val[0] that
is always true, and this mistake is found by commit ee3db469dd31
("wifi: rtlwifi: remove always-true condition pointed out by GCC 12"), so
I recall the vendor driver to find fix and apply the correctness.

Fixes: 7274a8c22980 ("rtlwifi: rtl8192de: Merge phy routines")
Signed-off-by: Ping-Ke Shih 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20220801113345.42016-1-pkshih@realtek.com
Signed-off-by: Greg Kroah-Hartman

drm/edid: Fix uninitialized variable in drm_cvt_modes()

2023-06-09T08:29:04+00:00

commit 991fcb77f490390bcad89fa67d95763c58cdc04c upstream.

Noticed this when trying to compile with -Wall on a kernel fork. We
potentially don't set width here, which causes the compiler to complain
about width potentially being uninitialized in drm_cvt_modes(). So, let's
fix that.

Changes since v1:
* Don't emit an error as this code isn't reachable, just mark it as such
Changes since v2:
* Remove now unused variable

Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage")
Signed-off-by: Lyude Paul 
Reviewed-by: Ilia Mirkin 
Link: https://patchwork.freedesktop.org/patch/msgid/20201105235703.1328115-1-lyude@redhat.com
Signed-off-by: Greg Kroah-Hartman

RDMA/bnxt_re: Remove the qp from list only if the qp destroy succeeds

2023-06-09T08:29:04+00:00

commit 097a9d23b7250355b182c5fd47dd4c55b22b1c33 upstream.

Driver crashes when destroy_qp is re-tried because of an error
returned. This is because the qp entry was removed from the qp list during
the first call.

Remove qp from the list only if destroy_qp returns success.

The driver will still trigger a WARN_ON due to the memory leaking, but at
least it isn't corrupting memory too.

Fixes: 8dae419f9ec7 ("RDMA/bnxt_re: Refactor queue pair creation code")
Link: https://lore.kernel.org/r/1598292876-26529-2-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Selvin Xavier 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

RDMA/bnxt_re: Remove set but not used variable 'dev_attr'

2023-06-09T08:29:04+00:00

commit a0b404a98e274b5fc0cfb7c108d99127d482e5ff upstream.

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/infiniband/hw/bnxt_re/ib_verbs.c: In function 'bnxt_re_create_gsi_qp':
drivers/infiniband/hw/bnxt_re/ib_verbs.c:1283:30: warning:
 variable 'dev_attr' set but not used [-Wunused-but-set-variable]

commit 8dae419f9ec7 ("RDMA/bnxt_re: Refactor queue pair creation code")
involved this, but not used, so remove it.

Link: https://lore.kernel.org/r/20200227064542.91205-1-yuehaibing@huawei.com
Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman

scsi: dpt_i2o: Do not process completions with invalid addresses

2023-06-09T08:29:04+00:00

adpt_isr() reads reply addresses from a hardware register, which
should always be within the DMA address range of the device's pool of
reply address buffers.  In case the address is out of range, it tries
to muddle on, converting to a virtual address using bus_to_virt().

bus_to_virt() does not take DMA addresses, and it doesn't make sense
to try to handle the completion in this case.  Ignore it and continue
looping to service the interrupt.  If a completion has been lost then
the SCSI core should eventually time-out and trigger a reset.

There is no corresponding upstream commit, because this driver was
removed upstream.

Fixes: 67af2b060e02 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt ...")
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

scsi: dpt_i2o: Remove broken pass-through ioctl (I2OUSERCMD)

2023-06-09T08:29:03+00:00

adpt_i2o_passthru() takes a user-provided message and passes it
through to the hardware with appropriate translation of addresses
and message IDs.  It has a number of bugs:

- When a message requires scatter/gather, it doesn't verify that the
  offset to the scatter/gather list is less than the message size.
- When a message requires scatter/gather, it overwrites the DMA
  addresses with the user-space virtual addresses before unmapping the
  DMA buffers.
- It reads the message from user memory multiple times.  This allows
  user-space to change the message and bypass validation.
- It assumes that the message is at least 4 words long, but doesn't
  check that.

I tried fixing these, but even the maintainer of the corresponding
user-space in Debian doesn't have the hardware any more.

Instead, remove the pass-through ioctl (I2OUSRCMD) and supporting
code.

There is no corresponding upstream commit, because this driver was
removed upstream.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes: 67af2b060e02 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt ...")
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

regmap: Account for register length when chunking

2023-06-09T08:29:03+00:00

commit 3981514180c987a79ea98f0ae06a7cbf58a9ac0f upstream.

Currently, when regmap_raw_write() splits the data, it uses the
max_raw_write value defined for the bus.  For any bus that includes
the target register address in the max_raw_write value, the chunked
transmission will always exceed the maximum transmission length.
To avoid this problem, subtract the length of the register and the
padding from the maximum transmission.

Signed-off-by: Jim Wylder

test_firmware: fix the memory leak of the allocated firmware buffer

2023-06-09T08:29:03+00:00

commit 48e156023059e57a8fc68b498439832f7600ffff upstream.

The following kernel memory leak was noticed after running
tools/testing/selftests/firmware/fw_run_tests.sh:

[root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak
.
.
.
unreferenced object 0xffff955389bc3400 (size 1024):
  comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] slab_post_alloc_hook+0x8c/0x3c0
    [] __kmem_cache_alloc_node+0x184/0x240
    [] kmalloc_trace+0x2e/0xc0
    [] test_fw_run_batch_request+0x9d/0x180
    [] kthread+0x10b/0x140
    [] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334b400 (size 1024):
  comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] slab_post_alloc_hook+0x8c/0x3c0
    [] __kmem_cache_alloc_node+0x184/0x240
    [] kmalloc_trace+0x2e/0xc0
    [] test_fw_run_batch_request+0x9d/0x180
    [] kthread+0x10b/0x140
    [] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c334f000 (size 1024):
  comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] slab_post_alloc_hook+0x8c/0x3c0
    [] __kmem_cache_alloc_node+0x184/0x240
    [] kmalloc_trace+0x2e/0xc0
    [] test_fw_run_batch_request+0x9d/0x180
    [] kthread+0x10b/0x140
    [] ret_from_fork+0x29/0x50
unreferenced object 0xffff9553c3348400 (size 1024):
  comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s)
  hex dump (first 32 bytes):
    47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00  GH4567..........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] slab_post_alloc_hook+0x8c/0x3c0
    [] __kmem_cache_alloc_node+0x184/0x240
    [] kmalloc_trace+0x2e/0xc0
    [] test_fw_run_batch_request+0x9d/0x180
    [] kthread+0x10b/0x140
    [] ret_from_fork+0x29/0x50
[root@pc-mtodorov firmware]#

Note that the size 1024 corresponds to the size of the test firmware
buffer. The actual number of the buffers leaked is around 70-110,
depending on the test run.

The cause of the leak is the following:

request_partial_firmware_into_buf() and request_firmware_into_buf()
provided firmware buffer isn't released on release_firmware(), we
have allocated it and we are responsible for deallocating it manually.
This is introduced in a number of context where previously only
release_firmware() was called, which was insufficient.

Reported-by: Mirsad Goran Todorovac 
Fixes: 7feebfa487b92 ("test_firmware: add support for request_firmware_into_buf")
Cc: Greg Kroah-Hartman 
Cc: Dan Carpenter 
Cc: Takashi Iwai 
Cc: Luis Chamberlain 
Cc: Russ Weight 
Cc: Tianfei zhang 
Cc: Christophe JAILLET 
Cc: Zhengchao Shao 
Cc: Colin Ian King 
Cc: linux-kernel@vger.kernel.org
Cc: Kees Cook 
Cc: Scott Branden 
Cc: Luis R. Rodriguez 
Cc: linux-kselftest@vger.kernel.org
Cc: stable@vger.kernel.org # v5.4
Signed-off-by: Mirsad Goran Todorovac 
Link: https://lore.kernel.org/r/20230509084746.48259-3-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman