Bart Van Assche [Tue, 12 Oct 2021 22:23:12 +0000 (15:23 -0700)]
MIPS: sni: Fix the build
[ Upstream commit
c91cf42f61dc77b289784ea7b15a8531defa41c0 ]
This patch fixes the following gcc 10 build error:
arch/mips/sni/time.c: In function ‘a20r_set_periodic’:
arch/mips/sni/time.c:15:26: error: unsigned conversion from ‘int’ to ‘u8’ {aka ‘volatile unsigned char’} changes value from ‘576’ to ‘64’ [-Werror=overflow]
15 | #define SNI_COUNTER0_DIV ((SNI_CLOCK_TICK_RATE / SNI_COUNTER2_DIV) / HZ)
| ^
arch/mips/sni/time.c:21:45: note: in expansion of macro ‘SNI_COUNTER0_DIV’
21 | *(volatile u8 *)(A20R_PT_CLOCK_BASE + 0) = SNI_COUNTER0_DIV;
| ^~~~~~~~~~~~~~~~
Cc: linux-mips@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guanghui Feng [Mon, 11 Oct 2021 14:08:24 +0000 (22:08 +0800)]
tty: tty_buffer: Fix the softlockup issue in flush_to_ldisc
[ Upstream commit
3968ddcf05fb4b9409cd1859feb06a5b0550a1c1 ]
When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a soft lockup,
which look like this one:
Workqueue: events_unbound flush_to_ldisc
Call trace:
dump_backtrace+0x0/0x1ec
show_stack+0x24/0x30
dump_stack+0xd0/0x128
panic+0x15c/0x374
watchdog_timer_fn+0x2b8/0x304
__run_hrtimer+0x88/0x2c0
__hrtimer_run_queues+0xa4/0x120
hrtimer_interrupt+0xfc/0x270
arch_timer_handler_phys+0x40/0x50
handle_percpu_devid_irq+0x94/0x220
__handle_domain_irq+0x88/0xf0
gic_handle_irq+0x84/0xfc
el1_irq+0xc8/0x180
slip_unesc+0x80/0x214 [slip]
tty_ldisc_receive_buf+0x64/0x80
tty_port_default_receive_buf+0x50/0x90
flush_to_ldisc+0xbc/0x110
process_one_work+0x1d4/0x4b0
worker_thread+0x180/0x430
kthread+0x11c/0x120
In the testcase pty04, The first process call the write syscall to send
data to the pty master. At the same time, the workqueue will do the
flush_to_ldisc to pop data in a loop until there is no more data left.
When the sender and workqueue running in different core, the sender sends
data fastly in full time which will result in workqueue doing work in loop
for a long time and occuring softlockup in flush_to_ldisc with kernel
configured without preempt. So I add need_resched check and cond_resched
in the flush_to_ldisc loop to avoid it.
Signed-off-by: Guanghui Feng <guanghuifeng@linux.alibaba.com>
Link: https://lore.kernel.org/r/1633961304-24759-1-git-send-email-guanghuifeng@linux.alibaba.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tvrtko Ursulin [Thu, 14 Oct 2021 05:38:31 +0000 (13:38 +0800)]
iommu/vt-d: Do not falsely log intel_iommu is unsupported kernel option
[ Upstream commit
5240aed2cd2594fb392239f11b9681e5e1591619 ]
Handling of intel_iommu kernel command line option should return "true" to
indicate option is valid and so avoid logging it as unknown by the core
parsing code.
Also log unknown sub-options at the notice level to let user know of
potential typos or similar.
Reported-by: Eero Tamminen <eero.t.tamminen@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://lore.kernel.org/r/20210831112947.310080-1-tvrtko.ursulin@linux.intel.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20211014053839.727419-2-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Sat, 16 Oct 2021 06:26:02 +0000 (23:26 -0700)]
ALSA: ISA: not for M68K
[ Upstream commit
3c05f1477e62ea5a0a8797ba6a545b1dc751fb31 ]
On m68k, compiling drivers under SND_ISA causes build errors:
../sound/core/isadma.c: In function 'snd_dma_program':
../sound/core/isadma.c:33:17: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration]
33 | flags = claim_dma_lock();
| ^~~~~~~~~~~~~~
../sound/core/isadma.c:41:9: error: implicit declaration of function 'release_dma_lock' [-Werror=implicit-function-declaration]
41 | release_dma_lock(flags);
| ^~~~~~~~~~~~~~~~
../sound/isa/sb/sb16_main.c: In function 'snd_sb16_playback_prepare':
../sound/isa/sb/sb16_main.c:253:72: error: 'DMA_AUTOINIT' undeclared (first use in this function)
253 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_WRITE | DMA_AUTOINIT);
| ^~~~~~~~~~~~
../sound/isa/sb/sb16_main.c:253:72: note: each undeclared identifier is reported only once for each function it appears in
../sound/isa/sb/sb16_main.c: In function 'snd_sb16_capture_prepare':
../sound/isa/sb/sb16_main.c:322:71: error: 'DMA_AUTOINIT' undeclared (first use in this function)
322 | snd_dma_program(dma, runtime->dma_addr, size, DMA_MODE_READ | DMA_AUTOINIT);
| ^~~~~~~~~~~~
and more...
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20211016062602.3588-1-rdunlap@infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Li Yang [Tue, 12 Oct 2021 23:58:23 +0000 (18:58 -0500)]
ARM: dts: ls1021a-tsn: use generic "jedec,spi-nor" compatible for flash
[ Upstream commit
05e63b48b20fa70726be505a7660d1a07bc1cffb ]
We cannot list all the possible chips used in different board revisions,
just use the generic "jedec,spi-nor" compatible instead. This also
fixes dtbs_check error:
['jedec,spi-nor', 's25fl256s1', 's25fl512s'] is too long
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Li Yang [Tue, 12 Oct 2021 23:58:22 +0000 (18:58 -0500)]
ARM: dts: ls1021a: move thermal-zones node out of soc/
[ Upstream commit
1ee1500ef717eefb5d9bdaf97905cb81b4e69aa4 ]
This fixes dtbs-check error from simple-bus schema:
soc: thermal-zones: {'type': 'object'} is not allowed for {'cpu-thermal': ..... }
From schema: /home/leo/.local/lib/python3.8/site-packages/dtschema/schemas/simple-bus.yaml
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Derek Fang [Thu, 14 Oct 2021 09:40:54 +0000 (17:40 +0800)]
ASoC: rt5682: fix a little pop while playback
[ Upstream commit
4b19e4a77cc6baa0f840e8bae62ab974667f6207 ]
A little pop can be heard obviously from HP while playing a silent.
This patch fixes it by using two functions:
1. Enable HP 1bit output mode.
2. Change the charge pump switch size during playback on and off.
Signed-off-by: Derek Fang <derek.fang@realtek.com>
Link: https://lore.kernel.org/r/20211014094054.811-1-derek.fang@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Mon, 11 Oct 2021 13:49:20 +0000 (21:49 +0800)]
usb: host: ohci-tmio: check return value after calling platform_get_resource()
[ Upstream commit
9eff2b2e59fda25051ab36cd1cb5014661df657b ]
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20211011134920.118477-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Roger Quadros [Thu, 7 Oct 2021 12:08:30 +0000 (15:08 +0300)]
ARM: dts: omap: fix gpmc,mux-add-data type
[ Upstream commit
51b9e22ffd3c4c56cbb7caae9750f70e55ffa603 ]
gpmc,mux-add-data is not boolean.
Fixes the below errors flagged by dtbs_check.
"ethernet@4,0:gpmc,mux-add-data: True is not of type 'array'"
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
William Overton [Sun, 10 Oct 2021 14:58:41 +0000 (15:58 +0100)]
ALSA: usb-audio: Add support for the Pioneer DJM 750MK2 Mixer/Soundcard
[ Upstream commit
6d27788160362a7ee6c0d317636fe4b1ddbe59a7 ]
The kernel already has support for very similar Pioneer djm products
and this work is based on that.
Added device to quirks-table.h and added control info to
mixer_quirks.c.
Tested on my hardware and all working.
Signed-off-by: William Overton <willovertonuk@gmail.com>
Link: https://lore.kernel.org/r/20211010145841.11907-1-willovertonuk@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Fri, 1 Oct 2021 17:25:14 +0000 (19:25 +0200)]
HID: multitouch: disable sticky fingers for UPERFECT Y
[ Upstream commit
08b9a61a87bc339a73c584d8924c86ab36d204a7 ]
When a finger is on the screen, the UPERFECT Y portable touchscreen
monitor reports a contact in the first place. However, after this
initial report, contacts are not reported at the refresh rate of the
screen as required by the Windows 8 specs.
This behaviour triggers the release_timer, removing the fingers even
though they are still present.
To avoid it, add a new class, similar to MT_CLS_WIN_8 but without the
MT_QUIRK_STICKY_FINGERS quirk for this device.
Suggested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luis Chamberlain [Fri, 17 Sep 2021 18:22:13 +0000 (11:22 -0700)]
firmware_loader: fix pre-allocated buf built-in firmware use
[ Upstream commit
f7a07f7b96033df7709042ff38e998720a3f7119 ]
The firmware_loader can be used with a pre-allocated buffer
through the use of the API calls:
o request_firmware_into_buf()
o request_partial_firmware_into_buf()
If the firmware was built-in and present, our current check
for if the built-in firmware fits into the pre-allocated buffer
does not return any errors, and we proceed to tell the caller
that everything worked fine. It's a lie and no firmware would
end up being copied into the pre-allocated buffer. So if the
caller trust the result it may end up writing a bunch of 0's
to a device!
Fix this by making the function that checks for the pre-allocated
buffer return non-void. Since the typical use case is when no
pre-allocated buffer is provided make this return successfully
for that case. If the built-in firmware does *not* fit into the
pre-allocated buffer size return a failure as we should have
been doing before.
I'm not aware of users of the built-in firmware using the API
calls with a pre-allocated buffer, as such I doubt this fixes
any real life issue. But you never know... perhaps some oddball
private tree might use it.
In so far as upstream is concerned this just fixes our code for
correctness.
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20210917182226.3532898-2-mcgrof@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Mon, 4 Oct 2021 21:35:12 +0000 (16:35 -0500)]
ASoC: Intel: sof_sdw: add missing quirk for Dell SKU 0A45
[ Upstream commit
64ba6d2ce72ffde70dc5a1794917bf1573203716 ]
This device is based on SDCA codecs but with a single amplifier
instead of two.
BugLink: https://github.com/thesofproject/linux/issues/3161
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20211004213512.220836-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Mon, 4 Oct 2021 21:35:11 +0000 (16:35 -0500)]
ASoC: Intel: soc-acpi: add missing quirk for TGL SDCA single amp
[ Upstream commit
f2470679b070a77ea22f8b791fae7084c2340c7d ]
We don't have a configuration for a single amp on link1.
BugLink: https://github.com/thesofproject/linux/issues/3161
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Link: https://lore.kernel.org/r/20211004213512.220836-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Mon, 4 Oct 2021 21:35:09 +0000 (16:35 -0500)]
ALSA: intel-dsp-config: add quirk for APL/GLK/TGL devices based on ES8336 codec
[ Upstream commit
9d36ceab94151f07cf3fcb067213ac87937adf12 ]
These devices are based on an I2C/I2S device, we need to force the use
of the SOF driver otherwise the legacy HDaudio driver will be loaded -
only HDMI will be supported.
Co-developed-by: Huajun Li <huajun.li@intel.com>
Signed-off-by: Huajun Li <huajun.li@intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211004213512.220836-3-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Frieder Schrempf [Thu, 30 Sep 2021 15:56:30 +0000 (17:56 +0200)]
arm64: dts: imx8mm-kontron: Fix reset delays for ethernet PHY
[ Upstream commit
315e7b884190a6c9c28e95ad3b724dde9e922b99 ]
According to the datasheet the VSC8531 PHY expects a reset pulse of 100 ns
and a delay of 15 ms after the reset has been deasserted. Set the matching
values in the devicetree.
Reported-by: Heiko Thiery <heiko.thiery@gmail.com>
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mahesh Rajashekhara [Tue, 28 Sep 2021 23:54:33 +0000 (18:54 -0500)]
scsi: smartpqi: Add controller handshake during kdump
[ Upstream commit
9ee5d6e9ac52a3c8625697535f8e35864d9fd38c ]
Correct kdump hangs when controller is locked up.
There are occasions when a controller reboot (controller soft reset) is
issued when a controller firmware crash dump is in progress.
This leads to incomplete controller firmware crash dump:
- When the controller crash dump is in progress, and a kdump is initiated,
the driver issues inbound doorbell reset to bring back the controller in
SIS mode.
- If the controller is in locked up state, the inbound doorbell reset does
not work causing controller initialization failures. This results in the
driver hanging waiting for SIS mode.
To avoid an incomplete controller crash dump, add in a controller crash
dump handshake:
- Controller will indicate start and end of the controller crash dump by
setting some register bits.
- Driver will look these bits when a kdump is initiated. If a controller
crash dump is in progress, the driver will wait for the controller crash
dump to complete before issuing the controller soft reset then complete
driver initialization.
Link: https://lore.kernel.org/r/20210928235442.201875-3-don.brace@microchip.com
Reviewed-by: Scott Benesh <scott.benesh@microchip.com>
Reviewed-by: Scott Teel <scott.teel@microchip.com>
Reviewed-by: Mike McGowen <mike.mcgowen@microchip.com>
Acked-by: John Donnelly <john.p.donnelly@oracle.com>
Signed-off-by: Mahesh Rajashekhara <mahesh.rajashekhara@microchip.com>
Signed-off-by: Don Brace <don.brace@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guo Zhi [Wed, 29 Sep 2021 12:25:37 +0000 (20:25 +0800)]
scsi: advansys: Fix kernel pointer leak
[ Upstream commit
d4996c6eac4c81b8872043e9391563f67f13e406 ]
Pointers should be printed with %p or %px rather than cast to 'unsigned
long' and printed with %lx.
Change %lx to %p to print the hashed pointer.
Link: https://lore.kernel.org/r/20210929122538.1158235-1-qtxuning1999@sjtu.edu.cn
Signed-off-by: Guo Zhi <qtxuning1999@sjtu.edu.cn>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sat, 2 Oct 2021 21:14:57 +0000 (23:14 +0200)]
ASoC: nau8824: Add DMI quirk mechanism for active-high jack-detect
[ Upstream commit
92d3360108f1839ca40451bad20ff67dd24a1964 ]
Add a quirk mechanism to allow specifying that active-high jack-detection
should be used on platforms where this info is not available in devicetree.
And add an entry for the Cyberbook T116 tablet to the DMI table, so that
jack-detection will work properly on this tablet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211002211459.110124-2-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 3 Oct 2021 13:22:55 +0000 (15:22 +0200)]
ASoC: rt5651: Use IRQF_NO_AUTOEN when requesting the IRQ
[ Upstream commit
6e037b72cf4ea6c28a131ea021d63ee4e7e6fa64 ]
Use the new IRQF_NO_AUTOEN flag when requesting the IRQ, rather then
disabling it immediately after requesting it.
This fixes a possible race where the IRQ might trigger between requesting
and disabling it; and this also leads to a small code cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211003132255.31743-2-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 3 Oct 2021 13:22:54 +0000 (15:22 +0200)]
ASoC: es8316: Use IRQF_NO_AUTOEN when requesting the IRQ
[ Upstream commit
1cf2aa665901054b140eb71748661ceae99b6b5a ]
Use the new IRQF_NO_AUTOEN flag when requesting the IRQ, rather then
disabling it immediately after requesting it.
This fixes a possible race where the IRQ might trigger between requesting
and disabling it; and this also leads to a small code cleanup.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211003132255.31743-1-hdegoede@redhat.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Riedmueller [Mon, 27 Sep 2021 07:28:56 +0000 (09:28 +0200)]
clk: imx: imx6ul: Move csi_sel mux to correct base register
[ Upstream commit
2f9d61869640f732599ec36b984c2b5c46067519 ]
The csi_sel mux register is located in the CCM register base and not the
CCM_ANALOG register base. So move it to the correct position in code.
Otherwise changing the parent of the csi clock can lead to a complete
system failure due to the CCM_ANALOG_PLL_SYS_TOG register being falsely
modified.
Also remove the SET_RATE_PARENT flag since one possible supply for the
csi_sel mux is the system PLL which we don't want to modify.
Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Link: https://lore.kernel.org/r/20210927072857.3940880-1-s.riedmueller@phytec.de
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geraldo Nascimento [Thu, 30 Sep 2021 19:40:14 +0000 (16:40 -0300)]
ALSA: usb-audio: disable implicit feedback sync for Behringer UFX1204 and UFX1604
[ Upstream commit
28c369e60827f706cef4604a3e2848198f25bd26 ]
Behringer UFX1204 and UFX1604 have Synchronous endpoints to which
current ALSA code applies implicit feedback sync as if they were
Asynchronous endpoints. This breaks UAC compliance and is unneeded.
The commit
5e35dc0338d85ccebacf3f77eca1e5dea73155e8 and subsequent
1a15718b41df026cffd0e42cfdc38a1384ce19f9 were meant to clear up noise.
Unfortunately, noise persisted for those using higher sample rates and
this was only solved by commit
d2e8f641257d0d3af6e45d6ac2d6f9d56b8ea964
Since there are no more reports of noise, let's get rid of the
implicit-fb quirks breaking UAC compliance.
Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com>
Link: https://lore.kernel.org/r/YVYSnoQ7nxLXT0Dq@geday
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Damien Le Moal [Fri, 20 Aug 2021 07:02:53 +0000 (16:02 +0900)]
scsi: core: Fix scsi_mode_sense() buffer length handling
[ Upstream commit
17b49bcbf8351d3dbe57204468ac34f033ed60bc ]
Several problems exist with scsi_mode_sense() buffer length handling:
1) The allocation length field of the MODE SENSE(10) command is 16-bits,
occupying bytes 7 and 8 of the CDB. With this command, access to mode
pages larger than 255 bytes is thus possible. However, the CDB
allocation length field is set by assigning len to byte 8 only, thus
truncating buffer length larger than 255.
2) If scsi_mode_sense() is called with len smaller than 8 with
sdev->use_10_for_ms set, or smaller than 4 otherwise, the buffer length
is increased to 8 and 4 respectively, and the buffer is zero filled
with these increased values, thus corrupting the memory following the
buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev->use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
* Use get_unaligned_be16() to retrieve the mode data length and block
descriptor length fields of the mode sense reply header instead of using
an open coded calculation.
* Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
Block Descriptor, which is the opposite of what the dbd argument
description was.
Link: https://lore.kernel.org/r/20210820070255.682775-2-damien.lemoal@wdc.com
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Fri, 24 Sep 2021 19:24:17 +0000 (14:24 -0500)]
ASoC: SOF: Intel: hda-dai: fix potential locking issue
[ Upstream commit
a20f3b10de61add5e14b6ce4df982f4df2a4cbbc ]
The initial hdac_stream code was adapted a third time with the same
locking issues. Move the spin_lock outside the loops and make sure the
fields are protected on read/write.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210924192417.169243-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Pearson [Tue, 14 Sep 2021 16:42:05 +0000 (11:42 -0500)]
RDMA/rxe: Separate HW and SW l/rkeys
[ Upstream commit
001345339f4ca85790a1644a74e33ae77ac116be ]
Separate software and simulated hardware lkeys and rkeys for MRs and MWs.
This makes struct ib_mr and struct ib_mw isolated from hardware changes
triggered by executing work requests.
This change fixes a bug seen in blktest.
Link: https://lore.kernel.org/r/20210914164206.19768-4-rpearsonhpe@gmail.com
Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kuldeep Singh [Thu, 9 Sep 2021 11:12:29 +0000 (16:42 +0530)]
arm64: dts: ls1012a: Add serial alias for ls1012a-rdb
[ Upstream commit
7f31ae6e01da140e34d6513815253e811019f016 ]
U-boot atempts to read serial alias value for ls1012a-rdb but couldn't
do so as it is not initialised and thus, FDT_ERR_NOTFOUND error is
reported while booting linux.
Loading fdt from FIT Image at
a0000000 ...
Description: ls1012ardb-dtb
Type: Flat Device Tree
Data Start: 0xab111474
Data Size: 11285 Bytes = 11 KiB
Architecture: AArch64
Load Address: 0x90000000
Loading fdt from 0xab111474 to 0x90000000
Booting using the fdt blob at 0x90000000
Uncompressing Kernel Image
Loading Device Tree to
000000008fffa000, end
000000008ffffc14 ... OK
WARNING: fdt_fixup_stdout: could not read serial0 alias: FDT_ERR_NOTFOUND
NOTICE: RNG: INSTANTIATED
Starting kernel ...
Fix the above error by specifying serial value to duart.
Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Walle [Thu, 26 Aug 2021 12:35:28 +0000 (14:35 +0200)]
arm64: dts: freescale: fix arm,sp805 compatible string
[ Upstream commit
99a7cacc66cae92db40139b57689be2af75fc6b8 ]
According to Documentation/devicetree/bindings/watchdog/arm,sp805.yaml
the compatible is:
compatible = "arm,sp805", "arm,primecell";
The current compatible string doesn't exist at all. Fix it.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shawn Guo [Sun, 29 Aug 2021 11:16:28 +0000 (19:16 +0800)]
arm64: dts: qcom: sdm845: Fix qcom,controlled-remotely property
[ Upstream commit
1c8bf398b6b51eb085a49036ad8f9c000171cce1 ]
Property qcom,controlled-remotely should be boolean. Fix it.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210829111628.5543-4-shawn.guo@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shawn Guo [Sun, 29 Aug 2021 11:16:27 +0000 (19:16 +0800)]
arm64: dts: qcom: ipq8074: Fix qcom,controlled-remotely property
[ Upstream commit
8c97f0ac4dc8f1743eb8e8a49f66189e13ae45e9 ]
Property qcom,controlled-remotely should be boolean. Fix it.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210829111628.5543-3-shawn.guo@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shawn Guo [Sun, 29 Aug 2021 11:16:26 +0000 (19:16 +0800)]
arm64: dts: qcom: ipq6018: Fix qcom,controlled-remotely property
[ Upstream commit
3509de752ea14c7e5781b3a56a4a0bf832f5723a ]
Property qcom,controlled-remotely should be boolean. Fix it.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210829111628.5543-2-shawn.guo@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
AngeloGioacchino Del Regno [Wed, 1 Sep 2021 18:31:21 +0000 (20:31 +0200)]
arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency
[ Upstream commit
3f1dcaff642e75c1d2ad03f783fa8a3b1f56dd50 ]
The entry/exit latency and minimum residency in state for the idle
states of MSM8998 were ..bad: first of all, for all of them the
timings were written for CPU sleep but the min-residency-us param
was miscalculated (supposedly, while porting this from downstream);
Then, the power collapse states are setting PC on both the CPU
cluster *and* the L2 cache, which have different timings: in the
specific case of L2 the times are higher so these ones should be
taken into account instead of the CPU ones.
This parameter misconfiguration was not giving particular issues
because on MSM8998 there was no CPU scaling at all, so cluster/L2
power collapse was rarely (if ever) hit.
When CPU scaling is enabled, though, the wrong timings will produce
SoC unstability shown to the user as random, apparently error-less,
sudden reboots and/or lockups.
This set of parameters are stabilizing the SoC when CPU scaling is
ON and when power collapse is frequently hit.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210901183123.1087392-3-angelogioacchino.delregno@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian Lamparter [Sat, 18 Sep 2021 17:29:30 +0000 (19:29 +0200)]
ARM: BCM53016: Specify switch ports for Meraki MR32
[ Upstream commit
6abc4ca5a28070945e0d68cb4160b309bfbf4b8b ]
the switch identifies itself as a BCM53012 (rev 5)...
This patch has been tested & verified on OpenWrt's
snapshot with Linux 5.10 (didn't test any older kernels).
The MR32 is able to "talk to the network" as before with
OpenWrt's SWITCHDEV b53 driver.
| b53-srab-switch
18007000.ethernet-switch: found switch: BCM53012, rev 5
| libphy: dsa slave smi: probed
| b53-srab-switch
18007000.ethernet-switch poe (uninitialized):
| PHY [dsa-0.0:00] driver [Generic PHY] (irq=POLL)
| b53-srab-switch
18007000.ethernet-switch: Using legacy PHYLIB callbacks.
| Please migrate to PHYLINK!
| DSA: tree 0 setup
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Mon, 20 Sep 2021 14:55:02 +0000 (16:55 +0200)]
staging: rtl8723bs: remove a third possible deadlock
[ Upstream commit
bdc1bbdbaa92df19a14d4c1902088c8432b46c6f ]
The assoc_timer takes the pmlmepriv->lock and various functions which
take the pmlmepriv->scanned_queue.lock first take the pmlmepriv->lock,
this means that we cannot have code which waits for the timer
(timer_del_sync) while holding the pmlmepriv->scanned_queue.lock
to avoid a triangle deadlock:
[ 363.139361] ======================================================
[ 363.139377] WARNING: possible circular locking dependency detected
[ 363.139396] 5.15.0-rc1+ #470 Tainted: G C E
[ 363.139413] ------------------------------------------------------
[ 363.139424] RTW_CMD_THREAD/2466 is trying to acquire lock:
[ 363.139441]
ffffbacd00699038 (&pmlmepriv->lock){+.-.}-{2:2}, at: _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[ 363.139598]
but task is already holding lock:
[ 363.139610]
ffffbacd00128ea0 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x5/0x260
[ 363.139673]
which lock already depends on the new lock.
[ 363.139684]
the existing dependency chain (in reverse order) is:
[ 363.139696]
-> #2 ((&pmlmepriv->assoc_timer)){+.-.}-{0:0}:
[ 363.139734] del_timer_sync+0x59/0x100
[ 363.139762] rtw_joinbss_event_prehandle+0x342/0x640 [r8723bs]
[ 363.139870] report_join_res+0xdf/0x110 [r8723bs]
[ 363.139980] OnAssocRsp+0x17a/0x200 [r8723bs]
[ 363.140092] rtw_recv_entry+0x190/0x1120 [r8723bs]
[ 363.140209] rtl8723b_process_phy_info+0x3f9/0x750 [r8723bs]
[ 363.140318] tasklet_action_common.constprop.0+0xe8/0x110
[ 363.140345] __do_softirq+0xde/0x485
[ 363.140372] __irq_exit_rcu+0xd0/0x100
[ 363.140393] irq_exit_rcu+0xa/0x20
[ 363.140413] common_interrupt+0x83/0xa0
[ 363.140440] asm_common_interrupt+0x1e/0x40
[ 363.140463] finish_task_switch.isra.0+0x157/0x3d0
[ 363.140492] __schedule+0x447/0x1880
[ 363.140516] schedule+0x59/0xc0
[ 363.140537] smpboot_thread_fn+0x161/0x1c0
[ 363.140565] kthread+0x143/0x160
[ 363.140585] ret_from_fork+0x22/0x30
[ 363.140614]
-> #1 (&pmlmepriv->scanned_queue.lock){+.-.}-{2:2}:
[ 363.140653] _raw_spin_lock_bh+0x34/0x40
[ 363.140675] rtw_free_network_queue+0x31/0x80 [r8723bs]
[ 363.140776] rtw_sitesurvey_cmd+0x79/0x1e0 [r8723bs]
[ 363.140869] rtw_cfg80211_surveydone_event_callback+0x3cf/0x470 [r8723bs]
[ 363.140973] rdev_scan+0x42/0x1a0 [cfg80211]
[ 363.141307] nl80211_trigger_scan+0x566/0x660 [cfg80211]
[ 363.141635] genl_family_rcv_msg_doit+0xcd/0x110
[ 363.141661] genl_rcv_msg+0xce/0x1c0
[ 363.141680] netlink_rcv_skb+0x50/0xf0
[ 363.141699] genl_rcv+0x24/0x40
[ 363.141717] netlink_unicast+0x16d/0x230
[ 363.141736] netlink_sendmsg+0x22b/0x450
[ 363.141755] sock_sendmsg+0x5e/0x60
[ 363.141781] ____sys_sendmsg+0x22f/0x270
[ 363.141803] ___sys_sendmsg+0x81/0xc0
[ 363.141828] __sys_sendmsg+0x49/0x80
[ 363.141851] do_syscall_64+0x3b/0x90
[ 363.141873] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 363.141895]
-> #0 (&pmlmepriv->lock){+.-.}-{2:2}:
[ 363.141930] __lock_acquire+0x1158/0x1de0
[ 363.141954] lock_acquire+0xb5/0x2b0
[ 363.141974] _raw_spin_lock_bh+0x34/0x40
[ 363.141993] _rtw_join_timeout_handler+0x3c/0x160 [r8723bs]
[ 363.142097] call_timer_fn+0x94/0x260
[ 363.142122] __run_timers.part.0+0x1bf/0x290
[ 363.142147] run_timer_softirq+0x26/0x50
[ 363.142171] __do_softirq+0xde/0x485
[ 363.142193] __irq_exit_rcu+0xd0/0x100
[ 363.142215] irq_exit_rcu+0xa/0x20
[ 363.142235] sysvec_apic_timer_interrupt+0x72/0x90
[ 363.142260] asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 363.142283] __module_address.part.0+0x0/0xd0
[ 363.142309] is_module_address+0x25/0x40
[ 363.142334] static_obj+0x4f/0x60
[ 363.142361] lockdep_init_map_type+0x47/0x220
[ 363.142382] __init_swait_queue_head+0x45/0x60
[ 363.142408] mmc_wait_for_req+0x4a/0xc0 [mmc_core]
[ 363.142504] mmc_wait_for_cmd+0x55/0x70 [mmc_core]
[ 363.142592] mmc_io_rw_direct+0x75/0xe0 [mmc_core]
[ 363.142691] sdio_writeb+0x2e/0x50 [mmc_core]
[ 363.142788] _sd_cmd52_write+0x62/0x80 [r8723bs]
[ 363.142885] sd_cmd52_write+0x6c/0xb0 [r8723bs]
[ 363.142981] rtl8723bs_set_hal_ops+0x982/0x9b0 [r8723bs]
[ 363.143089] rtw_write16+0x1e/0x30 [r8723bs]
[ 363.143184] SetHwReg8723B+0xcc9/0xd30 [r8723bs]
[ 363.143294] mlmeext_joinbss_event_callback+0x17a/0x1a0 [r8723bs]
[ 363.143405] rtw_joinbss_event_callback+0x11/0x20 [r8723bs]
[ 363.143507] mlme_evt_hdl+0x4d/0x70 [r8723bs]
[ 363.143620] rtw_cmd_thread+0x168/0x3c0 [r8723bs]
[ 363.143712] kthread+0x143/0x160
[ 363.143732] ret_from_fork+0x22/0x30
[ 363.143757]
other info that might help us debug this:
[ 363.143768] Chain exists of:
&pmlmepriv->lock --> &pmlmepriv->scanned_queue.lock --> (&pmlmepriv->assoc_timer)
[ 363.143809] Possible unsafe locking scenario:
[ 363.143819] CPU0 CPU1
[ 363.143831] ---- ----
[ 363.143841] lock((&pmlmepriv->assoc_timer));
[ 363.143862] lock(&pmlmepriv->scanned_queue.lock);
[ 363.143882] lock((&pmlmepriv->assoc_timer));
[ 363.143902] lock(&pmlmepriv->lock);
[ 363.143921]
*** DEADLOCK ***
Make rtw_joinbss_event_prehandle() release the scanned_queue.lock before
it deletes the timer to avoid this (it is still holding pmlmepriv->lock
protecting against racing the timer).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-3-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Mon, 20 Sep 2021 14:55:01 +0000 (16:55 +0200)]
staging: rtl8723bs: remove a second possible deadlock
[ Upstream commit
a7ac783c338bafc04d3259600646350dba989043 ]
Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:
[ 103.849756] ======================================================
[ 103.849761] WARNING: possible circular locking dependency detected
[ 103.849767] 5.15.0-rc1+ #470 Tainted: G C E
[ 103.849773] ------------------------------------------------------
[ 103.849776] wpa_supplicant/695 is trying to acquire lock:
[ 103.849781]
ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[ 103.849840]
but task is already holding lock:
[ 103.849843]
ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[ 103.849881]
which lock already depends on the new lock.
[ 103.849884]
the existing dependency chain (in reverse order) is:
[ 103.849887]
-> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[ 103.849898] _raw_spin_lock_bh+0x34/0x40
[ 103.849913] rtw_get_stainfo+0x93/0x110 [r8723bs]
[ 103.849948] rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[ 103.849983] rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[ 103.850019] rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[ 103.850050] kthread+0x143/0x160
[ 103.850058] ret_from_fork+0x22/0x30
[ 103.850067]
-> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[ 103.850077] __lock_acquire+0x1158/0x1de0
[ 103.850084] lock_acquire+0xb5/0x2b0
[ 103.850090] _raw_spin_lock_bh+0x34/0x40
[ 103.850095] rtw_free_stainfo+0x8a/0x510 [r8723bs]
[ 103.850130] rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[ 103.850159] PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[ 103.850189] cfg80211_disconnect+0x173/0x320 [cfg80211]
[ 103.850331] nl80211_disconnect+0x6e/0xb0 [cfg80211]
[ 103.850422] genl_family_rcv_msg_doit+0xcd/0x110
[ 103.850430] genl_rcv_msg+0xce/0x1c0
[ 103.850435] netlink_rcv_skb+0x50/0xf0
[ 103.850441] genl_rcv+0x24/0x40
[ 103.850446] netlink_unicast+0x16d/0x230
[ 103.850452] netlink_sendmsg+0x22b/0x450
[ 103.850457] sock_sendmsg+0x5e/0x60
[ 103.850465] ____sys_sendmsg+0x22f/0x270
[ 103.850472] ___sys_sendmsg+0x81/0xc0
[ 103.850479] __sys_sendmsg+0x49/0x80
[ 103.850485] do_syscall_64+0x3b/0x90
[ 103.850493] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 103.850500]
other info that might help us debug this:
[ 103.850504] Possible unsafe locking scenario:
[ 103.850507] CPU0 CPU1
[ 103.850510] ---- ----
[ 103.850512] lock(&pstapriv->sta_hash_lock);
[ 103.850518] lock(&pxmitpriv->lock);
[ 103.850524] lock(&pstapriv->sta_hash_lock);
[ 103.850530] lock(&pxmitpriv->lock);
[ 103.850535]
*** DEADLOCK ***
Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.
This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.
Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.
Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabio Aiuto [Mon, 20 Sep 2021 14:55:00 +0000 (16:55 +0200)]
staging: rtl8723bs: remove possible deadlock when disconnect (v2)
[ Upstream commit
54659ca026e586bbb33a7e60daa6443a3ac6b5df ]
when turning off a connection, lockdep complains with the
following warning (a modprobe has been done but the same
happens with a disconnection from NetworkManager,
it's enough to trigger a cfg80211_disconnect call):
[ 682.855867] ======================================================
[ 682.855877] WARNING: possible circular locking dependency detected
[ 682.855887] 5.14.0-rc6+ #16 Tainted: G C OE
[ 682.855898] ------------------------------------------------------
[ 682.855906] modprobe/1770 is trying to acquire lock:
[ 682.855916]
ffffb6d000332b00 (&pxmitpriv->lock){+.-.}-{2:2},
at: rtw_free_stainfo+0x52/0x4a0 [r8723bs]
[ 682.856073]
but task is already holding lock:
[ 682.856081]
ffffb6d0003336a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2},
at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[ 682.856207]
which lock already depends on the new lock.
[ 682.856215]
the existing dependency chain (in reverse order) is:
[ 682.856223]
-> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[ 682.856247] _raw_spin_lock_bh+0x34/0x40
[ 682.856265] rtw_get_stainfo+0x9a/0x110 [r8723bs]
[ 682.856389] rtw_xmit_classifier+0x27/0x130 [r8723bs]
[ 682.856515] rtw_xmitframe_enqueue+0xa/0x20 [r8723bs]
[ 682.856642] rtl8723bs_hal_xmit+0x3b/0xb0 [r8723bs]
[ 682.856752] rtw_xmit+0x4ef/0x890 [r8723bs]
[ 682.856879] _rtw_xmit_entry+0xba/0x350 [r8723bs]
[ 682.856981] dev_hard_start_xmit+0xee/0x320
[ 682.856999] sch_direct_xmit+0x8c/0x330
[ 682.857014] __dev_queue_xmit+0xba5/0xf00
[ 682.857030] packet_sendmsg+0x981/0x1b80
[ 682.857047] sock_sendmsg+0x5b/0x60
[ 682.857060] __sys_sendto+0xf1/0x160
[ 682.857073] __x64_sys_sendto+0x24/0x30
[ 682.857087] do_syscall_64+0x3a/0x80
[ 682.857102] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 682.857117]
-> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[ 682.857142] __lock_acquire+0xfd9/0x1b50
[ 682.857158] lock_acquire+0xb4/0x2c0
[ 682.857172] _raw_spin_lock_bh+0x34/0x40
[ 682.857185] rtw_free_stainfo+0x52/0x4a0 [r8723bs]
[ 682.857308] rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[ 682.857415] cfg80211_rtw_disconnect+0x4b/0x70 [r8723bs]
[ 682.857522] cfg80211_disconnect+0x12e/0x2f0 [cfg80211]
[ 682.857759] cfg80211_leave+0x2b/0x40 [cfg80211]
[ 682.857961] cfg80211_netdev_notifier_call+0xa9/0x560 [cfg80211]
[ 682.858163] raw_notifier_call_chain+0x41/0x50
[ 682.858180] __dev_close_many+0x62/0x100
[ 682.858195] dev_close_many+0x7d/0x120
[ 682.858209] unregister_netdevice_many+0x416/0x680
[ 682.858225] unregister_netdevice_queue+0xab/0xf0
[ 682.858240] unregister_netdev+0x18/0x20
[ 682.858255] rtw_unregister_netdevs+0x28/0x40 [r8723bs]
[ 682.858360] rtw_dev_remove+0x24/0xd0 [r8723bs]
[ 682.858463] sdio_bus_remove+0x31/0xd0 [mmc_core]
[ 682.858532] device_release_driver_internal+0xf7/0x1d0
[ 682.858550] driver_detach+0x47/0x90
[ 682.858564] bus_remove_driver+0x77/0xd0
[ 682.858579] rtw_drv_halt+0xc/0x678 [r8723bs]
[ 682.858685] __x64_sys_delete_module+0x13f/0x250
[ 682.858699] do_syscall_64+0x3a/0x80
[ 682.858715] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 682.858729]
other info that might help us debug this:
[ 682.858737] Possible unsafe locking scenario:
[ 682.858744] CPU0 CPU1
[ 682.858751] ---- ----
[ 682.858758] lock(&pstapriv->sta_hash_lock);
[ 682.858772] lock(&pxmitpriv->lock);
[ 682.858786] lock(&pstapriv->sta_hash_lock);
[ 682.858799] lock(&pxmitpriv->lock);
[ 682.858812]
*** DEADLOCK ***
[ 682.858820] 5 locks held by modprobe/1770:
[ 682.858831] #0:
ffff8d870697d980 (&dev->mutex){....}-{3:3},
at: device_release_driver_internal+0x1a/0x1d0
[ 682.858869] #1:
ffffffffbdbbf1c8 (rtnl_mutex){+.+.}-{3:3},
at: unregister_netdev+0xe/0x20
[ 682.858906] #2:
ffff8d87054ee5e8 (&rdev->wiphy.mtx){+.+.}-{3:3},
at: cfg80211_netdev_notifier_call+0x9e/0x560 [cfg80211]
[ 682.859131] #3:
ffff8d870f2bc8f0 (&wdev->mtx){+.+.}-{3:3},
at: cfg80211_leave+0x20/0x40 [cfg80211]
[ 682.859354] #4:
ffffb6d0003336a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2},
at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[ 682.859482]
stack backtrace:
[ 682.859491] CPU: 1 PID: 1770 Comm: modprobe Tainted: G
C OE 5.14.0-rc6+ #16
[ 682.859507] Hardware name: LENOVO 80NR/Madrid, BIOS DACN25WW 08/20/2015
[ 682.859517] Call Trace:
[ 682.859531] dump_stack_lvl+0x56/0x6f
[ 682.859551] check_noncircular+0xdb/0xf0
[ 682.859579] __lock_acquire+0xfd9/0x1b50
[ 682.859606] lock_acquire+0xb4/0x2c0
[ 682.859623] ? rtw_free_stainfo+0x52/0x4a0 [r8723bs]
[ 682.859752] ? mark_held_locks+0x48/0x70
[ 682.859769] ? rtw_free_stainfo+0x4a/0x4a0 [r8723bs]
[ 682.859898] _raw_spin_lock_bh+0x34/0x40
[ 682.859914] ? rtw_free_stainfo+0x52/0x4a0 [r8723bs]
[ 682.860039] rtw_free_stainfo+0x52/0x4a0 [r8723bs]
[ 682.860171] rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[ 682.860286] cfg80211_rtw_disconnect+0x4b/0x70 [r8723bs]
[ 682.860397] cfg80211_disconnect+0x12e/0x2f0 [cfg80211]
[ 682.860629] cfg80211_leave+0x2b/0x40 [cfg80211]
[ 682.860836] cfg80211_netdev_notifier_call+0xa9/0x560 [cfg80211]
[ 682.861048] ? __lock_acquire+0x4dc/0x1b50
[ 682.861070] ? lock_is_held_type+0xa8/0x110
[ 682.861089] ? lock_is_held_type+0xa8/0x110
[ 682.861104] ? find_held_lock+0x2d/0x90
[ 682.861120] ? packet_notifier+0x173/0x300
[ 682.861141] ? lock_release+0xb3/0x250
[ 682.861160] ? packet_notifier+0x192/0x300
[ 682.861184] raw_notifier_call_chain+0x41/0x50
[ 682.861205] __dev_close_many+0x62/0x100
[ 682.861224] dev_close_many+0x7d/0x120
[ 682.861245] unregister_netdevice_many+0x416/0x680
[ 682.861264] ? find_held_lock+0x2d/0x90
[ 682.861284] unregister_netdevice_queue+0xab/0xf0
[ 682.861306] unregister_netdev+0x18/0x20
[ 682.861325] rtw_unregister_netdevs+0x28/0x40 [r8723bs]
[ 682.861434] rtw_dev_remove+0x24/0xd0 [r8723bs]
[ 682.861542] sdio_bus_remove+0x31/0xd0 [mmc_core]
[ 682.861615] device_release_driver_internal+0xf7/0x1d0
[ 682.861637] driver_detach+0x47/0x90
[ 682.861656] bus_remove_driver+0x77/0xd0
[ 682.861674] rtw_drv_halt+0xc/0x678 [r8723bs]
[ 682.861782] __x64_sys_delete_module+0x13f/0x250
[ 682.861801] ? lockdep_hardirqs_on_prepare+0xf3/0x170
[ 682.861817] ? syscall_enter_from_user_mode+0x20/0x70
[ 682.861836] do_syscall_64+0x3a/0x80
[ 682.861855] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 682.861873] RIP: 0033:0x7f6dbe85400b
[ 682.861890] Code: 73 01 c3 48 8b 0d 6d 1e 0c 00 f7 d8 64 89
01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa
b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d
1e 0c 00 f7 d8 64 89 01 48
[ 682.861906] RSP: 002b:
00007ffe7a82f538 EFLAGS:
00000206 ORIG_RAX:
00000000000000b0
[ 682.861923] RAX:
ffffffffffffffda RBX:
000055a64693bd20 RCX:
00007f6dbe85400b
[ 682.861935] RDX:
0000000000000000 RSI:
0000000000000800 RDI:
000055a64693bd88
[ 682.861946] RBP:
000055a64693bd20 R08:
0000000000000000 R09:
0000000000000000
[ 682.861957] R10:
00007f6dbe8c7ac0 R11:
0000000000000206 R12:
000055a64693bd88
[ 682.861967] R13:
0000000000000000 R14:
000055a64693bd88 R15:
00007ffe7a831848
This happens because when we enqueue a frame for
transmission we do it under xmit_priv lock, then calling
rtw_get_stainfo (needed for enqueuing) takes sta_hash_lock
and this leads to the following lock dependency:
xmit_priv->lock -> sta_hash_lock
Turning off a connection will bring to call
rtw_free_assoc_resources which will set up
the inverse dependency:
sta_hash_lock -> xmit_priv_lock
This could lead to a deadlock as lockdep complains.
Fix it by removing the xmit_priv->lock around
rtw_xmitframe_enqueue call inside rtl8723bs_hal_xmit
and put it in a smaller critical section inside
rtw_xmit_classifier, the only place where
xmit_priv data are actually accessed.
Replace spin_{lock,unlock}_bh(pxmitpriv->lock)
in other tx paths leading to rtw_xmitframe_enqueue
call with spin_{lock,unlock}_bh(psta->sleep_q.lock)
- it's not clear why accessing a sleep_q was protected
by a spinlock on xmitpriv->lock.
This way is avoided the same faulty lock nesting
order.
Extra changes in v2 by Hans de Goede:
-Lift the taking of the struct __queue.lock spinlock out of
rtw_free_xmitframe_queue() into the callers this allows also
protecting a bunch of related state in rtw_free_stainfo():
-Protect psta->sleepq_len on rtw_free_xmitframe_queue(&psta->sleep_q);
-Protect struct tx_servq.tx_pending and tx_servq.qcnt when
calling rtw_free_xmitframe_queue(&tx_servq.sta_pending)
-This also allows moving the spin_lock_bh(&pxmitpriv->lock); to below
the sleep_q free-ing code, avoiding another ABBA locking issue
CC: Larry Finger <Larry.Finger@lwfinger.net>
Co-developed-by: Hans de Goede <hdegoede@redhat.com>
Tested-on: Lenovo Ideapad MiiX 300-10IBY
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Walleij [Thu, 3 Jun 2021 22:00:04 +0000 (00:00 +0200)]
ARM: dts: ux500: Skomer regulator fixes
[ Upstream commit
7aee0288beab72cdfa35af51f62e94373fca595d ]
AUX2 has slightly wrong voltage and AUX5 doesn't need to be
always on.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sven Peter [Tue, 14 Sep 2021 14:02:35 +0000 (16:02 +0200)]
usb: typec: tipd: Remove WARN_ON in tps6598x_block_read
[ Upstream commit
b7a0a63f3fed57d413bb857de164ea9c3984bc4e ]
Calling tps6598x_block_read with a higher than allowed len can be
handled by just returning an error. There's no need to crash systems
with panic-on-warn enabled.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Link: https://lore.kernel.org/r/20210914140235.65955-3-sven@svenpeter.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 15 Sep 2021 03:49:25 +0000 (11:49 +0800)]
usb: musb: tusb6010: check return value after calling platform_get_resource()
[ Upstream commit
14651496a3de6807a17c310f63c894ea0c5d858e ]
It will cause null-ptr-deref if platform_get_resource() returns NULL,
we need check the return value.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20210915034925.2399823-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Tue, 21 Sep 2021 09:42:25 +0000 (12:42 +0300)]
bus: ti-sysc: Use context lost quirk for otg
[ Upstream commit
9067839ff45a528bcb015cc2f24f656126b91e3f ]
Let's use SYSC_QUIRK_REINIT_ON_CTX_LOST quirk for am335x otg instead of
SYSC_QUIRK_REINIT_ON_RESUME quirk as we can now handle the context loss
in a more generic way.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Tue, 21 Sep 2021 09:42:25 +0000 (12:42 +0300)]
bus: ti-sysc: Add quirk handling for reinit on context lost
[ Upstream commit
9d881361206ebcf6285c2ec2ef275aff80875347 ]
Some interconnect target modules such as otg and gpmc on am335x need a
re-init after resume. As we also have PM runtime cases where the context
may be lost, let's handle these all with cpu_pm.
For the am335x resume path, we already have cpu_pm_resume() call
cpu_pm_cluster_exit().
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Selvin Xavier [Wed, 15 Sep 2021 12:32:42 +0000 (05:32 -0700)]
RDMA/bnxt_re: Check if the vlan is valid before reporting
[ Upstream commit
6bda39149d4b8920fdb8744090653aca3daa792d ]
When VF is configured with default vlan, HW strips the vlan from the
packet and driver receives it in Rx completion. VLAN needs to be reported
for UD work completion only if the vlan is configured on the host. Add a
check for valid vlan in the UD receive path.
Link: https://lore.kernel.org/r/1631709163-2287-12-git-send-email-selvin.xavier@broadcom.com
Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Walle [Mon, 30 Aug 2021 16:51:13 +0000 (18:51 +0200)]
arm64: dts: hisilicon: fix arm,sp805 compatible string
[ Upstream commit
894d4f1f77d0e88f1f81af2e1e37333c1c41b631 ]
According to Documentation/devicetree/bindings/watchdog/arm,sp805.yaml
the compatible is:
compatible = "arm,sp805", "arm,primecell";
The current compatible string doesn't exist at all. Fix it.
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthias Brugger [Thu, 15 Jul 2021 16:41:01 +0000 (18:41 +0200)]
arm64: dts: rockchip: Disable CDN DP on Pinebook Pro
[ Upstream commit
2513fa5c25d42f55ca5f0f0ab247af7c9fbfa3b1 ]
The CDN DP needs a PHY and a extcon to work correctly. But no extcon is
provided by the device-tree, which leads to an error:
cdn-dp
fec00000.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing extcon or phy
cdn-dp: probe of
fec00000.dp failed with error -22
Disable the CDN DP to make graphic work on the Pinebook Pro.
Reported-by: Guillaume Gardet <guillaume.gardet@arm.com>
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Link: https://lore.kernel.org/r/20210715164101.11486-1-matthias.bgg@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bixuan Cui [Sat, 11 Sep 2021 08:12:46 +0000 (16:12 +0800)]
ASoC: mediatek: mt8195: Add missing of_node_put()
[ Upstream commit
b2fc2c92d2fd34d93268f677e514936f50dd6b5c ]
The platform_node is returned by of_parse_phandle() should have
of_node_put() before return.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Link: https://lore.kernel.org/r/20210911081246.33867-1-cuibixuan@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Fri, 10 Sep 2021 23:31:46 +0000 (16:31 -0700)]
scsi: lpfc: Fix list_add() corruption in lpfc_drain_txq()
[ Upstream commit
99154581b05c8fb22607afb7c3d66c1bace6aa5d ]
When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass
the requests to the adapter. If such an attempt fails, a local "fail_msg"
string is set and a log message output. The job is then added to a
completions list for cancellation.
Processing of any further jobs from the txq list continues, but since
"fail_msg" remains set, jobs are added to the completions list regardless
of whether a wqe was passed to the adapter. If successfully added to
txcmplq, jobs are added to both lists resulting in list corruption.
Fix by clearing the fail_msg string after adding a job to the completions
list. This stops the subsequent jobs from being added to the completions
list unless they had an appropriate failure.
Link: https://lore.kernel.org/r/20210910233159.115896-2-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ajish Koshy [Mon, 6 Sep 2021 17:04:04 +0000 (22:34 +0530)]
scsi: pm80xx: Fix memory leak during rmmod
[ Upstream commit
51e6ed83bb4ade7c360551fa4ae55c4eacea354b ]
Driver failed to release all memory allocated. This would lead to memory
leak during driver removal.
Properly free memory when the module is removed.
Link: https://lore.kernel.org/r/20210906170404.5682-5-Ajish.Koshy@microchip.com
Acked-by: Jack Wang <jinpu.wang@ionos.com>
Signed-off-by: Ajish Koshy <Ajish.Koshy@microchip.com>
Signed-off-by: Viswas G <Viswas.G@microchip.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafał Miłecki [Thu, 19 Aug 2021 12:26:06 +0000 (14:26 +0200)]
arm64: dts: broadcom: bcm4908: Move reboot syscon out of bus
[ Upstream commit
6cf9f70255b90b540b9cbde062f18fea29024a75 ]
This fixes following error for every bcm4908 DTS file:
bus@
ff800000: reboot: {'type': 'object'} is not allowed for {'compatible': ['syscon-reboot'], 'regmap': [[15]], 'offset': [[52]], 'mask': [[1]]}
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthew Hagan [Sun, 29 Aug 2021 22:37:48 +0000 (22:37 +0000)]
ARM: dts: NSP: Fix mpcore, mmc node names
[ Upstream commit
15a563d008ef9d04df525f0c476cd7d7127bb883 ]
Running dtbs_check yielded the issues with bcm-nsp.dtsi.
Firstly this patch fixes the following message by appending "-bus" to
the mpcore node name:
mpcore@
19000000: $nodename:0: 'mpcore@
19000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Secondly mmc node name. The label name can remain as is.
sdhci@21000: $nodename:0: 'sdhci@21000' does not match '^mmc(@.*)?$'
Signed-off-by: Matthew Hagan <mnhagan88@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafał Miłecki [Thu, 19 Aug 2021 06:57:01 +0000 (08:57 +0200)]
ARM: dts: BCM5301X: Fix MDIO mux binding
[ Upstream commit
6ee0b56f7530e0ebb496fe15d0b54c5f3a1b5e17 ]
This fixes following error for all BCM5301X dts files:
mdio-bus-mux@
18003000: compatible: ['mdio-mux-mmioreg'] is too short
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafał Miłecki [Thu, 19 Aug 2021 06:57:00 +0000 (08:57 +0200)]
ARM: dts: BCM5301X: Fix nodes names
[ Upstream commit
9dba049b6d32e95c0dd2a0d607f593ea288ac140 ]
This fixes following errors for all BCM5301X dts files:
chipcommonA@
18000000: $nodename:0: 'chipcommonA@
18000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
mpcore@
19000000: $nodename:0: 'mpcore@
19000000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
mdio-bus-mux@
18003000: $nodename:0: 'mdio-bus-mux@
18003000' does not match '^mdio-mux[\\-@]?'
dmu@
1800c000: $nodename:0: 'dmu@
1800c000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jérôme Pouiller [Mon, 13 Sep 2021 13:02:03 +0000 (15:02 +0200)]
staging: wfx: ensure IRQ is ready before enabling it
[ Upstream commit
5e57c668dc097c6c27c973504706edec53f79281 ]
Since commit
5561770f80b1 ("staging: wfx: repair external IRQ for
SDIO"), wfx_sdio_irq_subscribe() enforce the device to use IRQs.
However, there is currently a race in this code. An IRQ may happen
before the IRQ has been registered.
The problem has observed during debug session when the device crashes
before the IRQ set up:
[ 1.546] wfx-sdio mmc0:0001:1: started firmware 3.12.2 "WF200_ASIC_WFM_(Jenkins)_FW3.12.2" (API: 3.7, keyset: C0, caps: 0x00000002)
[ 2.559] wfx-sdio mmc0:0001:1: time out while polling control register
[ 3.565] wfx-sdio mmc0:0001:1: chip is abnormally long to answer
[ 6.563] wfx-sdio mmc0:0001:1: chip did not answer
[ 6.568] wfx-sdio mmc0:0001:1: hardware request CONFIGURATION (0x09) on vif 2 returned error -110
[ 6.577] wfx-sdio mmc0:0001:1: PDS bytes 0 to 12: chip didn't reply (corrupted file?)
[ 6.585] Unable to handle kernel NULL pointer dereference at virtual address
00000000
[ 6.592] pgd =
c0004000
[ 6.595] [
00000000] *pgd=
00000000
[ 6.598] Internal error: Oops - BUG: 17 [#1] THUMB2
[ 6.603] Modules linked in:
[ 6.606] CPU: 0 PID: 23 Comm: kworker/u2:1 Not tainted 3.18.19 #78
[ 6.612] Workqueue: kmmcd mmc_rescan
[ 6.616] task:
c176d100 ti:
c0e50000 task.ti:
c0e50000
[ 6.621] PC is at wake_up_process+0xa/0x14
[ 6.625] LR is at sdio_irq+0x61/0x250
[ 6.629] pc : [<
c001e8ae>] lr : [<
c00ec5bd>] psr:
600001b3
[ 6.629] sp :
c0e51bd8 ip :
c0e51cc8 fp :
00000001
[ 6.640] r10:
00000003 r9 :
00000000 r8 :
c0003c34
[ 6.644] r7 :
c0e51bd8 r6 :
c0003c30 r5 :
00000001 r4 :
c0e78c00
[ 6.651] r3 :
00000000 r2 :
00000000 r1 :
00000003 r0 :
00000000
[ 6.657] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment kernel
[ 6.664] Control:
50c53c7d Table:
11fd8059 DAC:
00000015
[ 6.670] Process kworker/u2:1 (pid: 23, stack limit = 0xc0e501b0)
[ 6.676] Stack: (0xc0e51bd8 to 0xc0e52000)
[...]
[ 6.949] [<
c001e8ae>] (wake_up_process) from [<
c00ec5bd>] (sdio_irq+0x61/0x250)
[ 6.956] [<
c00ec5bd>] (sdio_irq) from [<
c0025099>] (handle_irq_event_percpu+0x17/0x92)
[ 6.964] [<
c0025099>] (handle_irq_event_percpu) from [<
c002512f>] (handle_irq_event+0x1b/0x24)
[ 6.973] [<
c002512f>] (handle_irq_event) from [<
c0026577>] (handle_level_irq+0x5d/0x76)
[ 6.981] [<
c0026577>] (handle_level_irq) from [<
c0024cc3>] (generic_handle_irq+0x13/0x1c)
[ 6.989] [<
c0024cc3>] (generic_handle_irq) from [<
c0024dd9>] (__handle_domain_irq+0x31/0x48)
[ 6.997] [<
c0024dd9>] (__handle_domain_irq) from [<
c0008359>] (ov_handle_irq+0x31/0xe0)
[ 7.005] [<
c0008359>] (ov_handle_irq) from [<
c000af5b>] (__irq_svc+0x3b/0x5c)
[ 7.013] Exception stack(0xc0e51c68 to 0xc0e51cb0)
[...]
[ 7.038] [<
c000af5b>] (__irq_svc) from [<
c01775aa>] (wait_for_common+0x9e/0xc4)
[ 7.045] [<
c01775aa>] (wait_for_common) from [<
c00e1dc3>] (mmc_wait_for_req+0x4b/0xdc)
[ 7.053] [<
c00e1dc3>] (mmc_wait_for_req) from [<
c00e1e83>] (mmc_wait_for_cmd+0x2f/0x34)
[ 7.061] [<
c00e1e83>] (mmc_wait_for_cmd) from [<
c00e7b2b>] (mmc_io_rw_direct_host+0x71/0xac)
[ 7.070] [<
c00e7b2b>] (mmc_io_rw_direct_host) from [<
c00e8f79>] (sdio_claim_irq+0x6b/0x116)
[ 7.078] [<
c00e8f79>] (sdio_claim_irq) from [<
c00d8415>] (wfx_sdio_irq_subscribe+0x19/0x94)
[ 7.086] [<
c00d8415>] (wfx_sdio_irq_subscribe) from [<
c00d5229>] (wfx_probe+0x189/0x2ac)
[ 7.095] [<
c00d5229>] (wfx_probe) from [<
c00d83bf>] (wfx_sdio_probe+0x8f/0xcc)
[ 7.102] [<
c00d83bf>] (wfx_sdio_probe) from [<
c00e7fbb>] (sdio_bus_probe+0x5f/0xa8)
[ 7.109] [<
c00e7fbb>] (sdio_bus_probe) from [<
c00be229>] (driver_probe_device+0x59/0x134)
[ 7.118] [<
c00be229>] (driver_probe_device) from [<
c00bd4d7>] (bus_for_each_drv+0x3f/0x4a)
[ 7.126] [<
c00bd4d7>] (bus_for_each_drv) from [<
c00be1a5>] (device_attach+0x3b/0x52)
[ 7.134] [<
c00be1a5>] (device_attach) from [<
c00bdc2b>] (bus_probe_device+0x17/0x4c)
[ 7.141] [<
c00bdc2b>] (bus_probe_device) from [<
c00bcd69>] (device_add+0x2c5/0x334)
[ 7.149] [<
c00bcd69>] (device_add) from [<
c00e80bf>] (sdio_add_func+0x23/0x44)
[ 7.156] [<
c00e80bf>] (sdio_add_func) from [<
c00e79eb>] (mmc_attach_sdio+0x187/0x1ec)
[ 7.164] [<
c00e79eb>] (mmc_attach_sdio) from [<
c00e31bd>] (mmc_rescan+0x18d/0x1fc)
[ 7.172] [<
c00e31bd>] (mmc_rescan) from [<
c001a14f>] (process_one_work+0xd7/0x170)
[ 7.179] [<
c001a14f>] (process_one_work) from [<
c001a59b>] (worker_thread+0x103/0x1bc)
[ 7.187] [<
c001a59b>] (worker_thread) from [<
c001c731>] (kthread+0x7d/0x90)
[ 7.194] [<
c001c731>] (kthread) from [<
c0008ce1>] (ret_from_fork+0x11/0x30)
[ 7.201] Code: 2103 b580 2200 af00 (681b) 46bd
[ 7.206] ---[ end trace
3ab50aced42eedb4 ]---
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Link: https://lore.kernel.org/r/20210913130203.1903622-33-Jerome.Pouiller@silabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Wed, 1 Sep 2021 09:18:49 +0000 (11:18 +0200)]
arm64: dts: allwinner: a100: Fix thermal zone node name
[ Upstream commit
5c34c4e46e601554bfa370b23c8ae3c3c734e9f7 ]
The thermal zones one the A100 are called $device-thermal-zone.
However, the thermal zone binding explicitly requires that zones are
called *-thermal. Let's fix it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20210901091852.479202-50-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Wed, 1 Sep 2021 09:18:47 +0000 (11:18 +0200)]
arm64: dts: allwinner: h5: Fix GPU thermal zone node name
[ Upstream commit
94a0f2b0e4e0953d8adf319c44244ef7a57de32c ]
The GPU thermal zone is named gpu_thermal. However, the underscore is
an invalid character for a node name and the thermal zone binding
explicitly requires that zones are called *-thermal. Let's fix it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20210901091852.479202-48-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxime Ripard [Wed, 1 Sep 2021 09:18:42 +0000 (11:18 +0200)]
ARM: dts: sunxi: Fix OPPs node name
[ Upstream commit
ffbe853a3f5a37fa0a511265b21abf097ffdbe45 ]
The operating-points-v2 nodes are named inconsistently, but mostly
either opp_table0 or gpu-opp-table. However, the underscore is an
invalid character for a node name and the thermal zone binding
explicitly requires that zones are called opp-table-*. Let's fix it.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20210901091852.479202-43-maxime@cerno.tech
Signed-off-by: Sasha Levin <sashal@kernel.org>
Samuel Holland [Wed, 1 Sep 2021 05:05:19 +0000 (00:05 -0500)]
clk: sunxi-ng: Unregister clocks/resets when unbinding
[ Upstream commit
9bec2b9c6134052994115d2d3374e96f2ccb9b9d ]
Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.
This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.
Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210901050526.45673-2-samuel@sholland.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Simek [Fri, 6 Aug 2021 08:58:29 +0000 (10:58 +0200)]
arm64: zynqmp: Fix serial compatible string
[ Upstream commit
812fa2f0e9d33564bd0131a69750e0d165f4c82a ]
Based on commit
65a2c14d4f00 ("dt-bindings: serial: convert Cadence UART
bindings to YAML") compatible string should look like differently that's
why fix it to be aligned with dt binding.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/89b36e0a6187cc6b05b27a035efdf79173bd4486.1628240307.git.michal.simek@xilinx.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amit Kumar Mahapatra [Mon, 14 Jun 2021 15:25:10 +0000 (17:25 +0200)]
arm64: zynqmp: Do not duplicate flash partition label property
[ Upstream commit
167721a5909f867f8c18c8e78ea58e705ad9bbd4 ]
In kernel 5.4, support has been added for reading MTD devices via the nvmem
API.
For this the mtd devices are registered as read-only NVMEM providers under
sysfs with the same name as the flash partition label property.
So if flash partition label property of multiple flash devices are
identical then the second mtd device fails to get registered as a NVMEM
provider.
This patch fixes the issue by having different label property for different
flashes.
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/6c4b9b9232b93d9e316a63c086540fd5bf6b8687.1623684253.git.michal.simek@xilinx.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Sun, 21 Nov 2021 12:44:15 +0000 (13:44 +0100)]
Linux 5.15.4
Link: https://lore.kernel.org/r/20211119171444.640508836@linuxfoundation.org
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-By: Scott Bruce <smbruce@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rafael J. Wysocki [Wed, 17 Nov 2021 16:05:41 +0000 (17:05 +0100)]
Revert "ACPI: scan: Release PM resources blocked by unused objects"
commit
3b2b49e6dfdcf423506a771bf44cee842596351a upstream.
Revert commit
c10383e8ddf4 ("ACPI: scan: Release PM resources blocked
by unused objects"), because it causes boot issues to appear on some
platforms.
Reported-by: Kyle D. Pelton <kyle.d.pelton@intel.com>
Reported-by: Saranya Gopal <saranya.gopal@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subbaraman Narayanamurthy [Thu, 4 Nov 2021 23:57:07 +0000 (16:57 -0700)]
thermal: Fix NULL pointer dereferences in of_thermal_ functions
commit
96cfe05051fd8543cdedd6807ec59a0e6c409195 upstream.
of_parse_thermal_zones() parses the thermal-zones node and registers a
thermal_zone device for each subnode. However, if a thermal zone is
consuming a thermal sensor and that thermal sensor device hasn't probed
yet, an attempt to set trip_point_*_temp for that thermal zone device
can cause a NULL pointer dereference. Fix it.
console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp
...
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000020
...
Call trace:
of_thermal_set_trip_temp+0x40/0xc4
trip_point_temp_store+0xc0/0x1dc
dev_attr_store+0x38/0x88
sysfs_kf_write+0x64/0xc0
kernfs_fop_write_iter+0x108/0x1d0
vfs_write+0x2f4/0x368
ksys_write+0x7c/0xec
__arm64_sys_write+0x20/0x30
el0_svc_common.llvm.
7279915941325364641+0xbc/0x1bc
do_el0_svc+0x28/0xa0
el0_svc+0x14/0x24
el0_sync_handler+0x88/0xec
el0_sync+0x1c0/0x200
While at it, fix the possible NULL pointer dereference in other
functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(),
of_thermal_get_trend().
Suggested-by: David Collins <quic_collinsd@quicinc.com>
Signed-off-by: Subbaraman Narayanamurthy <quic_subbaram@quicinc.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Thelen [Thu, 11 Nov 2021 02:18:14 +0000 (18:18 -0800)]
perf/core: Avoid put_page() when GUP fails
commit
4716023a8f6a0f4a28047f14dd7ebdc319606b84 upstream.
PEBS PERF_SAMPLE_PHYS_ADDR events use perf_virt_to_phys() to convert PMU
sampled virtual addresses to physical using get_user_page_fast_only()
and page_to_phys().
Some get_user_page_fast_only() error cases return false, indicating no
page reference, but still initialize the output page pointer with an
unreferenced page. In these error cases perf_virt_to_phys() calls
put_page(). This causes page reference count underflow, which can lead
to unintentional page sharing.
Fix perf_virt_to_phys() to only put_page() if get_user_page_fast_only()
returns a referenced page.
Fixes:
fc7ce9c74c3ad ("perf/core, x86: Add PERF_SAMPLE_PHYS_ADDR")
Signed-off-by: Greg Thelen <gthelen@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20211111021814.757086-1-gthelen@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 4 Nov 2021 18:01:30 +0000 (18:01 +0000)]
PCI: Add MSI masking quirk for Nvidia ION AHCI
commit
f21082fb20dbfb3e42b769b59ef21c2a7f2c7c1f upstream.
The ION AHCI device pretends that MSI masking isn't a thing, while it
actually implements it and needs MSIs to be unmasked to work. Add a quirk
to that effect.
Reported-by: Rui Salvaterra <rsalvaterra@gmail.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Rui Salvaterra <rsalvaterra@gmail.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <helgaas@kernel.org>
Link: https://lore.kernel.org/r/CALjTZvbzYfBuLB+H=fj2J+9=DxjQ2Uqcy0if_PvmJ-nU-qEgkg@mail.gmail.com
Link: https://lore.kernel.org/r/20211104180130.3825416-3-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 4 Nov 2021 18:01:29 +0000 (18:01 +0000)]
PCI/MSI: Deal with devices lying about their MSI mask capability
commit
2226667a145db2e1f314d7f57fd644fe69863ab9 upstream.
It appears that some devices are lying about their mask capability,
pretending that they don't have it, while they actually do.
The net result is that now that we don't enable MSIs on such
endpoint.
Add a new per-device flag to deal with this. Further patches will
make use of it, sadly.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20211104180130.3825416-2-maz@kernel.org
Cc: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sven Schnelle [Sat, 13 Nov 2021 19:41:17 +0000 (20:41 +0100)]
parisc/entry: fix trace test in syscall exit path
commit
3ec18fc7831e7d79e2d536dd1f3bc0d3ba425e8a upstream.
commit
8779e05ba8aa ("parisc: Fix ptrace check on syscall return")
fixed testing of TI_FLAGS. This uncovered a bug in the test mask.
syscall_restore_rfi is only used when the kernel needs to exit to
usespace with single or block stepping and the recovery counter
enabled. The test however used _TIF_SYSCALL_TRACE_MASK, which
includes a lot of bits that shouldn't be tested here.
Fix this by using TIF_SINGLESTEP and TIF_BLOCKSTEP directly.
I encountered this bug by enabling syscall tracepoints. Both in qemu and
on real hardware. As soon as i enabled the tracepoint (sys_exit_read,
but i guess it doesn't really matter which one), i got random page
faults in userspace almost immediately.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Flintham [Thu, 30 Sep 2021 08:22:39 +0000 (09:22 +0100)]
Bluetooth: btusb: Add support for TP-Link UB500 Adapter
commit
4fd6d490796171bf786090fee782e252186632e4 upstream.
Add support for TP-Link UB500 Adapter (RTL8761B)
* /sys/kernel/debug/usb/devices
T: Bus=01 Lev=02 Prnt=05 Port=01 Cnt=01 Dev#= 78 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2357 ProdID=0604 Rev= 2.00
S: Manufacturer=
S: Product=TP-Link UB500 Adapter
S: SerialNumber=
E848B8C82000
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Nicholas Flintham <nick@flinny.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Szabolcs Sipos <labuwx@balfug.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xie Yongji [Tue, 26 Oct 2021 14:40:14 +0000 (22:40 +0800)]
loop: Use blk_validate_block_size() to validate block size
commit
af3c570fb0df422b4906ebd11c1bf363d89961d5 upstream.
Remove loop_validate_block_size() and use the block layer helper
to validate block size.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Link: https://lore.kernel.org/r/20211026144015.188-4-xieyongji@bytedance.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xie Yongji [Tue, 26 Oct 2021 14:40:12 +0000 (22:40 +0800)]
block: Add a helper to validate the block size
commit
570b1cac477643cbf01a45fa5d018430a1fddbce upstream.
There are some duplicated codes to validate the block
size in block drivers. This limitation actually comes
from block layer, so this patch tries to add a new block
layer helper for that.
Signed-off-by: Xie Yongji <xieyongji@bytedance.com>
Link: https://lore.kernel.org/r/20211026144015.188-2-xieyongji@bytedance.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Cc: Tadeusz Struk <tadeusz.struk@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kees Cook [Thu, 13 May 2021 04:51:10 +0000 (21:51 -0700)]
fortify: Explicitly disable Clang support
commit
a52f8a59aef46b59753e583bf4b28fccb069ce64 upstream.
Clang has never correctly compiled the FORTIFY_SOURCE defenses due to
a couple bugs:
Eliding inlines with matching __builtin_* names
https://bugs.llvm.org/show_bug.cgi?id=50322
Incorrect __builtin_constant_p() of some globals
https://bugs.llvm.org/show_bug.cgi?id=41459
In the process of making improvements to the FORTIFY_SOURCE defenses, the
first (silent) bug (coincidentally) becomes worked around, but exposes
the latter which breaks the build. As such, Clang must not be used with
CONFIG_FORTIFY_SOURCE until at least latter bug is fixed (in Clang 13),
and the fortify routines have been rearranged.
Update the Kconfig to reflect the reality of the current situation.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com
Cc: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 18 Nov 2021 08:58:18 +0000 (17:58 +0900)]
btrfs: zoned: allow preallocation for relocation inodes
commit
960a3166aed015887cd54423a6589ae4d0b65bd5 upstream
Now that we use a dedicated block group and regular writes for data
relocation, we can preallocate the space needed for a relocated inode,
just like we do in regular mode.
Essentially this reverts commit
32430c614844 ("btrfs: zoned: enable
relocation on a zoned filesystem") as it is not needed anymore.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 18 Nov 2021 08:58:17 +0000 (17:58 +0900)]
btrfs: check for relocation inodes on zoned btrfs in should_nocow
commit
2adada886b26e998b5a624e72f0834ebfdc54cc7 upstream
Prepare for allowing preallocation for relocation inodes.
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 18 Nov 2021 08:58:16 +0000 (17:58 +0900)]
btrfs: zoned: use regular writes for relocation
commit
e6d261e3b1f777b499ce8f535ed44dd1b69278b7 upstream
Now that we have a dedicated block group for relocation, we can use
REQ_OP_WRITE instead of REQ_OP_ZONE_APPEND for writing out the data on
relocation.
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 18 Nov 2021 08:58:15 +0000 (17:58 +0900)]
btrfs: zoned: only allow one process to add pages to a relocation inode
commit
35156d852762b58855f513b4f8bb7f32d69dc9c5 upstream
Don't allow more than one process to add pages to a relocation inode on
a zoned filesystem, otherwise we cannot guarantee the sequential write
rule once we're filling preallocated extents on a zoned filesystem.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 18 Nov 2021 08:58:14 +0000 (17:58 +0900)]
btrfs: zoned: add a dedicated data relocation block group
commit
c2707a25562343511bf9a3a6a636a16a822204eb upstream
Relocation in a zoned filesystem can fail with a transaction abort with
error -22 (EINVAL). This happens because the relocation code assumes that
the extents we relocated the data to have the same size the source extents
had and ensures this by preallocating the extents.
But in a zoned filesystem we currently can't preallocate the extents as
this would break the sequential write required rule. Therefore it can
happen that the writeback process kicks in while we're still adding pages
to a delalloc range and starts writing out dirty pages.
This then creates destination extents that are smaller than the source
extents, triggering the following safety check in get_new_location():
1034 if (num_bytes != btrfs_file_extent_disk_num_bytes(leaf, fi)) {
1035 ret = -EINVAL;
1036 goto out;
1037 }
Temporarily create a dedicated block group for the relocation process, so
no non-relocation data writes can interfere with the relocation writes.
This is needed that we can switch the relocation process on a zoned
filesystem from the REQ_OP_ZONE_APPEND writing we use for data to a scheme
like in a non-zoned filesystem using REQ_OP_WRITE and preallocation.
Fixes:
32430c614844 ("btrfs: zoned: enable relocation on a zoned filesystem")
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 18 Nov 2021 08:58:13 +0000 (17:58 +0900)]
btrfs: introduce btrfs_is_data_reloc_root
commit
37f00a6d2e9c97d6e7b5c3d47c49b714c3d0b99f upstream
There are several places in our codebase where we check if a root is the
root of the data reloc tree and subsequent patches will introduce more.
Factor out the check into a small helper function instead of open coding
it multiple times.
Reviewed-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Woodhouse [Sun, 14 Nov 2021 08:59:02 +0000 (08:59 +0000)]
KVM: Fix steal time asm constraints
commit
964b7aa0b040bdc6ec1c543ee620cda3f8b4c68a upstream.
In 64-bit mode, x86 instruction encoding allows us to use the low 8 bits
of any GPR as an 8-bit operand. In 32-bit mode, however, we can only use
the [abcd] registers. For which, GCC has the "q" constraint instead of
the less restrictive "r".
Also fix st->preempted, which is an input/output operand rather than an
input.
Fixes:
7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <
89bf72db1b859990355f9c40713a34e0d2d86c98.camel@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 19 Nov 2021 11:30:13 +0000 (12:30 +0100)]
Revert "drm: fb_helper: fix CONFIG_FB dependency"
This reverts commit
c95380ba527ae0aee29b2a133c5d0c481d472759 which is
commit
606b102876e3741851dfb09d53f3ee57f650a52c upstream.
It causes some build problems as reported by Jiri.
Link: https://lore.kernel.org/r/9fdb2bf1-de52-1b9d-4783-c61ce39e8f51@kernel.org
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 19 Nov 2021 11:30:10 +0000 (12:30 +0100)]
Revert "drm: fb_helper: improve CONFIG_FB dependency"
This reverts commit
94e18f5a5dd1b5e3b89c665fc5ff780858b1c9f6 which is
commit
9d6366e743f37d36ef69347924ead7bcc596076e upstream.
It causes some build problems as reported by Jiri.
Link: https://lore.kernel.org/r/9fdb2bf1-de52-1b9d-4783-c61ce39e8f51@kernel.org
Reported-by: Jiri Slaby <jirislaby@kernel.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Tue, 2 Nov 2021 14:24:20 +0000 (07:24 -0700)]
string: uninline memcpy_and_pad
commit
5c4e0a21fae877a7ef89be6dcc6263ec672372b8 upstream.
When building m68k:allmodconfig, recent versions of gcc generate the
following error if the length of UTS_RELEASE is less than 8 bytes.
In function 'memcpy_and_pad',
inlined from 'nvmet_execute_disc_identify' at
drivers/nvme/target/discovery.c:268:2: arch/m68k/include/asm/string.h:72:25: error:
'__builtin_memcpy' reading 8 bytes from a region of size 7
Discussions around the problem suggest that this only happens if an
architecture does not provide strlen(), if -ffreestanding is provided as
compiler option, and if CONFIG_FORTIFY_SOURCE=n. All of this is the case
for m68k. The exact reasons are unknown, but seem to be related to the
ability of the compiler to evaluate the return value of strlen() and
the resulting execution flow in memcpy_and_pad(). It would be possible
to work around the problem by using sizeof(UTS_RELEASE) instead of
strlen(UTS_RELEASE), but that would only postpone the problem until the
function is called in a similar way. Uninline memcpy_and_pad() instead
to solve the problem for good.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 18 Nov 2021 18:17:21 +0000 (19:17 +0100)]
Linux 5.15.3
Link: https://lore.kernel.org/r/20211115165428.722074685@linuxfoundation.org
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Link: https://lore.kernel.org/r/20211116142631.571909964@linuxfoundation.org
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Fox Chen <foxhlchen@gmail.com>
Link: https://lore.kernel.org/r/20211117101657.463560063@linuxfoundation.org
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Link: https://lore.kernel.org/r/20211118081919.507743013@linuxfoundation.org
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-By: Scott Bruce <smbruce@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Mon, 1 Nov 2021 14:53:55 +0000 (14:53 +0000)]
media: videobuf2-dma-sg: Fix buf->vb NULL pointer dereference
commit
d55c3ee6b4c7b76326eb257403762f8bd7cc48c2 upstream.
Commit
a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API")
added a new vb member to struct vb2_dma_sg_buf, but it only added
code setting this to the vb2_dma_sg_alloc() function and not to the
vb2_dma_sg_get_userptr() and vb2_dma_sg_attach_dmabuf() which also
create vb2_dma_sg_buf objects.
This is causing a crash due to a NULL pointer deref when using
libcamera on devices with an Intel IPU3 (qcam app).
Fix these crashes by assigning buf->vb in the other 2 functions too,
note libcamera tests the vb2_dma_sg_get_userptr() path, the change
to the vb2_dma_sg_attach_dmabuf() path is untested.
Fixes:
a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API")
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergey Senozhatsky [Tue, 28 Sep 2021 03:46:34 +0000 (04:46 +0100)]
media: videobuf2: always set buffer vb2 pointer
commit
67f85135c57c8ea20b5417b28ae65e53dc2ec2c3 upstream.
We need to always link allocated vb2_dc_buf back to vb2_buffer because
we dereference vb2 in prepare() and finish() callbacks.
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Fri, 1 Oct 2021 19:41:20 +0000 (21:41 +0200)]
x86/sev: Make the #VC exception stacks part of the default stacks storage
commit
541ac97186d9ea88491961a46284de3603c914fd upstream.
The size of the exception stacks was increased by the commit in Fixes,
resulting in stack sizes greater than a page in size. The #VC exception
handling was only mapping the first (bottom) page, resulting in an
SEV-ES guest failing to boot.
Make the #VC exception stacks part of the default exception stacks
storage and allocate them with a CONFIG_AMD_MEM_ENCRYPT=y .config. Map
them only when a SEV-ES guest has been detected.
Rip out the custom VC stacks mapping and storage code.
[ bp: Steal and adapt Tom's commit message. ]
Fixes:
7fae4c24a2b8 ("x86: Increase exception stack sizes")
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Link: https://lkml.kernel.org/r/YVt1IMjIs7pIZTRR@zn.tnic
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Lendacky [Wed, 8 Sep 2021 22:58:34 +0000 (17:58 -0500)]
x86/sev: Add an x86 version of cc_platform_has()
commit
aa5a461171f98fde0df78c4f6b5018a1e967cf81 upstream.
Introduce an x86 version of the cc_platform_has() function. This will be
used to replace vendor specific calls like sme_active(), sev_active(),
etc.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210928191009.32551-4-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Lendacky [Wed, 8 Sep 2021 22:58:33 +0000 (17:58 -0500)]
arch/cc: Introduce a function to check for confidential computing features
commit
46b49b12f3fc5e1347dba37d4639e2165f447871 upstream.
In preparation for other confidential computing technologies, introduce
a generic helper function, cc_platform_has(), that can be used to
check for specific active confidential computing attributes, like
memory encryption. This is intended to eliminate having to add multiple
technology-specific checks to the code (e.g. if (sev_active() ||
tdx_active() || ... ).
[ bp: s/_CC_PLATFORM_H/_LINUX_CC_PLATFORM_H/g ]
Co-developed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Co-developed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210928191009.32551-3-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrii Nakryiko [Mon, 1 Nov 2021 23:01:18 +0000 (16:01 -0700)]
selftests/bpf: Fix also no-alu32 strobemeta selftest
commit
a20eac0af02810669e187cb623bc904908c423af upstream.
Previous fix aded bpf_clamp_umax() helper use to re-validate boundaries.
While that works correctly, it introduces more branches, which blows up
past 1 million instructions in no-alu32 variant of strobemeta selftests.
Switching len variable from u32 to u64 also fixes the issue and reduces
the number of validated instructions, so use that instead. Fix this
patch and bpf_clamp_umax() removed, both alu32 and no-alu32 selftests
pass.
Fixes:
0133c20480b1 ("selftests/bpf: Fix strobemeta selftest regression")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211101230118.1273019-1-andrii@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Fri, 29 Oct 2021 17:27:32 +0000 (19:27 +0200)]
selftests/x86/iopl: Adjust to the faked iopl CLI/STI usage
commit
a72fdfd21e01c626273ddcf5ab740d4caef4be54 upstream.
Commit in Fixes changed the iopl emulation to not #GP on CLI and STI
because it would break some insane luserspace tools which would toggle
interrupts.
The corresponding selftest would rely on the fact that executing CLI/STI
would trigger a #GP and thus detect it this way but since that #GP is
not happening anymore, the detection is now wrong too.
Extend the test to actually look at the IF flag and whether executing
those insns had any effect on it. The STI detection needs to have the
fact that interrupts were previously disabled, passed in so do that from
the previous CLI test, i.e., STI test needs to follow a previous CLI one
for it to make sense.
Fixes:
b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage")
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20211030083939.13073-1-bp@alien8.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Wed, 13 Oct 2021 10:00:52 +0000 (11:00 +0100)]
mmc: moxart: Fix null pointer dereference on pointer host
commit
0eab756f8821d255016c63bb55804c429ff4bdb1 upstream.
There are several error return paths that dereference the null pointer
host because the pointer has not yet been set to a valid value.
Fix this by adding a new out_mmc label and exiting via this label
to avoid the host clean up and hence the null pointer dereference.
Addresses-Coverity: ("Explicit null dereference")
Fixes:
8105c2abbf36 ("mmc: moxart: Fix reference count leaks in moxart_probe")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20211013100052.125461-1-colin.king@canonical.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Wed, 20 Oct 2021 08:59:07 +0000 (11:59 +0300)]
ath10k: fix invalid dma_addr_t token assignment
commit
937e79c67740d1d84736730d679f3cb2552f990e upstream.
Using a kernel pointer in place of a dma_addr_t token can
lead to undefined behavior if that makes it into cache
management functions. The compiler caught one such attempt
in a cast:
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface':
drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
5586 | arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf;
| ^
Looking through how this gets used down the way, I'm fairly
sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL
devices, and if it was accessed, that would be a bug.
Change the assignment to use a known-invalid address token
instead, which avoids the warning and makes it easier to catch
bugs if it does end up getting used.
Fixes:
e263bdab9c0e ("ath10k: high latency fixes for beacon buffer")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paulo Alcantara [Fri, 12 Nov 2021 17:53:36 +0000 (14:53 -0300)]
cifs: fix memory leak of smb3_fs_context_dup::server_hostname
commit
869da64d071142d4ed562a3e909deb18e4e72c4e upstream.
Fix memory leak of smb3_fs_context_dup::server_hostname when parsing
and duplicating fs contexts during mount(2) as reported by kmemleak:
unreferenced object 0xffff888125715c90 (size 16):
comm "mount.cifs", pid 3832, jiffies
4304535868 (age 190.094s)
hex dump (first 16 bytes):
7a 65 6c 64 61 2e 74 65 73 74 00 6b 6b 6b 6b a5 zelda.test.kkkk.
backtrace:
[<
ffffffff8168106e>] kstrdup+0x2e/0x60
[<
ffffffffa027a362>] smb3_fs_context_dup+0x392/0x8d0 [cifs]
[<
ffffffffa0136353>] cifs_smb3_do_mount+0x143/0x1700 [cifs]
[<
ffffffffa02795e8>] smb3_get_tree+0x2e8/0x520 [cifs]
[<
ffffffff817a19aa>] vfs_get_tree+0x8a/0x2d0
[<
ffffffff8181e3e3>] path_mount+0x423/0x1a10
[<
ffffffff8181fbca>] __x64_sys_mount+0x1fa/0x270
[<
ffffffff83ae364b>] do_syscall_64+0x3b/0x90
[<
ffffffff83c0007c>] entry_SYSCALL_64_after_hwframe+0x44/0xae
unreferenced object 0xffff888111deed20 (size 32):
comm "mount.cifs", pid 3832, jiffies
4304536044 (age 189.918s)
hex dump (first 32 bytes):
44 46 53 52 4f 4f 54 31 2e 5a 45 4c 44 41 2e 54 DFSROOT1.ZELDA.T
45 53 54 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 EST.kkkkkkkkkkk.
backtrace:
[<
ffffffff8168118d>] kstrndup+0x2d/0x90
[<
ffffffffa027ab2e>] smb3_parse_devname+0x9e/0x360 [cifs]
[<
ffffffffa01870c8>] cifs_setup_volume_info+0xa8/0x470 [cifs]
[<
ffffffffa018c469>] connect_dfs_target+0x309/0xc80 [cifs]
[<
ffffffffa018d6cb>] cifs_mount+0x8eb/0x17f0 [cifs]
[<
ffffffffa0136475>] cifs_smb3_do_mount+0x265/0x1700 [cifs]
[<
ffffffffa02795e8>] smb3_get_tree+0x2e8/0x520 [cifs]
[<
ffffffff817a19aa>] vfs_get_tree+0x8a/0x2d0
[<
ffffffff8181e3e3>] path_mount+0x423/0x1a10
[<
ffffffff8181fbca>] __x64_sys_mount+0x1fa/0x270
[<
ffffffff83ae364b>] do_syscall_64+0x3b/0x90
[<
ffffffff83c0007c>] entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes:
7be3248f3139 ("cifs: To match file servers, make sure the server hostname matches")
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Tue, 14 Sep 2021 07:21:25 +0000 (08:21 +0100)]
media: vidtv: move kfree(dvb) to vidtv_bridge_dev_release()
commit
112024a3b6dcfc62ec36ea0cf58b897f2ce54c59 upstream.
Adding kfree(dvb) to vidtv_bridge_remove() will remove the memory
too soon: if an application still has an open filehandle to the device
when the driver is unloaded, then when that filehandle is closed, a
use-after-free access takes place to the freed memory.
Move the kfree(dvb) to vidtv_bridge_dev_release() instead.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes:
76e21bb8be4f ("media: vidtv: Fix memory leak in remove")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Limonciello [Tue, 2 Nov 2021 15:04:37 +0000 (10:04 -0500)]
drm/amd/display: Look at firmware version to determine using dmub on dcn21
commit
91adec9e07097e538691daed5d934e7886dd1dc3 upstream.
commit
652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21
asics") switched over to using dmub on Renoir to fix Gitlab 1735, but this
implied a new dependency on newer firmware which might not be met on older
kernel versions.
Since sw_init runs before hw_init, there is an opportunity to determine
whether or not the firmware version is new to adjust the behavior.
Cc: Roman.Li@amd.com
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1772
BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1735
Fixes:
652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21 asics")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Roman Li <Roman.Li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Mon, 12 Jul 2021 13:52:59 +0000 (09:52 -0400)]
SUNRPC: Partial revert of commit
6f9f17287e78
commit
ea7a1019d8baf8503ecd6e3ec8436dec283569e6 upstream.
The premise of commit
6f9f17287e78 ("SUNRPC: Mitigate cond_resched() in
xprt_transmit()") was that cond_resched() is expensive and unnecessary
when there has been just a single send.
The point of cond_resched() is to ensure that tasks that should pre-empt
this one get a chance to do so when it is safe to do so. The code prior
to commit
6f9f17287e78 failed to take into account that it was keeping a
rpc_task pinned for longer than it needed to, and so rather than doing a
full revert, let's just move the cond_resched.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pali Rohár [Tue, 5 Oct 2021 18:09:41 +0000 (20:09 +0200)]
PCI: aardvark: Fix PCIe Max Payload Size setting
commit
a4e17d65dafdd3513042d8f00404c9b6068a825c upstream.
Change PCIe Max Payload Size setting in PCIe Device Control register to 512
bytes to align with PCIe Link Initialization sequence as defined in Marvell
Armada 3700 Functional Specification. According to the specification,
maximal Max Payload Size supported by this device is 512 bytes.
Without this kernel prints suspicious line:
pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 16384, max 512)
With this change it changes to:
pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 512, max 512)
Link: https://lore.kernel.org/r/20211005180952.6812-3-kabel@kernel.org
Fixes:
8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Marek Behún <kabel@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pali Rohár [Tue, 5 Oct 2021 18:09:40 +0000 (20:09 +0200)]
PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros
commit
460275f124fb072dca218a6b43b6370eebbab20d upstream.
Define a macro PCI_EXP_DEVCTL_PAYLOAD_* for every possible Max Payload
Size in linux/pci_regs.h, in the same style as PCI_EXP_DEVCTL_READRQ_*.
Link: https://lore.kernel.org/r/20211005180952.6812-2-kabel@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jernej Skrabec [Tue, 31 Aug 2021 18:48:19 +0000 (20:48 +0200)]
drm/sun4i: Fix macros in sun8i_csc.h
commit
c302c98da646409d657a473da202f10f417f3ff1 upstream.
Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
recommendation of having arguments enclosed in parenthesis. While that
didn't change anything for quite sometime, it actually become important
after CSC code rework with commit
ea067aee45a8 ("drm/sun4i: de2/de3:
Remove redundant CSC matrices").
Without this fix, colours are completely off for supported YVU formats
on SoCs with DE2 (A64, H3, R40, etc.).
Fix the issue by enclosing macro arguments in parenthesis.
Cc: stable@vger.kernel.org # 5.12+
Fixes:
883029390550 ("drm/sun4i: Add DE2 CSC library")
Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210831184819.93670-1-jernej.skrabec@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xiaoming Ni [Wed, 29 Sep 2021 03:36:46 +0000 (11:36 +0800)]
powerpc/85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n
commit
c45361abb9185b1e172bd75eff51ad5f601ccae4 upstream.
When CONFIG_SMP=y, timebase synchronization is required when the second
kernel is started.
arch/powerpc/kernel/smp.c:
int __cpu_up(unsigned int cpu, struct task_struct *tidle)
{
...
if (smp_ops->give_timebase)
smp_ops->give_timebase();
...
}
void start_secondary(void *unused)
{
...
if (smp_ops->take_timebase)
smp_ops->take_timebase();
...
}
When CONFIG_HOTPLUG_CPU=n and CONFIG_KEXEC_CORE=n,
smp_85xx_ops.give_timebase is NULL,
smp_85xx_ops.take_timebase is NULL,
As a result, the timebase is not synchronized.
Timebase synchronization does not depend on CONFIG_HOTPLUG_CPU.
Fixes:
56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations")
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210929033646.39630-3-nixiaoming@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nathan Lynch [Wed, 20 Oct 2021 19:47:03 +0000 (14:47 -0500)]
powerpc/pseries/mobility: ignore ibm, platform-facilities updates
commit
319fa1a52e438a6e028329187783a25ad498c4e6 upstream.
On VMs with NX encryption, compression, and/or RNG offload, these
capabilities are described by nodes in the ibm,platform-facilities device
tree hierarchy:
$ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
/sys/firmware/devicetree/base/ibm,platform-facilities/
├── ibm,compression-v1
├── ibm,random-v1
└── ibm,sym-encryption-v1
3 directories
The acceleration functions that these nodes describe are not disrupted by
live migration, not even temporarily.
But the post-migration ibm,update-nodes sequence firmware always sends
"delete" messages for this hierarchy, followed by an "add" directive to
reconstruct it via ibm,configure-connector (log with debugging statements
enabled in mobility.c):
mobility: removing node /ibm,platform-facilities/ibm,random-v1:
4294967285
mobility: removing node /ibm,platform-facilities/ibm,compression-v1:
4294967284
mobility: removing node /ibm,platform-facilities/ibm,sym-encryption-v1:
4294967283
mobility: removing node /ibm,platform-facilities:
4294967286
...
mobility: added node /ibm,platform-facilities:
4294967286
Note we receive a single "add" message for the entire hierarchy, and what
we receive from the ibm,configure-connector sequence is the top-level
platform-facilities node along with its three children. The debug message
simply reports the parent node and not the whole subtree.
Also, significantly, the nodes added are almost completely equivalent to
the ones removed; even phandles are unchanged. ibm,shared-interrupt-pool in
the leaf nodes is the only property I've observed to differ, and Linux does
not use that. So in practice, the sum of update messages Linux receives for
this hierarchy is equivalent to minor property updates.
We succeed in removing the original hierarchy from the device tree. But the
vio bus code is ignorant of this, and does not unbind or relinquish its
references. The leaf nodes, still reachable through sysfs, of course still
refer to the now-freed ibm,platform-facilities parent node, which makes
use-after-free possible:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 3 PID: 1706 at lib/refcount.c:25 refcount_warn_saturate+0x164/0x1f0
refcount_warn_saturate+0x160/0x1f0 (unreliable)
kobject_get+0xf0/0x100
of_node_get+0x30/0x50
of_get_parent+0x50/0xb0
of_fwnode_get_parent+0x54/0x90
fwnode_count_parents+0x50/0x150
fwnode_full_name_string+0x30/0x110
device_node_string+0x49c/0x790
vsnprintf+0x1c0/0x4c0
sprintf+0x44/0x60
devspec_show+0x34/0x50
dev_attr_show+0x40/0xa0
sysfs_kf_seq_show+0xbc/0x200
kernfs_seq_show+0x44/0x60
seq_read_iter+0x2a4/0x740
kernfs_fop_read_iter+0x254/0x2e0
new_sync_read+0x120/0x190
vfs_read+0x1d0/0x240
Moreover, the "new" replacement subtree is not correctly added to the
device tree, resulting in ibm,platform-facilities parent node without the
appropriate leaf nodes, and broken symlinks in the sysfs device hierarchy:
$ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/
/sys/firmware/devicetree/base/ibm,platform-facilities/
0 directories
$ cd /sys/devices/vio ; find . -xtype l -exec file {} +
./ibm,sym-encryption-v1/of_node: broken symbolic link to
../../../firmware/devicetree/base/ibm,platform-facilities/ibm,sym-encryption-v1
./ibm,random-v1/of_node: broken symbolic link to
../../../firmware/devicetree/base/ibm,platform-facilities/ibm,random-v1
./ibm,compression-v1/of_node: broken symbolic link to
../../../firmware/devicetree/base/ibm,platform-facilities/ibm,compression-v1
This is because add_dt_node() -> dlpar_attach_node() attaches only the
parent node returned from configure-connector, ignoring any children. This
should be corrected for the general case, but fixing that won't help with
the stale OF node references, which is the more urgent problem.
One way to address that would be to make the drivers respond to node
removal notifications, so that node references can be dropped
appropriately. But this would likely force the drivers to disrupt active
clients for no useful purpose: equivalent nodes are immediately re-added.
And recall that the acceleration capabilities described by the nodes remain
available throughout the whole process.
The solution I believe to be robust for this situation is to convert
remove+add of a node with an unchanged phandle to an update of the node's
properties in the Linux device tree structure. That would involve changing
and adding a fair amount of code, and may take several iterations to land.
Until that can be realized we have a confirmed use-after-free and the
possibility of memory corruption. So add a limited workaround that
discriminates on the node type, ignoring adds and removes. This should be
amenable to backporting in the meantime.
Fixes:
410bccf97881 ("powerpc/pseries: Partition migration in the kernel")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211020194703.2613093-1-nathanl@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Piggin [Tue, 26 Oct 2021 12:25:31 +0000 (22:25 +1000)]
powerpc/64s/interrupt: Fix check_return_regs_valid() false positive
commit
4a5cb51f3db4be547225a4bce7a43d41b231382b upstream.
The check_return_regs_valid() can cause a false positive if the return
regs are marked as norestart and they are an HSRR type interrupt,
because the low bit in the bottom of regs->trap causes interrupt type
matching to fail.
This can occcur for example on bare metal with a HV privileged doorbell
interrupt that causes a signal, but do_signal returns early because
get_signal() fails, and takes the "No signal to deliver" path. In this
case no signal was delivered so the return location is not changed so
return SRRs are not invalidated, yet set_trap_norestart is called, which
messes up the match. Building go-1.16.6 is known to reproduce this.
Fix it by using the TRAP() accessor which masks out the low bit.
Fixes:
6eaaf9de3599 ("powerpc/64s/interrupt: Check and fix srr_valid without crashing")
Cc: stable@vger.kernel.org # v5.14+
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211026122531.3599918-1-npiggin@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell Currey [Wed, 27 Oct 2021 07:24:10 +0000 (17:24 +1000)]
powerpc/security: Use a mutex for interrupt exit code patching
commit
3c12b4df8d5e026345a19886ae375b3ebc33c0b6 upstream.
The mitigation-patching.sh script in the powerpc selftests toggles
all mitigations on and off simultaneously, revealing that rfi_flush
and stf_barrier cannot safely operate at the same time due to races
in updating the static key.
On some systems, the static key code throws a warning and the kernel
remains functional. On others, the kernel will hang or crash.
Fix this by slapping on a mutex.
Fixes:
13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt")
Cc: stable@vger.kernel.org # v5.14+
Signed-off-by: Russell Currey <ruscur@russell.cc>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20211027072410.40950-1-ruscur@russell.cc
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>