Greg Kroah-Hartman [Thu, 2 Feb 2023 14:10:09 +0000 (15:10 +0100)]
scsi: snic: Fix memory leak with using debugfs_lookup()
[ Upstream commit
ad0e4e2fab928477f74d742e6e77d79245d3d3e7 ]
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic at
once.
Link: https://lore.kernel.org/r/20230202141009.2290380-1-gregkh@linuxfoundation.org
Cc: Karan Tilak Kumar <kartilak@cisco.com>
Cc: Sesidhar Baddela <sebaddel@cisco.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wesley Chalmers [Fri, 4 Nov 2022 19:19:22 +0000 (15:19 -0400)]
drm/amd/display: Do not commit pipe when updating DRR
[ Upstream commit
8f0d304d21b351d65e8c434c5399a40231876ba1 ]
[WHY]
DRR and Pipe cannot be updated on
the same frame, or else underflow will
occur.
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com>
Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Claudiu Beznea [Fri, 3 Feb 2023 13:27:14 +0000 (15:27 +0200)]
pinctrl: at91: use devm_kasprintf() to avoid potential leaks
[ Upstream commit
1c4e5c470a56f7f7c649c0c70e603abc1eab15c4 ]
Use devm_kasprintf() instead of kasprintf() to avoid any potential
leaks. At the moment drivers have no remove functionality thus
there is no need for fixes tag.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230203132714.1931596-1-claudiu.beznea@microchip.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Denis Pauk [Wed, 11 Jan 2023 21:22:41 +0000 (23:22 +0200)]
hwmon: (nct6775) B650/B660/X670 ASUS boards support
[ Upstream commit
e2e09989ccc21ad428d6393450add78584b143bd ]
Boards such as:
"EX-B660M-V5 PRO D4",
"PRIME B650-PLUS",
"PRIME B650M-A",
"PRIME B650M-A AX",
"PRIME B650M-A II",
"PRIME B650M-A WIFI",
"PRIME B650M-A WIFI II",
"PRIME B660M-A D4",
"PRIME B660M-A WIFI D4",
"PRIME X670-P",
"PRIME X670-P WIFI",
"PRIME X670E-PRO WIFI",
"Pro B660M-C-D4",
"ProArt B660-CREATOR D4",
"ProArt X670E-CREATOR WIFI",
"ROG CROSSHAIR X670E EXTREME",
"ROG CROSSHAIR X670E GENE",
"ROG CROSSHAIR X670E HERO",
"ROG MAXIMUS XIII EXTREME GLACIAL",
"ROG MAXIMUS Z690 EXTREME",
"ROG MAXIMUS Z690 EXTREME GLACIAL",
"ROG STRIX B650-A GAMING WIFI",
"ROG STRIX B650E-E GAMING WIFI",
"ROG STRIX B650E-F GAMING WIFI",
"ROG STRIX B650E-I GAMING WIFI",
"ROG STRIX B660-A GAMING WIFI D4",
"ROG STRIX B660-F GAMING WIFI",
"ROG STRIX B660-G GAMING WIFI",
"ROG STRIX B660-I GAMING WIFI",
"ROG STRIX X670E-A GAMING WIFI",
"ROG STRIX X670E-E GAMING WIFI",
"ROG STRIX X670E-F GAMING WIFI",
"ROG STRIX X670E-I GAMING WIFI",
"ROG STRIX Z590-A GAMING WIFI II",
"ROG STRIX Z690-A GAMING WIFI D4",
"TUF GAMING B650-PLUS",
"TUF GAMING B650-PLUS WIFI",
"TUF GAMING B650M-PLUS",
"TUF GAMING B650M-PLUS WIFI",
"TUF GAMING B660M-PLUS WIFI",
"TUF GAMING X670E-PLUS",
"TUF GAMING X670E-PLUS WIFI",
"TUF GAMING Z590-PLUS WIFI",
have got a NCT6799D chip, but by default there's no use of it
because of resource conflict with WMI method.
This commit adds such boards to the monitoring list with new ACPI device
UID.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Co-developed-by: Ahmad Khalifa <ahmad@khalifa.ws>
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Tested-by: Jeroen Beerstra <jeroen@beerstra.org>
Tested-by: Slawomir Stepien <sst@poczta.fm>
Link: https://lore.kernel.org/r/20230111212241.7456-2-pauk.denis@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Denis Pauk [Wed, 11 Jan 2023 21:22:40 +0000 (23:22 +0200)]
hwmon: (nct6775) Directly call ASUS ACPI WMI method
[ Upstream commit
c3b3747d02f571da2543e719066a50dd966989d8 ]
New ASUS B650/B660/X670 boards firmware have not exposed WMI monitoring
GUID and entrypoint method WMBD could be implemented for different device
UID.
Implement the direct call to entrypoint method for monitoring the device
UID of B550/X570 boards.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204807
Signed-off-by: Denis Pauk <pauk.denis@gmail.com>
Co-developed-by: Ahmad Khalifa <ahmad@khalifa.ws>
Signed-off-by: Ahmad Khalifa <ahmad@khalifa.ws>
Link: https://lore.kernel.org/r/20230111212241.7456-1-pauk.denis@gmail.com
[groeck: Fix multi-line formatting]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robin Murphy [Tue, 3 Jan 2023 11:46:20 +0000 (12:46 +0100)]
hwmon: (coretemp) Simplify platform device handling
[ Upstream commit
6d03bbff456befeccdd4d663177c4d6c75d0c4ff ]
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andreas Gruenbacher [Tue, 31 Jan 2023 14:06:53 +0000 (15:06 +0100)]
gfs2: Improve gfs2_make_fs_rw error handling
[ Upstream commit
b66f723bb552ad59c2acb5d45ea45c890f84498b ]
In gfs2_make_fs_rw(), make sure to call gfs2_consist() to report an
inconsistency and mark the filesystem as withdrawn when
gfs2_find_jhead() fails.
At the end of gfs2_make_fs_rw(), when we discover that the filesystem
has been withdrawn, make sure we report an error. This also replaces
the gfs2_withdrawn() check after gfs2_find_jhead().
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: syzbot+f51cb4b9afbd87ec06f2@syzkaller.appspotmail.com
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vladimir Stempen [Tue, 17 Jan 2023 19:14:42 +0000 (14:14 -0500)]
drm/amd/display: fix FCLK pstate change underflow
[ Upstream commit
972243f973eb0821084e5833d5f7f4ed025f42da ]
[Why]
Currently we set FCLK p-state change
watermark calculated based on dummy
p-state latency when UCLK p-state is
not supported
[How]
Calculate FCLK p-state change watermark
based on on FCLK pstate change latency
in case UCLK p-state is not supported
Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com>
Acked-by: Alex Hung <alex.hung@amd.com>
Signed-off-by: Vladimir Stempen <vladimir.stempen@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vitaly Prosyak [Fri, 20 Jan 2023 18:19:50 +0000 (13:19 -0500)]
Revert "drm/amdgpu: TA unload messages are not actually sent to psp when amdgpu is uninstalled"
[ Upstream commit
39934d3ed5725c5e3570ed1b67f612f1ea60ce03 ]
This reverts commit
fac53471d0ea9693d314aa2df08d62b2e7e3a0f8.
The following change: move the drm_dev_unplug call after
amdgpu_driver_unload_kms in amdgpu_pci_remove. The reason is
the following: amdgpu_pci_remove calls drm_dev_unregister
and it should be called first to ensure userspace can't access the
device instance anymore. If we call drm_dev_unplug after
amdgpu_driver_unload_kms then we observe IGT PCI software unplug
test failure (kernel hung) for all ASICs. This is how this
regression was found.
After this revert, the following commands do work not, but it would
be fixed in the next commit:
- sudo modprobe -r amdgpu
- sudo modprobe amdgpu
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Sat, 28 Jan 2023 00:53:58 +0000 (16:53 -0800)]
regulator: s5m8767: Bounds check id indexing into arrays
[ Upstream commit
e314e15a0b58f9d051c00b25951073bcdae61953 ]
The compiler has no way to know if "id" is within the array bounds of
the regulators array. Add a check for this and a build-time check that
the regulators and reg_voltage_map arrays are sized the same. Seen with
GCC 13:
../drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
../drivers/regulator/s5m8767.c:936:35: warning: array subscript [0, 36] is outside array bounds of 'struct regulator_desc[37]' [-Warray-bounds=]
936 | regulators[id].vsel_reg =
| ~~~~~~~~~~^~~~
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230128005358.never.313-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Fri, 27 Jan 2023 22:52:07 +0000 (14:52 -0800)]
regulator: max77802: Bounds check regulator id against opmode
[ Upstream commit
4fd8bcec5fd7c0d586206fa2f42bd67b06cdaa7e ]
Explicitly bounds-check the id before accessing the opmode array. Seen
with GCC 13:
../drivers/regulator/max77802-regulator.c: In function 'max77802_enable':
../drivers/regulator/max77802-regulator.c:217:29: warning: array subscript [0, 41] is outside array bounds of 'unsigned int[42]' [-Warray-bounds=]
217 | if (max77802->opmode[id] == MAX77802_OFF_PWRREQ)
| ~~~~~~~~~~~~~~~~^~~~
../drivers/regulator/max77802-regulator.c:62:22: note: while referencing 'opmode'
62 | unsigned int opmode[MAX77802_REG_MAX];
| ^~~~~~
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230127225203.never.864-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Fri, 27 Jan 2023 22:41:29 +0000 (14:41 -0800)]
ASoC: kirkwood: Iterate over array indexes instead of using pointer math
[ Upstream commit
b3bcedc0402fcdc5c8624c433562d9d1882749d8 ]
Walking the dram->cs array was seen as accesses beyond the first array
item by the compiler. Instead, use the array index directly. This allows
for run-time bounds checking under CONFIG_UBSAN_BOUNDS as well. Seen
with GCC 13 with -fstrict-flex-arrays:
../sound/soc/kirkwood/kirkwood-dma.c: In function
'kirkwood_dma_conf_mbus_windows.constprop':
../sound/soc/kirkwood/kirkwood-dma.c:90:24: warning: array subscript 0 is outside array bounds of 'const struct mbus_dram_window[0]' [-Warray-bounds=]
90 | if ((cs->base & 0xffff0000) < (dma & 0xffff0000)) {
| ~~^~~~~~
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: alsa-devel@alsa-project.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230127224128.never.410-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
강신형 [Thu, 8 Dec 2022 05:18:18 +0000 (14:18 +0900)]
ASoC: soc-compress: Reposition and add pcm_mutex
[ Upstream commit
aa9ff6a4955fdba02b54fbc4386db876603703b7 ]
If panic_on_warn is set and compress stream(DPCM) is started,
then kernel panic occurred because card->pcm_mutex isn't held appropriately.
In the following functions, warning were issued at this line
"snd_soc_dpcm_mutex_assert_held".
static int dpcm_be_connect(struct snd_soc_pcm_runtime *fe,
struct snd_soc_pcm_runtime *be, int stream)
{
...
snd_soc_dpcm_mutex_assert_held(fe);
...
}
void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream)
{
...
snd_soc_dpcm_mutex_assert_held(fe);
...
}
void snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd,
int stream, int action)
{
...
snd_soc_dpcm_mutex_assert_held(rtd);
...
}
int dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,
int event)
{
...
snd_soc_dpcm_mutex_assert_held(fe);
...
}
These functions are called by soc_compr_set_params_fe, soc_compr_open_fe
and soc_compr_free_fe
without pcm_mutex locking. And this is call stack.
[ 414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750
[ 414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750
[ 414.527945][ T2179] Call trace:
[ 414.527949][ T2179] dpcm_process_paths+0x5a4/0x750
[ 414.527955][ T2179] soc_compr_open_fe+0xb0/0x2cc
[ 414.527972][ T2179] snd_compr_open+0x180/0x248
[ 414.527981][ T2179] snd_open+0x15c/0x194
[ 414.528003][ T2179] chrdev_open+0x1b0/0x220
[ 414.528023][ T2179] do_dentry_open+0x30c/0x594
[ 414.528045][ T2179] vfs_open+0x34/0x44
[ 414.528053][ T2179] path_openat+0x914/0xb08
[ 414.528062][ T2179] do_filp_open+0xc0/0x170
[ 414.528068][ T2179] do_sys_openat2+0x94/0x18c
[ 414.528076][ T2179] __arm64_sys_openat+0x78/0xa4
[ 414.528084][ T2179] invoke_syscall+0x48/0x10c
[ 414.528094][ T2179] el0_svc_common+0xbc/0x104
[ 414.528099][ T2179] do_el0_svc+0x34/0xd8
[ 414.528103][ T2179] el0_svc+0x34/0xc4
[ 414.528125][ T2179] el0t_64_sync_handler+0x8c/0xfc
[ 414.528133][ T2179] el0t_64_sync+0x1a0/0x1a4
[ 414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ...
So, I reposition and add pcm_mutex to resolve lockdep error.
Signed-off-by: Shinhyung Kang <s47.kang@samsung.com>
Link: https://lore.kernel.org/r/016401d90ac4$7b6848c0$7238da40$@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marijn Suijten [Wed, 25 Jan 2023 10:14:11 +0000 (11:14 +0100)]
drm/msm/dpu: Add DSC hardware blocks to register snapshot
[ Upstream commit
a7efe60e36b9c0e966d7f82ac90a89b591d984e9 ]
Add missing DSC hardware block register ranges to the snapshot utility
to include them in dmesg (on MSM_DISP_SNAPSHOT_DUMP_IN_CONSOLE) and the
kms debugfs file.
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/520175/
Link: https://lore.kernel.org/r/20230125101412.216924-1-marijn.suijten@somainline.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakob Koschel [Thu, 19 Jan 2023 23:23:20 +0000 (00:23 +0100)]
docs/scripts/gdb: add necessary make scripts_gdb step
[ Upstream commit
6b219431037bf98c9efd49716aea9b68440477a3 ]
In order to debug the kernel successfully with gdb you need to run
'make scripts_gdb' nowadays.
This was changed with the following commit:
Commit
67274c083438340ad16c ("scripts/gdb: delay generation of gdb
constants.py")
In order to have a complete guide for beginners this remark
should be added to the offial documentation.
Signed-off-by: Jakob Koschel <jkl820.git@gmail.com>
Link: https://lore.kernel.org/r/20230112-documentation-gdb-v2-1-292785c43dc9@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
farah kassabri [Tue, 10 Jan 2023 10:29:55 +0000 (12:29 +0200)]
habanalabs: fix bug in timestamps registration code
[ Upstream commit
ac5af9900f82b7034de7c9eb1d70d030ba325607 ]
Protect re-using the same timestamp buffer record before actually
adding it to the to interrupt wait list.
Mark ts buff offset as in use in the spinlock protection area of the
interrupt wait list to avoid getting in the re-use section in
ts_buff_get_kernel_ts_record before adding the node to the list.
this scenario might happen when multiple threads are racing on
same offset and one thread could set data in the ts buff in
ts_buff_get_kernel_ts_record then the other thread takes over
and get to ts_buff_get_kernel_ts_record and we will try
to re-use the same ts buff offset then we will try to
delete a non existing node from the list.
Signed-off-by: farah kassabri <fkassabri@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Moti Haimovski [Thu, 29 Dec 2022 10:44:09 +0000 (12:44 +0200)]
habanalabs: extend fatal messages to contain PCI info
[ Upstream commit
2a0a839b6a28f7c4c528bb75b740c7f38ef79a37 ]
This commit attaches the PCI device address to driver fatal messages
in order to ease debugging in multi-device setups.
Signed-off-by: Moti Haimovski <mhaimovski@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Roman Li [Thu, 5 Jan 2023 22:44:10 +0000 (17:44 -0500)]
drm/amd/display: Set hvm_enabled flag for S/G mode
[ Upstream commit
40e9f3f067bc6fb47b878f8ba0a9cc7b93abbf49 ]
[Why]
After enabling S/G on dcn314 a screen corruption may be observed.
HostVM flag should be set in S/G mode to be included in DML calculations.
[How]
In S/G mode gpu_vm_support flag is set.
Use its value to init is_hvm_enabled.
Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Alan Liu <HaoPing.Liu@amd.com>
Signed-off-by: Roman Li <roman.li@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wayne Lin [Fri, 23 Dec 2022 01:57:02 +0000 (09:57 +0800)]
drm/drm_print: correct format problem
[ Upstream commit
d987150b539271b0394f24c1c648d2846662adb4 ]
[why & how]
__drm_dbg() parameter set format is wrong and not aligned with the
format under CONFIG_DRM_USE_DYNAMIC_DEBUG is on. Fix it.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomi Valkeinen [Mon, 23 Jan 2023 10:47:41 +0000 (12:47 +0200)]
drm: rcar-du: Fix setting a reserved bit in DPLLCR
[ Upstream commit
5fbc2f3b91d27e12b614947048764099570cbb55 ]
On H3 ES1.x two bits in DPLLCR are used to select the DU input dot clock
source. These are bits 20 and 21 for DU2, and bits 22 and 23 for DU1. On
non-ES1.x, only the higher bits are used (bits 21 and 23), and the lower
bits are reserved and should be set to 0.
The current code always sets the lower bits, even on non-ES1.x.
For both DU1 and DU2, on all SoC versions, when writing zeroes to those
bits the input clock is DCLKIN, and thus there's no difference between
ES1.x and non-ES1.x.
For DU1, writing 0b10 to the bits (or only writing the higher bit)
results in using PLL0 as the input clock, so in this case there's also
no difference between ES1.x and non-ES1.x.
However, for DU2, writing 0b10 to the bits results in using PLL0 as the
input clock on ES1.x, whereas on non-ES1.x it results in using PLL1. On
ES1.x you need to write 0b11 to select PLL1.
The current code always writes 0b11 to PLCS0 field to select PLL1 on all
SoC versions, which works but causes an illegal (in the sense of not
allowed by the documentation) write to a reserved bit field.
To remove the illegal bit write on PLSC0 we need to handle the input dot
clock selection differently for ES1.x and non-ES1.x.
Add a new quirk, RCAR_DU_QUIRK_H3_ES1_PLL, for this. This way we can
always set the bit 21 on PLSC0 when choosing the PLL as the source
clock, and additionally set the bit 20 when on ES1.x.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomi Valkeinen [Mon, 23 Jan 2023 10:47:40 +0000 (12:47 +0200)]
drm: rcar-du: Add quirk for H3 ES1.x pclk workaround
[ Upstream commit
4f548bc48a2b4c4e54eecfddb6f7d24aa1b98768 ]
rcar_du_crtc.c does a soc_device_match() in
rcar_du_crtc_set_display_timing() to find out if the SoC is H3 ES1.x, and
if so, apply a workaround.
We will need another H3 ES1.x check in the following patch, so rather than
adding more soc_device_match() calls, let's add a rcar_du_device_info
entry for the ES1, and a quirk flag,
RCAR_DU_QUIRK_H3_ES1_PCLK_STABILITY, for the workaround.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Tue, 10 Jan 2023 02:16:51 +0000 (10:16 +0800)]
drm/msm/dsi: Add missing check for alloc_ordered_workqueue
[ Upstream commit
115906ca7b535afb1fe7b5406c566ccd3873f82b ]
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference.
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/517646/
Link: https://lore.kernel.org/r/20230110021651.12770-1-jiasheng@iscas.ac.cn
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
José Expósito [Mon, 26 Dec 2022 12:54:54 +0000 (13:54 +0100)]
HID: uclogic: Add support for XP-PEN Deco Pro MW
[ Upstream commit
9266a88156d1fbb8e50d6eeff7bac44ad4eaecc2 ]
The XP-PEN Deco Pro MW is a UGEE v2 device with a frame with 8 buttons,
a bitmap dial and a mouse. Its pen has 2 buttons, supports tilt and
pressure.
It can be connected using a USB cable or, to use it in wireless mode,
using a USB Bluetooth dongle. When it is connected in wireless mode the
device battery is used to power it.
All the pieces to support it are already in place. Add its ID and
quirks in order to support the device.
Link: https://github.com/DIGImend/digimend-kernel-drivers/issues/622
Tested-by: Andreas Grosse <andig.mail@t-online.de>
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>
José Expósito [Mon, 26 Dec 2022 12:54:53 +0000 (13:54 +0100)]
HID: uclogic: Add support for XP-PEN Deco Pro SW
[ Upstream commit
7744ca571af55b794595cff2da9d51a26904998f ]
The XP-PEN Deco Pro SW is a UGEE v2 device with a frame with 8 buttons,
a bitmap dial and a mouse; however, the UCLOGIC_MOUSE_FRAME_QUIRK is
required because it reports an incorrect frame type. Its pen has 2
buttons, supports tilt and pressure.
It can be connected using a USB cable or, to use it in wireless mode,
using a USB Bluetooth dongle. When it is connected in wireless mode the
device battery is used to power it.
All the pieces to support it are already in place. Add its ID and
quirks in order to support the device.
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>
José Expósito [Mon, 26 Dec 2022 12:54:50 +0000 (13:54 +0100)]
HID: uclogic: Add battery quirk
[ Upstream commit
f60c377f52de37f8705c5fc6d57737fdaf309ff9 ]
Some UGEE v2 tablets have a wireless version with an internal battery
and their firmware is able to report their battery level.
However, there was not found a field on their descriptor indicating
whether the tablet has battery or not, making it mandatory to classify
such devices through the UCLOGIC_BATTERY_QUIRK quirk.
Tested-by: Mia Kanashi <chad@redpilled.dev>
Tested-by: Andreas Grosse <andig.mail@t-online.de>
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>
José Expósito [Mon, 26 Dec 2022 12:54:49 +0000 (13:54 +0100)]
HID: uclogic: Add frame type quirk
[ Upstream commit
14b71e6ad8ca59dd734c7fa9676f3d60bddee2a9 ]
The report descriptor used to get information about UGEE v2 devices is
incorrect in the XP-PEN Deco Pro SW. It indicates that the device frame
is of type UCLOGIC_PARAMS_FRAME_BUTTONS but the device has a frame of
type UCLOGIC_PARAMS_FRAME_MOUSE.
Here is the original report descriptor:
0x0e 0x03 0xc8 0xb3 0x34 0x65 0x08 0x00 0xff 0x1f 0xd8 0x13 0x00 0x00
^ This byte should be 2
Add a quirk to be able to fix the reported frame type.
Tested-by: Mia Kanashi <chad@redpilled.dev>
Tested-by: Andreas Grosse <andig.mail@t-online.de>
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>
Brandon Syu [Thu, 22 Dec 2022 08:43:37 +0000 (16:43 +0800)]
drm/amd/display: fix mapping to non-allocated address
[ Upstream commit
9190d4a263264eabf715f5fc1827da45e3fdc247 ]
[Why]
There is an issue mapping non-allocated location of memory.
It would allocate gpio registers from an array out of bounds.
[How]
Patch correct numbers of bounds for using.
Tested-by: Daniel Wheeler <Daniel.Wheeler@amd.com>
Reviewed-by: Martin Leung <Martin.Leung@amd.com>
Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Brandon Syu <Brandon.Syu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Konstantin Meskhidze [Wed, 30 Nov 2022 02:50:46 +0000 (10:50 +0800)]
drm: amd: display: Fix memory leakage
[ Upstream commit
6b8701be1f66064ca72733c5f6e13748cdbf8397 ]
This commit fixes memory leakage in dc_construct_ctx() function.
Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mario Limonciello [Wed, 11 Jan 2023 21:52:31 +0000 (15:52 -0600)]
drm/amd: Avoid ASSERT for some message failures
[ Upstream commit
3e5019ee67760cd61b2a5fd605e1289c2f92d983 ]
On DCN314 when resuming from s0i3 an ASSERT is shown indicating that
`VBIOSSMC_MSG_SetHardMinDcfclkByFreq` returned `VBIOSSMC_Result_Failed`.
This isn't a driver bug; it's a BIOS/configuration bug. To make this
easier to triage, add an explicit warning when this issue happens.
This matches the behavior utilized for failures with
`VBIOSSMC_MSG_TransferTableDram2Smu` configuration.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thomas Zimmermann [Mon, 19 Dec 2022 16:05:00 +0000 (17:05 +0100)]
Revert "fbcon: don't lose the console font across generic->chip driver switch"
[ Upstream commit
12d5796d55f9fd9e4b621003127c99e176665064 ]
This reverts commit
ae1287865f5361fa138d4d3b1b6277908b54eac9.
Always free the console font when deinitializing the framebuffer
console. Subsequent framebuffer consoles will then use the default
font. Rely on userspace to load any user-configured font for these
consoles.
Commit
ae1287865f53 ("fbcon: don't lose the console font across
generic->chip driver switch") was introduced to work around losing
the font during graphics-device handover. [1][2] It kept a dangling
pointer with the font data between loading the two consoles, which is
fairly adventurous hack. It also never covered cases when the other
consoles, such as VGA text mode, where involved.
The problem has meanwhile been solved in userspace. Systemd comes
with a udev rule that re-installs the configured font when a console
comes up. [3] So the kernel workaround can be removed.
This also removes one of the two special cases triggered by setting
FBINFO_MISC_FIRMWARE in an fbdev driver.
Tested during device handover from efifb and simpledrm to radeon. Udev
reloads the configured console font for the new driver's terminal.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=892340
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1074624
Link: https://cgit.freedesktop.org/systemd/systemd/tree/src/vconsole/90-vconsole.rules.in?h=v222
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221219160516.23436-3-tzimmermann@suse.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Justin Tee [Mon, 9 Jan 2023 23:33:13 +0000 (15:33 -0800)]
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
[ Upstream commit
21681b81b9ae548c5dae7ae00d931197a27f480c ]
During the sysfs firmware write process, a use-after-free read warning is
logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]
Use-after-free read at 0x0000000000cf164d (in kfence-#111):
lpfc_wr_object+0x235/0x310 [lpfc]
lpfc_write_firmware.cold+0x206/0x30d [lpfc]
lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]
lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]
kernfs_fop_write_iter+0x121/0x1b0
new_sync_write+0x11c/0x1b0
vfs_write+0x1ef/0x280
ksys_write+0x5f/0xe0
do_syscall_64+0x59/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into
mailbox payload memory, after the mailbox object was released back to the
mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring
that we don't reference internal mailbox memory after release.
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Philip Yang [Mon, 9 Jan 2023 23:08:17 +0000 (18:08 -0500)]
drm/amdkfd: Page aligned memory reserve size
[ Upstream commit
0c2dece8fb541ab07b68c3312a1065fa9c927a81 ]
Use page aligned size to reserve memory usage because page aligned TTM
BO size is used to unreserve memory usage, otherwise no page aligned
size causes memory usage accounting unbalanced.
Change vram_used definition type to int64_t to be able to trigger
WARN_ONCE(adev && adev->kfd.vram_used < 0, "..."), to help debug the
accounting issue with warning and backtrace.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mario Limonciello [Tue, 3 Jan 2023 22:03:41 +0000 (16:03 -0600)]
drm/amd: Avoid BUG() for case of SRIOV missing IP version
[ Upstream commit
93fec4f8c158584065134b4d45e875499bf517c8 ]
No need to crash the kernel. AMDGPU will now fail to probe.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liwei Song [Fri, 6 Jan 2023 09:47:29 +0000 (17:47 +0800)]
drm/radeon: free iio for atombios when driver shutdown
[ Upstream commit
4773fadedca918faec443daaca5e4ea1c0ced144 ]
Fix below kmemleak when unload radeon driver:
unreferenced object 0xffff9f8608ede200 (size 512):
comm "systemd-udevd", pid 326, jiffies
4294682822 (age 716.338s)
hex dump (first 32 bytes):
00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500
[<
00000000b6883cea>] atom_parse+0x117/0x230 [radeon]
[<
00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon]
[<
00000000683f672e>] si_init+0x57/0x750 [radeon]
[<
00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon]
[<
0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon]
[<
00000000b5155064>] drm_dev_register+0xdd/0x1d0
[<
0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon]
[<
00000000e69ecca3>] pci_device_probe+0xe1/0x160
[<
0000000019484b76>] really_probe.part.0+0xc1/0x2c0
[<
000000003f2649da>] __driver_probe_device+0x96/0x130
[<
00000000231c5bb1>] driver_probe_device+0x24/0xf0
[<
0000000000a42377>] __driver_attach+0x77/0x190
[<
00000000d7574da6>] bus_for_each_dev+0x7f/0xd0
[<
00000000633166d2>] driver_attach+0x1e/0x30
[<
00000000313b05b8>] bus_add_driver+0x12c/0x1e0
iio was allocated in atom_index_iio() called by atom_parse(),
but it doesn't got released when the dirver is shutdown.
Fix this kmemleak by free it in radeon_atombios_fini().
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Kazlauskas [Tue, 6 Dec 2022 21:10:22 +0000 (16:10 -0500)]
drm/amd/display: Defer DIG FIFO disable after VID stream enable
[ Upstream commit
2d90a1c054831338d57b39aec4d273cf3e867590 ]
[Why]
On some monitors we see a brief flash of corruption during the
monitor disable sequence caused by FIFO being disabled in the middle
of an active DP stream.
[How]
Wait until DP vid stream is disabled before turning off the FIFO.
The FIFO reset on DP unblank should take care of clearing any FIFO
error, if any.
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Syed Hassan <Syed.Hassan@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Carlo Caione [Mon, 19 Dec 2022 09:02:38 +0000 (10:02 +0100)]
drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
[ Upstream commit
77772e607522daa61f3af74df018559db75c43d6 ]
The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.
The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.
This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.
The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.
Align the driver to what is done in the MIPI DBI code by adjusting the
transfer size to the maximum allowed by the SPI controller.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Reviewed-by: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20221116-s905x_spi_ili9486-v4-2-f86b4463b9e4@baylibre.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jingyuan Liang [Tue, 13 Dec 2022 22:53:30 +0000 (22:53 +0000)]
HID: Add Mapping for System Microphone Mute
[ Upstream commit
2d60f9f4f26785a00273cb81fe60eff129ebd449 ]
HUTRR110 added a new usage code for a key that is supposed to
mute/unmute microphone system-wide.
Map the new usage code(0x01 0xa9) to keycode KEY_MICMUTE.
Additionally hid-debug is adjusted to recognize this keycode as well.
Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomi Valkeinen [Fri, 16 Sep 2022 08:22:05 +0000 (11:22 +0300)]
drm/omap: dsi: Fix excessive stack usage
[ Upstream commit
cfca78971b9233aef0891507a98fba62046d4542 ]
dsi_dump_dsi_irqs(), a function used for debugfs prints, has a large
struct in its frame, which can result in:
drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of 1060 bytes is larger than 1024 bytes [-Wframe-larger-than=]
As the performance of the function is of no concern, let's allocate the
struct with kmalloc instead.
Compile-tested only.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916082206.167427-1-tomi.valkeinen@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Roman Li [Thu, 1 Dec 2022 14:06:42 +0000 (09:06 -0500)]
drm/amd/display: Fix potential null-deref in dm_resume
[ Upstream commit
7a7175a2cd84b7874bebbf8e59f134557a34161b ]
[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null
[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ian Chen [Mon, 28 Nov 2022 08:17:34 +0000 (16:17 +0800)]
drm/amd/display: Revert Reduce delay when sink device not able to ACK 00340h write
[ Upstream commit
639f6ad6df7f47db48b59956b469a6917a136afb ]
[WHY]
It causes regression AMD source will not write DPCD 340.
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: Ian Chen <ian.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dillon Varone [Sat, 3 Dec 2022 03:56:57 +0000 (22:56 -0500)]
drm/amd/display: Reduce expected sdp bandwidth for dcn321
[ Upstream commit
6b81090d6d4cc0fd818c9ec9dbb6906f921ad396 ]
[Description]
Modify soc BB to reduce expected sdp bandwidth and align with measurements to
fix underflow issues.
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Allen Ballway [Wed, 30 Nov 2022 17:08:22 +0000 (17:08 +0000)]
drm: panel-orientation-quirks: Add quirk for DynaBook K50
[ Upstream commit
a3caf7ea0c3d5872ed0f2c51f5476aee0c47a73a ]
Like the ASUS T100HAN for which there is already a quirk,
the DynaBook K50 has a 800x1280 portrait screen mounted
in the tablet part of a landscape oriented 2-in-1.
Update the quirk to be more generic and apply to this device.
Signed-off-by: Allen Ballway <ballway@chromium.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221130170811.1.Iee9a494547541dade9eeee9521cc8b811e76a8a0@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 27 Nov 2022 18:15:39 +0000 (19:15 +0100)]
drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Tab 3 X90F
[ Upstream commit
8a238d7f7eea7592e0764bc3b9e79e7c6354b04c ]
The Lenovo Yoga Tab 3 X90F has a portrait 1600x2560 LCD used in
landscape mode, add a quirk for this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221127181539.104223-1-hdegoede@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Fri, 17 Feb 2023 18:24:54 +0000 (18:24 +0000)]
scm: add user copy checks to put_cmsg()
[ Upstream commit
5f1eb1ff58ea122e24adf0bc940f268ed2227462 ]
This is a followup of commit
2558b8039d05 ("net: use a bounce
buffer for copying skb->mark")
x86 and powerpc define user_access_begin, meaning
that they are not able to perform user copy checks
when using user_write_access_begin() / unsafe_copy_to_user()
and friends [1]
Instead of waiting bugs to trigger on other arches,
add a check_object_size() in put_cmsg() to make sure
that new code tested on x86 with CONFIG_HARDENED_USERCOPY=y
will perform more security checks.
[1] We can not generically call check_object_size() from
unsafe_copy_to_user() because UACCESS is enabled at this point.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Kees Cook <keescook@chromium.org>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Moshe Shemesh [Tue, 14 Feb 2023 16:38:06 +0000 (18:38 +0200)]
devlink: Fix TP_STRUCT_entry in trace of devlink health report
[ Upstream commit
d0ab772c1f1558af84f3293a52e9e886e08e0754 ]
Fix a bug in trace point definition for devlink health report, as
TP_STRUCT_entry of reporter_name should get reporter_name and not msg.
Note no fixes tag as this is a harmless bug as both reporter_name and
msg are strings and TP_fast_assign for this entry is correct.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Heiko Carstens [Mon, 13 Feb 2023 18:38:58 +0000 (19:38 +0100)]
s390/kfence: fix page fault reporting
[ Upstream commit
d9c2cf67b9cfd643ba85d51bc865a89a92e4f979 ]
Baoquan He reported lots of KFENCE reports when /proc/kcore is read,
e.g. with crash or even simpler with dd:
BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x5e/0x120
Invalid read at 0x00000000f4f5149f:
copy_from_kernel_nofault+0x5e/0x120
read_kcore+0x6b2/0x870
proc_reg_read+0x9a/0xf0
vfs_read+0x94/0x270
ksys_read+0x70/0x100
__do_syscall+0x1d0/0x200
system_call+0x82/0xb0
The reason for this is that read_kcore() simply reads memory that might
have been unmapped by KFENCE with copy_from_kernel_nofault(). Any fault due
to pages being unmapped by KFENCE would be handled gracefully by the fault
handler (exception table fixup).
However the s390 fault handler first reports the fault, and only afterwards
would perform the exception table fixup. Most architectures have this in
reversed order, which also avoids the false positive KFENCE reports when an
unmapped page is accessed.
Therefore change the s390 fault handler so it handles exception table
fixups before KFENCE page faults are reported.
Reported-by: Baoquan He <bhe@redhat.com>
Tested-by: Baoquan He <bhe@redhat.com>
Acked-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/r/20230213183858.1473681-1-hca@linux.ibm.com
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Kelley [Mon, 13 Feb 2023 05:08:01 +0000 (21:08 -0800)]
hv_netvsc: Check status in SEND_RNDIS_PKT completion message
[ Upstream commit
dca5161f9bd052e9e73be90716ffd57e8762c697 ]
Completion responses to SEND_RNDIS_PKT messages are currently processed
regardless of the status in the response, so that resources associated
with the request are freed. While this is appropriate, code bugs that
cause sending a malformed message, or errors on the Hyper-V host, go
undetected. Fix this by checking the status and outputting a rate-limited
message if there is an error.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://lore.kernel.org/r/1676264881-48928-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zong-Zhe Yang [Thu, 19 Jan 2023 06:35:28 +0000 (14:35 +0800)]
wifi: rtw89: debug: avoid invalid access on RTW89_DBG_SEL_MAC_30
[ Upstream commit
c074da21dd346e0cfef5d08b0715078d7aea7f8d ]
Only 8852C chip has valid pages on RTW89_DBG_SEL_MAC_30. To other chips,
this section is an address hole. It will lead to crash if trying to access
this section on chips except for 8852C. So, we avoid that.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230119063529.61563-2-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Moises Cardona [Sun, 25 Dec 2022 19:07:13 +0000 (14:07 -0500)]
Bluetooth: btusb: Add VID:PID 13d3:3529 for Realtek RTL8821CE
[ Upstream commit
1eec3b95b5ce7fb2cdd273ac4f8b24b1ed6776a1 ]
This patch adds VID:PID 13d3:3529 to the btusb.c file.
This VID:PID is found in the Realtek RTL8821CE module
(M.2 module AW-CB304NF on an ASUS E210MA laptop)
Output of /sys/kernel/debug/usb/devices:
T: Bus=01 Lev=01 Prnt=01 Port=07 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3529 Rev= 1.10
S: Manufacturer=Realtek
S: Product=Bluetooth Radio
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: Moises Cardona <moisesmcardona@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mario Limonciello [Thu, 15 Dec 2022 02:18:54 +0000 (20:18 -0600)]
Bluetooth: btusb: Add new PID/VID 0489:e0f2 for MT7921
[ Upstream commit
83458a5f272b303479e7d2f451600817a7350b6b ]
This bluetooth device is found in a combo WLAN/BT card
for a MediaTek 7921e.
The device information:
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e0f2 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=
000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
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=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us
I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Anson Tsao <anson.tsao@amd.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marcel Holtmann [Fri, 16 Dec 2022 20:12:47 +0000 (21:12 +0100)]
Bluetooth: Fix issue with Actions Semi ATS2851 based devices
[ Upstream commit
5d44f76fab0839799b19cbc88d13575da968dc08 ]
Their devices claim to support the erroneous data reporting, but don't
actually support the required commands. So blacklist them and add a
quirk.
< HCI Command: Read Default Erroneous Data Reporting (0x03|0x005a) plen 0
> HCI Event: Command Status (0x0f) plen 4
Read Default Erroneous Data Reporting (0x03|0x005a) ncmd 1
Status: Unknown HCI Command (0x01)
T: Bus=02 Lev=02 Prnt=08 Port=02 Cnt=01 Dev#= 10 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=10d7 ProdID=b012 Rev=88.91
S: Manufacturer=Actions
S: Product=general adapter
S: SerialNumber=ACTIONS1234
C:* #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 64 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=01(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=01(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=01(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=01(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=01(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=01(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Thu, 2 Feb 2023 15:15:15 +0000 (16:15 +0100)]
PM: EM: fix memory leak with using debugfs_lookup()
[ Upstream commit
a0e8c13ccd6a9a636d27353da62c2410c4eca337 ]
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Thu, 2 Feb 2023 14:15:45 +0000 (15:15 +0100)]
PM: domains: fix memory leak with using debugfs_lookup()
[ Upstream commit
0b6200e1e9f53dabdc30d0f6c51af9a5f664d32b ]
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Thu, 2 Feb 2023 15:12:14 +0000 (16:12 +0100)]
time/debug: Fix memory leak with using debugfs_lookup()
[ Upstream commit
5b268d8abaec6cbd4bd70d062e769098d96670aa ]
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic at
once.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230202151214.2306822-1-gregkh@linuxfoundation.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Heiko Carstens [Mon, 6 Feb 2023 13:49:40 +0000 (14:49 +0100)]
s390/idle: mark arch_cpu_idle() noinstr
[ Upstream commit
a9cbc1b471d291c865907542394f1c483b93a811 ]
linux-next commit ("cpuidle: tracing: Warn about !rcu_is_watching()")
adds a new warning which hits on s390's arch_cpu_idle() function:
RCU not on for: arch_cpu_idle+0x0/0x28
WARNING: CPU: 2 PID: 0 at include/linux/trace_recursion.h:162 arch_ftrace_ops_list_func+0x24c/0x258
Modules linked in:
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 6.2.0-rc6-next-
20230202 #4
Hardware name: IBM 8561 T01 703 (z/VM 7.3.0)
Krnl PSW :
0404d00180000000 00000000002b55c0 (arch_ftrace_ops_list_func+0x250/0x258)
R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3
Krnl GPRS:
c0000000ffffbfff 0000000080000002 0000000000000026 0000000000000000
0000037ffffe3a28 0000037ffffe3a20 0000000000000000 0000000000000000
0000000000000000 0000000000f4acf6 00000000001044f0 0000037ffffe3cb0
0000000000000000 0000000000000000 00000000002b55bc 0000037ffffe3bb8
Krnl Code:
00000000002b55b0:
c02000840051 larl %r2,
0000000001335652
00000000002b55b6:
c0e5fff512d1 brasl %r14,
0000000000157b58
#
00000000002b55bc:
af000000 mc 0,0
>
00000000002b55c0:
a7f4ffe7 brc 15,
00000000002b558e
00000000002b55c4: 0707 bcr 0,%r7
00000000002b55c6: 0707 bcr 0,%r7
00000000002b55c8:
eb6ff0480024 stmg %r6,%r15,72(%r15)
00000000002b55ce:
b90400ef lgr %r14,%r15
Call Trace:
[<
00000000002b55c0>] arch_ftrace_ops_list_func+0x250/0x258
([<
00000000002b55bc>] arch_ftrace_ops_list_func+0x24c/0x258)
[<
0000000000f5f0fc>] ftrace_common+0x1c/0x20
[<
00000000001044f6>] arch_cpu_idle+0x6/0x28
[<
0000000000f4acf6>] default_idle_call+0x76/0x128
[<
00000000001cc374>] do_idle+0xf4/0x1b0
[<
00000000001cc6ce>] cpu_startup_entry+0x36/0x40
[<
0000000000119d00>] smp_start_secondary+0x140/0x150
[<
0000000000f5d2ae>] restart_int_handler+0x6e/0x90
Mark arch_cpu_idle() noinstr like all other architectures with
CONFIG_ARCH_WANTS_NO_INSTR (should) have it to fix this.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Wed, 1 Feb 2023 01:37:59 +0000 (17:37 -0800)]
uaccess: Add minimum bounds check on kernel buffer size
[ Upstream commit
04ffde1319a715bd0550ded3580d4ea3bc003776 ]
While there is logic about the difference between ksize and usize,
copy_struct_from_user() didn't check the size of the destination buffer
(when it was known) against ksize. Add this check so there is an upper
bounds check on the possible memset() call, otherwise lower bounds
checks made by callers will trigger bounds warnings under -Warray-bounds.
Seen under GCC 13:
In function 'copy_struct_from_user',
inlined from 'iommufd_fops_ioctl' at
../drivers/iommu/iommufd/main.c:333:8:
../include/linux/fortify-string.h:59:33: warning: '__builtin_memset' offset [57,
4294967294] is out of the bounds [0, 56] of object 'buf' with type 'union ucmd_buffer' [-Warray-bounds=]
59 | #define __underlying_memset __builtin_memset
| ^
../include/linux/fortify-string.h:453:9: note: in expansion of macro '__underlying_memset'
453 | __underlying_memset(p, c, __fortify_size); \
| ^~~~~~~~~~~~~~~~~~~
../include/linux/fortify-string.h:461:25: note: in expansion of macro '__fortify_memset_chk'
461 | #define memset(p, c, s) __fortify_memset_chk(p, c, s, \
| ^~~~~~~~~~~~~~~~~~~~
../include/linux/uaccess.h:334:17: note: in expansion of macro 'memset'
334 | memset(dst + size, 0, rest);
| ^~~~~~
../drivers/iommu/iommufd/main.c: In function 'iommufd_fops_ioctl':
../drivers/iommu/iommufd/main.c:311:27: note: 'buf' declared here
311 | union ucmd_buffer buf;
| ^~~
Cc: Christian Brauner <brauner@kernel.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alexander Potapenko <glider@google.com>
Acked-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/lkml/20230203193523.never.667-kees@kernel.org/
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Fri, 27 Jan 2023 22:39:21 +0000 (14:39 -0800)]
coda: Avoid partial allocation of sig_inputArgs
[ Upstream commit
48df133578c70185a95a49390d42df1996ddba2a ]
GCC does not like having a partially allocated object, since it cannot
reason about it for bounds checking when it is passed to other code.
Instead, fully allocate sig_inputArgs. (Alternatively, sig_inputArgs
should be defined as a struct coda_in_hdr, if it is actually not using
any other part of the union.) Seen under GCC 13:
../fs/coda/upcall.c: In function 'coda_upcall':
../fs/coda/upcall.c:801:22: warning: array subscript 'union inputArgs[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds=]
801 | sig_inputArgs->ih.opcode = CODA_SIGNAL;
| ^~
Cc: Jan Harkes <jaharkes@cs.cmu.edu>
Cc: coda@cs.cmu.edu
Cc: codalist@coda.cs.cmu.edu
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230127223921.never.882-kees@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shay Drory [Wed, 11 Jan 2023 11:34:02 +0000 (13:34 +0200)]
net/mlx5: fw_tracer: Fix debug print
[ Upstream commit
988c2352273997a242f15c4fc3711773515006a2 ]
The debug message specify tdsn, but takes as an argument the
tmsn. The correct argument is tmsn, hence, fix the print.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Thu, 2 Feb 2023 12:44:49 +0000 (13:44 +0100)]
ACPI: video: Fix Lenovo Ideapad Z570 DMI match
[ Upstream commit
2d11eae42d52a131f06061015e49dc0f085c5bfc ]
Multiple Ideapad Z570 variants need acpi_backlight=native to force native
use on these pre Windows 8 machines since acpi_video backlight control
does not work here.
The original DMI quirk matches on a product_name of "102434U" but other
variants may have different product_name-s such as e.g. "1024D9U".
Move to checking product_version instead as is more or less standard for
Lenovo DMI quirks for similar reasons.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Sun, 1 Jan 2023 11:47:57 +0000 (12:47 +0100)]
wifi: mt76: dma: free rx_head in mt76_dma_rx_cleanup
[ Upstream commit
1b88b47e898edef0e56e3a2f4e49f052a136153d ]
Free rx_head skb in mt76_dma_rx_cleanup routine in order to avoid
possible memory leak at module unload.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Rui [Wed, 24 Aug 2022 07:44:42 +0000 (15:44 +0800)]
tools/power/x86/intel-speed-select: Add Emerald Rapid quirk
[ Upstream commit
61f9fdcdcd01f9a996b6db4e7092fcdfe8414ad5 ]
Need memory frequency quirk as Sapphire Rapids in Emerald Rapids.
So add Emerald Rapids CPU model check in is_spr_platform().
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[srinivas.pandruvada@linux.intel.com: Subject, changelog and code edits]
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sam James [Wed, 1 Feb 2023 23:00:09 +0000 (23:00 +0000)]
gcc-plugins: drop -std=gnu++11 to fix GCC 13 build
[ Upstream commit
5a6b64adc18d9adfb497a529ff004d59b6df151f ]
The latest GCC 13 snapshot (13.0.1
20230129) gives the following:
```
cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so
:./scripts/gcc-plugins/randomize_layout_plugin.so: undefined symbol: tree_code_type
```
This ends up being because of https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=
b0241ce6e37031
upstream in GCC which changes the visibility of some types used by the kernel's
plugin infrastructure like tree_code_type.
After discussion with the GCC folks, we found that the kernel needs to be building
plugins with the same flags used to build GCC - and GCC defaults to gnu++17
right now. The minimum GCC version needed to build the kernel is GCC 5.1
and GCC 5.1 already defaults to gnu++14 anyway, so just drop the flag, as
all GCCs that could be used to build GCC already default to an acceptable
version which was >= the version we forced via flags until now.
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230201230009.2252783-1-sam@gentoo.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Oliver Hartkopp [Wed, 4 Jan 2023 20:18:44 +0000 (21:18 +0100)]
can: isotp: check CAN address family in isotp_bind()
[ Upstream commit
c6adf659a8ba85913e16a571d5a9bcd17d3d1234 ]
Add missing check to block non-AF_CAN binds.
Syzbot created some code which matched the right sockaddr struct size
but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family
field:
bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10)
^^^^
This has no funtional impact but the userspace should be notified about
the wrong address family field content.
Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=11ff9d8c480000
Reported-by: syzbot+5aed6c3aaba661f5b917@syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/all/20230104201844.13168-1-socketcan@hartkopp.net
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alok Tiwari [Tue, 17 Jan 2023 15:45:49 +0000 (07:45 -0800)]
netfilter: nf_tables: NULL pointer dereference in nf_tables_updobj()
[ Upstream commit
dac7f50a45216d652887fb92d6cd3b7ca7f006ea ]
static analyzer detect null pointer dereference case for 'type'
function __nft_obj_type_get() can return NULL value which require to handle
if type is NULL pointer return -ENOENT.
This is a theoretical issue, since an existing object has a type, but
better add this failsafe check.
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vasily Gorbik [Tue, 24 Jan 2023 17:08:38 +0000 (18:08 +0100)]
s390/mm,ptdump: avoid Kasan vs Memcpy Real markers swapping
[ Upstream commit
05178996e1a77e2a4664536e6d101a086a905034 ]
---[ Real Memory Copy Area Start ]---
0x001bfffffffff000-0x001c000000000000 4K PTE I
---[ Kasan Shadow Start ]---
---[ Real Memory Copy Area End ]---
0x001c000000000000-0x001c000200000000 8G PMD RW NX
...
---[ Kasan Shadow End ]---
ptdump does a stable sort of markers. Move kasan markers after
memcpy real to avoid swapping.
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Schmitz [Thu, 12 Jan 2023 03:55:27 +0000 (16:55 +1300)]
m68k: Check syscall_trace_enter() return code
[ Upstream commit
2ca8a1de4437f21562e57f9ac123914747a8e7a1 ]
Check return code of syscall_trace_enter(), and skip syscall
if -1. Return code will be left at what had been set by
ptrace or seccomp (in regs->d0).
No regression seen in testing with strace on ARAnyM.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: https://lore.kernel.org/r/20230112035529.13521-2-schmitzmic@gmail.com
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Fainelli [Fri, 27 Jan 2023 00:08:19 +0000 (16:08 -0800)]
net: bcmgenet: Add a check for oversized packets
[ Upstream commit
5c0862c2c962052ed5055220a00ac1cefb92fbcd ]
Occasionnaly we may get oversized packets from the hardware which
exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early
check which drops the packet to avoid invoking skb_over_panic() and move
on to processing the next packet.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Fri, 6 Jan 2023 04:19:48 +0000 (20:19 -0800)]
crypto: hisilicon: Wipe entire pool on error
[ Upstream commit
aa85923a954e7704bc9d3847dabeb8540aa98d13 ]
To work around a Clang __builtin_object_size bug that shows up under
CONFIG_FORTIFY_SOURCE and UBSAN_BOUNDS, move the per-loop-iteration
mem_block wipe into a single wipe of the entire pool structure after
the loop.
Reported-by: Nathan Chancellor <nathan@kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/1780
Cc: Weili Qian <qianweili@huawei.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lore.kernel.org/r/20230106041945.never.831-kees@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Feng Tang [Tue, 20 Dec 2022 08:25:12 +0000 (16:25 +0800)]
clocksource: Suspend the watchdog temporarily when high read latency detected
[ Upstream commit
b7082cdfc464bf9231300605d03eebf943dda307 ]
Bugs have been reported on 8 sockets x86 machines in which the TSC was
wrongly disabled when the system is under heavy workload.
[ 818.380354] clocksource: timekeeping watchdog on CPU336: hpet wd-wd read-back delay of 1203520ns
[ 818.436160] clocksource: wd-tsc-wd read-back delay of 181880ns, clock-skew test skipped!
[ 819.402962] clocksource: timekeeping watchdog on CPU338: hpet wd-wd read-back delay of 324000ns
[ 819.448036] clocksource: wd-tsc-wd read-back delay of 337240ns, clock-skew test skipped!
[ 819.880863] clocksource: timekeeping watchdog on CPU339: hpet read-back delay of 150280ns, attempt 3, marking unstable
[ 819.936243] tsc: Marking TSC unstable due to clocksource watchdog
[ 820.068173] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
[ 820.092382] sched_clock: Marking unstable (
818769414384,
1195404998)
[ 820.643627] clocksource: Checking clocksource tsc synchronization from CPU 267 to CPUs 0,4,25,70,126,430,557,564.
[ 821.067990] clocksource: Switched to clocksource hpet
This can be reproduced by running memory intensive 'stream' tests,
or some of the stress-ng subcases such as 'ioport'.
The reason for these issues is the when system is under heavy load, the
read latency of the clocksources can be very high. Even lightweight TSC
reads can show high latencies, and latencies are much worse for external
clocksources such as HPET or the APIC PM timer. These latencies can
result in false-positive clocksource-unstable determinations.
These issues were initially reported by a customer running on a production
system, and this problem was reproduced on several generations of Xeon
servers, especially when running the stress-ng test. These Xeon servers
were not production systems, but they did have the latest steppings
and firmware.
Given that the clocksource watchdog is a continual diagnostic check with
frequency of twice a second, there is no need to rush it when the system
is under heavy load. Therefore, when high clocksource read latencies
are detected, suspend the watchdog timer for 5 minutes.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Acked-by: Waiman Long <longman@redhat.com>
Cc: John Stultz <jstultz@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Feng Tang <feng.tang@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tim Zimmermann [Sat, 7 Jan 2023 19:25:13 +0000 (20:25 +0100)]
thermal: intel: intel_pch: Add support for Wellsburg PCH
[ Upstream commit
40dc1929089fc844ea06d9f8bdb6211ed4517c2e ]
Add the PCI ID for the Wellsburg C610 series chipset PCH.
The driver can read the temperature from the Wellsburg PCH with only
the PCI ID added and no other modifications.
Signed-off-by: Tim Zimmermann <tim@linux4.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dave Thaler [Tue, 24 Jan 2023 00:12:18 +0000 (00:12 +0000)]
bpf, docs: Fix modulo zero, division by zero, overflow, and underflow
[ Upstream commit
0eb9d19e2201068260e439a5c96dc85f9f3722a2 ]
Fix modulo zero, division by zero, overflow, and underflow. Also clarify how
a negative immediate value is used in unsigned division.
Signed-off-by: Dave Thaler <dthaler@microsoft.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20230124001218.827-1-dthaler1968@googlemail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mark Rutland [Mon, 23 Jan 2023 13:45:58 +0000 (13:45 +0000)]
ACPI: Don't build ACPICA with '-Os'
[ Upstream commit
8f9e0a52810dd83406c768972d022c37e7a18f1f ]
The ACPICA code has been built with '-Os' since the beginning of git
history, though there's no explanatory comment as to why.
This is unfortunate as GCC drops the alignment specificed by
'-falign-functions=N' when '-Os' is used, as reported in GCC bug 88345:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
This prevents CONFIG_FUNCTION_ALIGNMENT and
CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B from having their expected effect
on the ACPICA code. This is doubly unfortunate as in subsequent patches
arm64 will depend upon CONFIG_FUNCTION_ALIGNMENT for its ftrace
implementation.
Drop the '-Os' flag when building the ACPICA code. With this removed,
the code builds cleanly and works correctly in testing so far.
I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y,
building and booting a kernel using ACPI, and looking for misaligned
text symbols:
* arm64:
Before, v6.2-rc3:
# uname -rm
6.2.0-rc3 aarch64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
5009
Before, v6.2-rc3 + fixed __cold:
# uname -rm
6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
919
After:
# uname -rm
6.2.0-rc3-00002-g267bddc38572 aarch64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
323
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
0
* x86_64:
Before, v6.2-rc3:
# uname -rm
6.2.0-rc3 x86_64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
11537
Before, v6.2-rc3 + fixed __cold:
# uname -rm
6.2.0-rc3-00001-g2a2bedf8bfa9 x86_64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
2805
After:
# uname -rm
6.2.0-rc3-00002-g267bddc38572 x86_64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
1357
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
0
With the patch applied, the remaining unaligned text labels are a
combination of static call trampolines and labels in assembly, which can
be dealt with in subsequent patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Florent Revest <revest@chromium.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-acpi@vger.kernel.org
Link: https://lore.kernel.org/r/20230123134603.1064407-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jesse Brandeburg [Wed, 14 Dec 2022 00:01:31 +0000 (16:01 -0800)]
ice: add missing checks for PF vsi type
[ Upstream commit
6a8d013e904ad9a66706fcc926ec9993bed7d190 ]
There were a few places we had missed checking the VSI type to make sure
it was definitely a PF VSI, before calling setup functions intended only
for the PF VSI.
This doesn't fix any explicit bugs but cleans up the code in a few
places and removes one explicit != vsi->type check that can be
superseded by this code (it's a super set)
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Siddaraju DH [Tue, 15 Nov 2022 09:41:35 +0000 (15:11 +0530)]
ice: restrict PTP HW clock freq adjustments to 100, 000, 000 PPB
[ Upstream commit
8aa4318c3a122b8670bc09af142de3872ca63b88 ]
The PHY provides only 39b timestamp. With current timing
implementation, we discard lower 7b, leaving 32b timestamp.
The driver reconstructs the full 64b timestamp by correlating the
32b timestamp with cached_time for performance. The reconstruction
algorithm does both forward & backward interpolation.
The 32b timeval has overflow duration of 2^32 counts ~= 4.23 second.
Due to interpolation in both direction, its now ~= 2.125 second
IIRC, going with at least half a duration, the cached_time is updated
with periodic thread of 1 second (worst-case) periodicity.
But the 1 second periodicity is based on System-timer.
With PPB adjustments, if the 1588 timers increments at say
double the rate, (2s in-place of 1s), the Nyquist rate/half duration
sampling/update of cached_time with 1 second periodic thread will
lead to incorrect interpolations.
Hence we should restrict the PPB adjustments to at least half duration
of cached_time update which translates to 500,000,000 PPB.
Since the periodicity of the cached-time system thread can vary,
it is good to have some buffer time and considering practicality of
PPB adjustments, limiting the max_adj to 100,000,000.
Signed-off-by: Siddaraju DH <siddaraju.dh@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pietro Borrello [Sat, 14 Jan 2023 13:11:41 +0000 (13:11 +0000)]
inet: fix fast path in __inet_hash_connect()
[ Upstream commit
21cbd90a6fab7123905386985e3e4a80236b8714 ]
__inet_hash_connect() has a fast path taken if sk_head(&tb->owners) is
equal to the sk parameter.
sk_head() returns the hlist_entry() with respect to the sk_node field.
However entries in the tb->owners list are inserted with respect to the
sk_bind_node field with sk_add_bind_node().
Thus the check would never pass and the fast path never execute.
This fast path has never been executed or tested as this bug seems
to be present since commit
1da177e4c3f4 ("Linux-2.6.12-rc2"), thus
remove it to reduce code complexity.
Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20230112-inet_hash_connect_bind_head-v3-1-b591fd212b93@diag.uniroma1.it
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jisoo Jang [Thu, 29 Dec 2022 09:29:06 +0000 (18:29 +0900)]
wifi: mt7601u: fix an integer underflow
[ Upstream commit
803f3176c5df3b5582c27ea690f204abb60b19b9 ]
Fix an integer underflow that leads to a null pointer dereference in
'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet
could be manipulated, which could trigger an integer underflow of
'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently
causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be
bypassed, eventually leading to a dereference of the pointer 'p', which
is a null pointer.
Ensure that 'dma_len' is greater than 'min_seg_len'.
Found by a modified version of syzkaller.
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+
#139
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:
ffffc900000cfc90 EFLAGS:
00010202
RAX:
dffffc0000000000 RBX:
ffff888115520dc0 RCX:
0000000000000000
RDX:
0000000000000001 RSI:
ffff8881118430c0 RDI:
ffff8881118430f8
RBP:
0000000000000000 R08:
0000000000000e09 R09:
0000000000000010
R10:
ffff888111843017 R11:
ffffed1022308602 R12:
0000000000000000
R13:
0000000000000e09 R14:
0000000000000010 R15:
0000000000000008
FS:
0000000000000000(0000) GS:
ffff88811a800000(0000)
knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
000000004035af40 CR3:
00000001157f2000 CR4:
0000000000750ef0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
PKRU:
55555554
Call Trace:
mt7601u_rx_tasklet+0xc73/0x1270
? mt7601u_submit_rx_buf.isra.0+0x510/0x510
? tasklet_action_common.isra.0+0x79/0x2f0
tasklet_action_common.isra.0+0x206/0x2f0
__do_softirq+0x1b5/0x880
? tasklet_unlock+0x30/0x30
run_ksoftirqd+0x26/0x50
smpboot_thread_fn+0x34f/0x7d0
? smpboot_register_percpu_thread+0x370/0x370
kthread+0x3a1/0x480
? set_kthread_struct+0x120/0x120
ret_from_fork+0x1f/0x30
Modules linked in: 88XXau(O) 88x2bu(O)
---[ end trace
57f34f93b4da0f9b ]---
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:
ffffc900000cfc90 EFLAGS:
00010202
RAX:
dffffc0000000000 RBX:
ffff888115520dc0 RCX:
0000000000000000
RDX:
0000000000000001 RSI:
ffff8881118430c0 RDI:
ffff8881118430f8
RBP:
0000000000000000 R08:
0000000000000e09 R09:
0000000000000010
R10:
ffff888111843017 R11:
ffffed1022308602 R12:
0000000000000000
R13:
0000000000000e09 R14:
0000000000000010 R15:
0000000000000008
FS:
0000000000000000(0000) GS:
ffff88811a800000(0000)
knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
000000004035af40 CR3:
00000001157f2000 CR4:
0000000000750ef0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
PKRU:
55555554
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221229092906.2328282-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jisoo Jang [Fri, 30 Dec 2022 07:51:39 +0000 (16:51 +0900)]
wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds
[ Upstream commit
660145d708be52f946a82e5b633c020f58f996de ]
Fix a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with
a CLM version string by memcpy() in brcmf_fil_iovar_data_get().
Ensure buf is null-terminated.
Found by a modified version of syzkaller.
[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22
[ 33.021554][ T1896] ==================================================================
[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110
[ 33.023122][ T1896] Read of size 1 at addr
ffffc90001d6efc8 by task kworker/0:2/1896
[ 33.023852][ T1896]
[ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132
[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event
[ 33.026581][ T1896] Call Trace:
[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d
[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334
[ 33.028037][ T1896] ? strreplace+0xf2/0x110
[ 33.028403][ T1896] ? strreplace+0xf2/0x110
[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf
[ 33.029283][ T1896] ? strreplace+0xf2/0x110
[ 33.029666][ T1896] strreplace+0xf2/0x110
[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40
[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0
[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110
[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260
[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 33.033582][ T1896] brcmf_attach+0x246/0xd40
[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50
[ 33.034383][ T1896] ? kmemdup+0x30/0x40
[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690
[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710
[ 33.036315][ T1896] really_probe+0x1be/0xa90
[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460
[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0
[ 33.037383][ T1896] driver_probe_device+0x49/0x120
[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250
[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120
[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0
[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20
[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120
[ 33.042330][ T1896] __device_attach+0x207/0x330
[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0
[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0
[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260
[ 33.043914][ T1896] device_add+0xa61/0x1ce0
[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660
[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550
[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770
[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230
[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90
[ 33.046931][ T1896] usb_probe_device+0x9c/0x220
[ 33.047434][ T1896] really_probe+0x1be/0xa90
[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460
[ 33.048134][ T1896] driver_probe_device+0x49/0x120
[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250
[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120
[ 33.049437][ T1896] bus_for_each_drv+0x123/0x1a0
[ 33.049814][ T1896] ? bus_rescan_devices+0x20/0x20
[ 33.050164][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.050579][ T1896] ? trace_hardirqs_on+0x1c/0x120
[ 33.050936][ T1896] __device_attach+0x207/0x330
[ 33.051399][ T1896] ? device_bind_driver+0xb0/0xb0
[ 33.051888][ T1896] ? kobject_uevent_env+0x230/0x12c0
[ 33.052314][ T1896] bus_probe_device+0x1a2/0x260
[ 33.052688][ T1896] device_add+0xa61/0x1ce0
[ 33.053121][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550
[ 33.053568][ T1896] usb_new_device.cold+0x463/0xf66
[ 33.053953][ T1896] ? hub_disconnect+0x400/0x400
[ 33.054313][ T1896] ? rwlock_bug.part.0+0x90/0x90
[ 33.054661][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.055094][ T1896] hub_event+0x10d5/0x3330
[ 33.055530][ T1896] ? hub_port_debounce+0x280/0x280
[ 33.055934][ T1896] ? __lock_acquire+0x1671/0x5790
[ 33.056387][ T1896] ? wq_calc_node_cpumask+0x170/0x2a0
[ 33.056924][ T1896] ? lock_release+0x640/0x640
[ 33.057383][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 33.057916][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 33.058402][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.059019][ T1896] process_one_work+0x873/0x13e0
[ 33.059488][ T1896] ? lock_release+0x640/0x640
[ 33.059932][ T1896] ? pwq_dec_nr_in_flight+0x320/0x320
[ 33.060446][ T1896] ? rwlock_bug.part.0+0x90/0x90
[ 33.060898][ T1896] worker_thread+0x8b/0xd10
[ 33.061348][ T1896] ? __kthread_parkme+0xd9/0x1d0
[ 33.061810][ T1896] ? process_one_work+0x13e0/0x13e0
[ 33.062288][ T1896] kthread+0x379/0x450
[ 33.062660][ T1896] ? _raw_spin_unlock_irq+0x24/0x30
[ 33.063148][ T1896] ? set_kthread_struct+0x100/0x100
[ 33.063606][ T1896] ret_from_fork+0x1f/0x30
[ 33.064070][ T1896]
[ 33.064313][ T1896]
[ 33.064545][ T1896] addr
ffffc90001d6efc8 is located in stack of task kworker/0:2/1896 at offset 512 in frame:
[ 33.065478][ T1896] brcmf_c_preinit_dcmds+0x0/0xc40
[ 33.065973][ T1896]
[ 33.066191][ T1896] this frame has 4 objects:
[ 33.066614][ T1896] [48, 56) 'ptr'
[ 33.066618][ T1896] [80, 148) 'revinfo'
[ 33.066957][ T1896] [192, 210) 'eventmask'
[ 33.067338][ T1896] [256, 512) 'buf'
[ 33.067742][ T1896]
[ 33.068304][ T1896] Memory state around the buggy address:
[ 33.068838][ T1896]
ffffc90001d6ee80: f2 00 00 02 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
[ 33.069545][ T1896]
ffffc90001d6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.070626][ T1896] >
ffffc90001d6ef80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
[ 33.072052][ T1896] ^
[ 33.073043][ T1896]
ffffc90001d6f000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.074230][ T1896]
ffffc90001d6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.074914][ T1896] ==================================================================
[ 33.075713][ T1896] Disabling lock debugging due to kernel taint
Reviewed-by: Arend van Spriel<arend.vanspriel@broadcom.com>
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221230075139.56591-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Holger Hoffstätte [Fri, 13 Jan 2023 15:40:23 +0000 (16:40 +0100)]
bpftool: Always disable stack protection for BPF objects
[ Upstream commit
878625e1c7a10dfbb1fdaaaae2c4d2a58fbce627 ]
When the clang toolchain has stack protection enabled in order to be
consistent with gcc - which just happens to be the case on Gentoo -
the bpftool build fails:
[...]
clang \
-I. \
-I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/include/uapi/ \
-I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/bpf/bpftool/bootstrap/libbpf/include \
-g -O2 -Wall -target bpf -c skeleton/pid_iter.bpf.c -o pid_iter.bpf.o
clang \
-I. \
-I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/include/uapi/ \
-I/tmp/portage/dev-util/bpftool-6.0.12/work/linux-6.0/tools/bpf/bpftool/bootstrap/libbpf/include \
-g -O2 -Wall -target bpf -c skeleton/profiler.bpf.c -o profiler.bpf.o
skeleton/profiler.bpf.c:40:14: error: A call to built-in function '__stack_chk_fail' is not supported.
int BPF_PROG(fentry_XXX)
^
skeleton/profiler.bpf.c:94:14: error: A call to built-in function '__stack_chk_fail' is not supported.
int BPF_PROG(fexit_XXX)
^
2 errors generated.
[...]
Since stack-protector makes no sense for the BPF bits just unconditionally
disable it.
Bug: https://bugs.gentoo.org/890638
Signed-off-by: Holger Hoffstätte <holger@applied-asynchrony.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/74cd9d2e-6052-312a-241e-2b514a75c92c@applied-asynchrony.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Breno Leitao [Mon, 28 Nov 2022 15:31:48 +0000 (07:31 -0800)]
x86/bugs: Reset speculation control settings on init
[ Upstream commit
0125acda7d76b943ca55811df40ed6ec0ecf670f ]
Currently, x86_spec_ctrl_base is read at boot time and speculative bits
are set if Kconfig items are enabled. For example, IBRS is enabled if
CONFIG_CPU_IBRS_ENTRY is configured, etc. These MSR bits are not cleared
if the mitigations are disabled.
This is a problem when kexec-ing a kernel that has the mitigation
disabled from a kernel that has the mitigation enabled. In this case,
the MSR bits are not cleared during the new kernel boot. As a result,
this might have some performance degradation that is hard to pinpoint.
This problem does not happen if the machine is (hard) rebooted because
the bit will be cleared by default.
[ bp: Massage. ]
Suggested-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20221128153148.1129350-1-leitao@debian.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jann Horn [Thu, 5 Jan 2023 13:44:03 +0000 (14:44 +0100)]
timers: Prevent union confusion from unexpected restart_syscall()
[ Upstream commit
9f76d59173d9d146e96c66886b671c1915a5c5e5 ]
The nanosleep syscalls use the restart_block mechanism, with a quirk:
The `type` and `rmtp`/`compat_rmtp` fields are set up unconditionally on
syscall entry, while the rest of the restart_block is only set up in the
unlikely case that the syscall is actually interrupted by a signal (or
pseudo-signal) that doesn't have a signal handler.
If the restart_block was set up by a previous syscall (futex(...,
FUTEX_WAIT, ...) or poll()) and hasn't been invalidated somehow since then,
this will clobber some of the union fields used by futex_wait_restart() and
do_restart_poll().
If userspace afterwards wrongly calls the restart_syscall syscall,
futex_wait_restart()/do_restart_poll() will read struct fields that have
been clobbered.
This doesn't actually lead to anything particularly interesting because
none of the union fields contain trusted kernel data, and
futex(..., FUTEX_WAIT, ...) and poll() aren't syscalls where it makes much
sense to apply seccomp filters to their arguments.
So the current consequences are just of the "if userspace does bad stuff,
it can damage itself, and that's not a problem" flavor.
But still, it seems like a hazard for future developers, so invalidate the
restart_block when partly setting it up in the nanosleep syscalls.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230105134403.754986-1-jannh@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Li [Fri, 6 Jan 2023 00:59:51 +0000 (08:59 +0800)]
thermal: intel: Fix unsigned comparison with less than zero
[ Upstream commit
e7fcfe67f9f410736b758969477b17ea285e8e6c ]
The return value from the call to intel_tcc_get_tjmax() is int, which can
be a negative error code. However, the return value is being assigned to
an u32 variable 'tj_max', so making 'tj_max' an int.
Eliminate the following warning:
./drivers/thermal/intel/intel_soc_dts_iosf.c:394:5-11: WARNING: Unsigned expression compared with zero: tj_max < 0
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3637
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kalle Valo [Thu, 22 Dec 2022 17:15:59 +0000 (19:15 +0200)]
wifi: ath11k: debugfs: fix to work with multiple PCI devices
[ Upstream commit
323d91d4684d238f6bc3693fed93caf795378fe0 ]
ath11k fails to load if there are multiple ath11k PCI devices with same name:
ath11k_pci 0000:01:00.0: Hardware name qcn9074 hw1.0
debugfs: Directory 'ath11k' with parent '/' already present!
ath11k_pci 0000:01:00.0: failed to create ath11k debugfs
ath11k_pci 0000:01:00.0: failed to create soc core: -17
ath11k_pci 0000:01:00.0: failed to init core: -17
ath11k_pci: probe of 0000:01:00.0 failed with error -17
Fix this by creating a directory for each ath11k device using schema
<bus>-<devname>, for example "pci-0000:06:00.0". This directory created under
the top-level ath11k directory, for example /sys/kernel/debug/ath11k.
The reference to the toplevel ath11k directory is not stored anymore within ath11k, instead
it's retrieved using debugfs_lookup(). If the directory does not exist it will
be created. After the last directory from the ath11k directory is removed, for
example when doing rmmod ath11k, the empty ath11k directory is left in place,
it's a minor cosmetic issue anyway.
Here's an example hierarchy with one WCN6855:
ath11k
`-- pci-0000:06:00.0
|-- mac0
| |-- dfs_block_radar_events
| |-- dfs_simulate_radar
| |-- ext_rx_stats
| |-- ext_tx_stats
| |-- fw_dbglog_config
| |-- fw_stats
| | |-- beacon_stats
| | |-- pdev_stats
| | `-- vdev_stats
| |-- htt_stats
| |-- htt_stats_reset
| |-- htt_stats_type
| `-- pktlog_filter
|-- simulate_fw_crash
`-- soc_dp_stats
I didn't have a test setup where I could connect multiple ath11k devices to the
same the host, so I have only tested this with one device.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1
Tested-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221220121231.20120-1-kvalo@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zqiang [Sat, 3 Dec 2022 02:25:03 +0000 (10:25 +0800)]
rcu-tasks: Handle queue-shrink/callback-enqueue race condition
[ Upstream commit
a4fcfbee8f6274f9b3f9a71dd5b03e6772ce33f3 ]
The rcu_tasks_need_gpcb() determines whether or not: (1) There are
callbacks needing another grace period, (2) There are callbacks ready
to be invoked, and (3) It would be a good time to shrink back down to a
single-CPU callback list. This third case is interesting because some
other CPU might be adding new callbacks, which might suddenly make this
a very bad time to be shrinking.
This is currently handled by requiring call_rcu_tasks_generic() to
enqueue callbacks under the protection of rcu_read_lock() and requiring
rcu_tasks_need_gpcb() to wait for an RCU grace period to elapse before
finalizing the transition. This works well in practice.
Unfortunately, the current code assumes that a grace period whose end is
detected by the poll_state_synchronize_rcu() in the second "if" condition
actually ended before the earlier code counted the callbacks queued on
CPUs other than CPU 0 (local variable "ncbsnz"). Given the current code,
it is possible that a long-delayed call_rcu_tasks_generic() invocation
will queue a callback on a non-zero CPU after these CPUs have had their
callbacks counted and zero has been stored to ncbsnz. Such a callback
would trigger the WARN_ON_ONCE() in the second "if" statement.
To see this, consider the following sequence of events:
o CPU 0 invokes rcu_tasks_one_gp(), and counts fewer than
rcu_task_collapse_lim callbacks. It sees at least one
callback queued on some other CPU, thus setting ncbsnz
to a non-zero value.
o CPU 1 invokes call_rcu_tasks_generic() and loads 42 from
->percpu_enqueue_lim. It therefore decides to enqueue its
callback onto CPU 1's callback list, but is delayed.
o CPU 0 sees the rcu_task_cb_adjust is non-zero and that the number
of callbacks does not exceed rcu_task_collapse_lim. It therefore
checks percpu_enqueue_lim, and sees that its value is greater
than the value one. CPU 0 therefore starts the shift back
to a single callback list. It sets ->percpu_enqueue_lim to 1,
but CPU 1 has already read the old value of 42. It also gets
a grace-period state value from get_state_synchronize_rcu().
o CPU 0 sees that ncbsnz is non-zero in its second "if" statement,
so it declines to finalize the shrink operation.
o CPU 0 again invokes rcu_tasks_one_gp(), and counts fewer than
rcu_task_collapse_lim callbacks. It also sees that there are
no callback queued on any other CPU, and thus sets ncbsnz to zero.
o CPU 1 resumes execution and enqueues its callback onto its own
list. This invalidates the value of ncbsnz.
o CPU 0 sees the rcu_task_cb_adjust is non-zero and that the number
of callbacks does not exceed rcu_task_collapse_lim. It therefore
checks percpu_enqueue_lim, but sees that its value is already
unity. It therefore does not get a new grace-period state value.
o CPU 0 sees that rcu_task_cb_adjust is non-zero, ncbsnz is zero,
and that poll_state_synchronize_rcu() says that the grace period
has completed. it therefore finalizes the shrink operation,
setting ->percpu_dequeue_lim to the value one.
o CPU 0 does a debug check, scanning the other CPUs' callback lists.
It sees that CPU 1's list has a callback, so it (rightly)
triggers the WARN_ON_ONCE(). After all, the new value of
->percpu_dequeue_lim says to not bother looking at CPU 1's
callback list, which means that this callback will never be
invoked. This can result in hangs and maybe even OOMs.
Based on long experience with rcutorture, this is an extremely
low-probability race condition, but it really can happen, especially in
preemptible kernels or within guest OSes.
This commit therefore checks for completion of the grace period
before counting callbacks. With this change, in the above failure
scenario CPU 0 would know not to prematurely end the shrink operation
because the grace period would not have completed before the count
operation started.
[ paulmck: Adjust grace-period end rather than adding RCU reader. ]
[ paulmck: Avoid spurious WARN_ON_ONCE() with ->percpu_dequeue_lim check. ]
Signed-off-by: Zqiang <qiang1.zhang@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zqiang [Wed, 30 Nov 2022 23:45:33 +0000 (07:45 +0800)]
rcu-tasks: Make rude RCU-Tasks work well with CPU hotplug
[ Upstream commit
ea5c8987fef20a8cca07e428aa28bc64649c5104 ]
The synchronize_rcu_tasks_rude() function invokes rcu_tasks_rude_wait_gp()
to wait one rude RCU-tasks grace period. The rcu_tasks_rude_wait_gp()
function in turn checks if there is only a single online CPU. If so, it
will immediately return, because a call to synchronize_rcu_tasks_rude()
is by definition a grace period on a single-CPU system. (We could
have blocked!)
Unfortunately, this check uses num_online_cpus() without synchronization,
which can result in too-short grace periods. To see this, consider the
following scenario:
CPU0 CPU1 (going offline)
migration/1 task:
cpu_stopper_thread
-> take_cpu_down
-> _cpu_disable
(dec __num_online_cpus)
->cpuhp_invoke_callback
preempt_disable
access old_data0
task1
del old_data0 .....
synchronize_rcu_tasks_rude()
task1 schedule out
....
task2 schedule in
rcu_tasks_rude_wait_gp()
->__num_online_cpus == 1
->return
....
task1 schedule in
->free old_data0
preempt_enable
When CPU1 decrements __num_online_cpus, its value becomes 1. However,
CPU1 has not finished going offline, and will take one last trip through
the scheduler and the idle loop before it actually stops executing
instructions. Because synchronize_rcu_tasks_rude() is mostly used for
tracing, and because both the scheduler and the idle loop can be traced,
this means that CPU0's prematurely ended grace period might disrupt the
tracing on CPU1. Given that this disruption might include CPU1 executing
instructions in memory that was just now freed (and maybe reallocated),
this is a matter of some concern.
This commit therefore removes that problematic single-CPU check from the
rcu_tasks_rude_wait_gp() function. This dispenses with the single-CPU
optimization, but there is no evidence indicating that this optimization
is important. In addition, synchronize_rcu_tasks_generic() contains a
similar optimization (albeit only for early boot), which also splats.
(As in exactly why are you invoking synchronize_rcu_tasks_rude() so
early in boot, anyway???)
It is OK for the synchronize_rcu_tasks_rude() function's check to be
unsynchronized because the only times that this check can evaluate to
true is when there is only a single CPU running with preemption
disabled.
While in the area, this commit also fixes a minor bug in which a
call to synchronize_rcu_tasks_rude() would instead be attributed to
synchronize_rcu_tasks().
[ paulmck: Add "synchronize_" prefix and "()" suffix. ]
Signed-off-by: Zqiang <qiang1.zhang@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pingfan Liu [Mon, 31 Oct 2022 01:52:37 +0000 (09:52 +0800)]
srcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL
[ Upstream commit
7f24626d6dd844bfc6d1f492d214d29c86d02550 ]
Commit
994f706872e6 ("srcu: Make Tree SRCU able to operate without
snp_node array") assumes that cpu 0 is always online. However, there
really are situations when some other CPU is the boot CPU, for example,
when booting a kdump kernel with the maxcpus=1 boot parameter.
On PowerPC, the kdump kernel can hang as follows:
...
[ 1.740036] systemd[1]: Hostname set to <xyz.com>
[ 243.686240] INFO: task systemd:1 blocked for more than 122 seconds.
[ 243.686264] Not tainted 6.1.0-rc1 #1
[ 243.686272] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000
[ 243.686296] Call Trace:
[ 243.686301] [
c000000016657640] [
c000000016657670] 0xc000000016657670 (unreliable)
[ 243.686317] [
c000000016657830] [
c00000001001dec0] __switch_to+0x130/0x220
[ 243.686333] [
c000000016657890] [
c000000010f607b8] __schedule+0x1f8/0x580
[ 243.686347] [
c000000016657940] [
c000000010f60bb4] schedule+0x74/0x140
[ 243.686361] [
c0000000166579b0] [
c000000010f699b8] schedule_timeout+0x168/0x1c0
[ 243.686374] [
c000000016657a80] [
c000000010f61de8] __wait_for_common+0x148/0x360
[ 243.686387] [
c000000016657b20] [
c000000010176bb0] __flush_work.isra.0+0x1c0/0x3d0
[ 243.686401] [
c000000016657bb0] [
c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40
[ 243.686415] [
c000000016657bd0] [
c0000000105f21b8] fsnotify_destroy_group+0x68/0x160
[ 243.686428] [
c000000016657c40] [
c0000000105f6500] inotify_release+0x30/0xa0
[ 243.686440] [
c000000016657cb0] [
c0000000105751a8] __fput+0xc8/0x350
[ 243.686452] [
c000000016657d00] [
c00000001017d524] task_work_run+0xe4/0x170
[ 243.686464] [
c000000016657d50] [
c000000010020e94] do_notify_resume+0x134/0x140
[ 243.686478] [
c000000016657d80] [
c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270
[ 243.686493] [
c000000016657de0] [
c00000001002ec60] syscall_exit_prepare+0x70/0x180
[ 243.686505] [
c000000016657e10] [
c00000001000bf7c] system_call_vectored_common+0xfc/0x280
[ 243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4
[ 243.686528] NIP:
00007fffa47d5ba4 LR:
0000000000000000 CTR:
0000000000000000
[ 243.686538] REGS:
c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1)
[ 243.686548] MSR:
800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE> CR:
42044440 XER:
00000000
[ 243.686572] IRQMASK: 0
[ 243.686572] GPR00:
0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000
[ 243.686572] GPR04:
0000000000000002 000000000000000a 0000000000000000 0000000000000001
[ 243.686572] GPR08:
000001000c172dd0 0000000000000000 0000000000000000 0000000000000000
[ 243.686572] GPR12:
0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000
[ 243.686572] GPR16:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 243.686572] GPR20:
0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000
[ 243.686572] GPR24:
00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570
[ 243.686572] GPR28:
000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98
[ 243.686683] NIP [
00007fffa47d5ba4] 0x7fffa47d5ba4
[ 243.686691] LR [
0000000000000000] 0x0
[ 243.686698] --- interrupt: 3000
[ 243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds.
[ 243.686717] Not tainted 6.1.0-rc1 #1
[ 243.686724] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800
[ 243.686747] Workqueue: events_unbound fsnotify_mark_destroy_workfn
[ 243.686758] Call Trace:
[ 243.686762] [
c0000000166736e0] [
c00000004fd91000] 0xc00000004fd91000 (unreliable)
[ 243.686775] [
c0000000166738d0] [
c00000001001dec0] __switch_to+0x130/0x220
[ 243.686788] [
c000000016673930] [
c000000010f607b8] __schedule+0x1f8/0x580
[ 243.686801] [
c0000000166739e0] [
c000000010f60bb4] schedule+0x74/0x140
[ 243.686814] [
c000000016673a50] [
c000000010f699b8] schedule_timeout+0x168/0x1c0
[ 243.686827] [
c000000016673b20] [
c000000010f61de8] __wait_for_common+0x148/0x360
[ 243.686840] [
c000000016673bc0] [
c000000010210840] __synchronize_srcu.part.0+0xa0/0xe0
[ 243.686855] [
c000000016673c30] [
c0000000105f2c64] fsnotify_mark_destroy_workfn+0xc4/0x1a0
[ 243.686868] [
c000000016673ca0] [
c000000010174ea8] process_one_work+0x2a8/0x570
[ 243.686882] [
c000000016673d40] [
c000000010175208] worker_thread+0x98/0x5e0
[ 243.686895] [
c000000016673dc0] [
c0000000101828d4] kthread+0x124/0x130
[ 243.686908] [
c000000016673e10] [
c00000001000cd40] ret_from_kernel_thread+0x5c/0x64
[ 366.566274] INFO: task systemd:1 blocked for more than 245 seconds.
[ 366.566298] Not tainted 6.1.0-rc1 #1
[ 366.566305] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 366.566314] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000
[ 366.566329] Call Trace:
...
The above splat occurs because PowerPC really does use maxcpus=1
instead of nr_cpus=1 in the kernel command line. Consequently, the
(quite possibly non-zero) kdump CPU is the only online CPU in the kdump
kernel. SRCU unconditionally queues a sdp->work on cpu 0, for which no
worker thread has been created, so sdp->work will be never executed and
__synchronize_srcu() will never be completed.
This commit therefore replaces CPU ID 0 with get_boot_cpu_id() in key
places in Tree SRCU. Since the CPU indicated by get_boot_cpu_id()
is guaranteed to be online, this avoids the above splat.
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: rcu@vger.kernel.org
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul E. McKenney [Fri, 16 Dec 2022 23:55:48 +0000 (15:55 -0800)]
rcu: Suppress smp_processor_id() complaint in synchronize_rcu_expedited_wait()
[ Upstream commit
2d7f00b2f01301d6e41fd4a28030dab0442265be ]
The normal grace period's RCU CPU stall warnings are invoked from the
scheduling-clock interrupt handler, and can thus invoke smp_processor_id()
with impunity, which allows them to directly invoke dump_cpu_task().
In contrast, the expedited grace period's RCU CPU stall warnings are
invoked from process context, which causes the dump_cpu_task() function's
calls to smp_processor_id() to complain bitterly in debug kernels.
This commit therefore causes synchronize_rcu_expedited_wait() to disable
preemption around its call to dump_cpu_task().
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul E. McKenney [Wed, 14 Dec 2022 19:41:44 +0000 (11:41 -0800)]
rcu: Make RCU_LOCKDEP_WARN() avoid early lockdep checks
[ Upstream commit
0cae5ded535c3a80aed94f119bbd4ee3ae284a65 ]
Currently, RCU_LOCKDEP_WARN() checks the condition before checking
to see if lockdep is still enabled. This is necessary to avoid the
false-positive splats fixed by commit
3066820034b5dd ("rcu: Reject
RCU_LOCKDEP_WARN() false positives"). However, the current state can
result in false-positive splats during early boot before lockdep is fully
initialized. This commit therefore checks debug_lockdep_rcu_enabled()
both before and after checking the condition, thus avoiding both sets
of false-positive error reports.
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Reported-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reported-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jisoo Jang [Tue, 15 Nov 2022 04:34:58 +0000 (13:34 +0900)]
wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()
[ Upstream commit
0a06cadcc2a0044e4a117cc0e61436fc3a0dad69 ]
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware
version string by memcpy() in brcmf_fil_iovar_data_get().
The patch ensures buf is null-terminated.
Found by a modified version of syzkaller.
[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3
[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 47.601565][ T1897] ==================================================================
[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0
[ 47.603447][ T1897] Read of size 1 at addr
ffffc90001f6f000 by task kworker/0:2/1897
[ 47.604336][ T1897]
[ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131
[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event
[ 47.607453][ T1897] Call Trace:
[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1
[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334
[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf
[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0
[ 47.610882][ T1897] strsep+0x1b2/0x1f0
[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0
[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40
[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0
[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110
[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260
[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 47.616288][ T1897] brcmf_attach+0x246/0xd40
[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0
[ 47.617280][ T1897] ? kmemdup+0x43/0x50
[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690
[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760
[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250
[ 47.619950][ T1897] really_probe+0x205/0xb70
[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.622209][ T1897] driver_probe_device+0x4e/0x150
[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.625437][ T1897] __device_attach+0x23f/0x3a0
[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.627057][ T1897] bus_probe_device+0x1da/0x290
[ 47.627557][ T1897] device_add+0xb7b/0x1eb0
[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290
[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0
[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0
[ 47.630385][ T1897] usb_probe_device+0xbb/0x250
[ 47.630927][ T1897] ? usb_suspend+0x590/0x590
[ 47.631397][ T1897] really_probe+0x205/0xb70
[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.633002][ T1897] ? usb_generic_driver_match+0x75/0x90
[ 47.633573][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.634170][ T1897] driver_probe_device+0x4e/0x150
[ 47.634703][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.635248][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.635748][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.636271][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.636881][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.637396][ T1897] __device_attach+0x23f/0x3a0
[ 47.637904][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.638426][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.638985][ T1897] bus_probe_device+0x1da/0x290
[ 47.639512][ T1897] device_add+0xb7b/0x1eb0
[ 47.639977][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.640612][ T1897] ? kfree+0x14a/0x6b0
[ 47.641055][ T1897] ? __usb_get_extra_descriptor+0x116/0x160
[ 47.641679][ T1897] usb_new_device.cold+0x49c/0x1029
[ 47.642245][ T1897] ? hub_disconnect+0x450/0x450
[ 47.642756][ T1897] ? rwlock_bug.part.0+0x90/0x90
[ 47.643273][ T1897] ? _raw_spin_unlock_irq+0x24/0x30
[ 47.643822][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.644445][ T1897] hub_event+0x1c98/0x3950
[ 47.644939][ T1897] ? hub_port_debounce+0x2e0/0x2e0
[ 47.645467][ T1897] ? check_irq_usage+0x861/0xf20
[ 47.645975][ T1897] ? drain_workqueue+0x280/0x360
[ 47.646506][ T1897] ? lock_release+0x640/0x640
[ 47.646994][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.647572][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.648111][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.648735][ T1897] process_one_work+0x92b/0x1460
[ 47.649262][ T1897] ? pwq_dec_nr_in_flight+0x330/0x330
[ 47.649816][ T1897] ? rwlock_bug.part.0+0x90/0x90
[ 47.650336][ T1897] worker_thread+0x95/0xe00
[ 47.650830][ T1897] ? __kthread_parkme+0x115/0x1e0
[ 47.651361][ T1897] ? process_one_work+0x1460/0x1460
[ 47.651904][ T1897] kthread+0x3a1/0x480
[ 47.652329][ T1897] ? set_kthread_struct+0x120/0x120
[ 47.652878][ T1897] ret_from_fork+0x1f/0x30
[ 47.653370][ T1897]
[ 47.653608][ T1897]
[ 47.653848][ T1897] addr
ffffc90001f6f000 is located in stack of task kworker/0:2/1897 at offset 512 in frame:
[ 47.654891][ T1897] brcmf_c_preinit_dcmds+0x0/0xc40
[ 47.655442][ T1897]
[ 47.655690][ T1897] this frame has 4 objects:
[ 47.656151][ T1897] [48, 56) 'ptr'
[ 47.656159][ T1897] [80, 148) 'revinfo'
[ 47.656534][ T1897] [192, 210) 'eventmask'
[ 47.656953][ T1897] [256, 512) 'buf'
[ 47.657410][ T1897]
[ 47.658035][ T1897] Memory state around the buggy address:
[ 47.658743][ T1897]
ffffc90001f6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 47.659577][ T1897]
ffffc90001f6ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 47.660394][ T1897] >
ffffc90001f6f000: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
[ 47.661199][ T1897] ^
[ 47.661625][ T1897]
ffffc90001f6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 47.662455][ T1897]
ffffc90001f6f100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
[ 47.663318][ T1897] ==================================================================
[ 47.664147][ T1897] Disabling lock debugging due to kernel taint
Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221115043458.37562-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nagarajan Maran [Tue, 29 Nov 2022 14:25:32 +0000 (19:55 +0530)]
wifi: ath11k: fix monitor mode bringup crash
[ Upstream commit
950b43f8bd8a4d476d2da6d2a083a89bcd3c90d7 ]
When the interface is brought up in monitor mode, it leads
to NULL pointer dereference crash. This crash happens when
the packet type is extracted for a SKB. This extraction
which is present in the received msdu delivery path,is
not needed for the monitor ring packets since they are
all RAW packets. Hence appending the flags with
"RX_FLAG_ONLY_MONITOR" to skip that extraction.
Observed calltrace:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000064
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=
0000000048517000
[
0000000000000064] pgd=
0000000000000000, p4d=
0000000000000000
Internal error: Oops:
0000000096000004 [#1] PREEMPT SMP
Modules linked in: ath11k_pci ath11k qmi_helpers
CPU: 2 PID: 1781 Comm: napi/-271 Not tainted
6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6
Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT)
pstate:
60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]
lr : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k]
sp :
ffff80000ef5bb10
x29:
ffff80000ef5bb10 x28:
0000000000000000 x27:
ffff000007baafa0
x26:
ffff000014a91ed0 x25:
0000000000000000 x24:
0000000000000000
x23:
ffff800002b77378 x22:
ffff000014a91ec0 x21:
ffff000006c8d600
x20:
0000000000000000 x19:
ffff800002b77740 x18:
0000000000000006
x17:
736564203634343a x16:
656e694c20657079 x15:
0000000000000143
x14:
00000000ffffffea x13:
ffff80000ef5b8b8 x12:
ffff80000ef5b8c8
x11:
ffff80000a591d30 x10:
ffff80000a579d40 x9 :
c0000000ffffefff
x8 :
0000000000000003 x7 :
0000000000017fe8 x6 :
ffff80000a579ce8
x5 :
0000000000000000 x4 :
0000000000000000 x3 :
0000000000000000
x2 :
3a35ec12ed7f8900 x1 :
0000000000000000 x0 :
0000000000000052
Call trace:
ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]
ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]
ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k]
ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]
ath11k_dp_service_srng+0x234/0x338 [ath11k]
ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]
__napi_poll+0x5c/0x190
napi_threaded_poll+0xf0/0x118
kthread+0xf4/0x110
ret_from_fork+0x10/0x20
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Reported-by: Florian Schmidt <florian@fls.name>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216573
Signed-off-by: Nagarajan Maran <quic_nmaran@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221129142532.23421-1-quic_nmaran@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Minsuk Kang [Mon, 5 Dec 2022 01:43:08 +0000 (10:43 +0900)]
wifi: ath9k: Fix use-after-free in ath9k_hif_usb_disconnect()
[ Upstream commit
f099c5c9e2ba08a379bd354a82e05ef839ae29ac ]
This patch fixes a use-after-free in ath9k that occurs in
ath9k_hif_usb_disconnect() when ath9k_destroy_wmi() is trying to access
'drv_priv' that has already been freed by ieee80211_free_hw(), called by
ath9k_htc_hw_deinit(). The patch moves ath9k_destroy_wmi() before
ieee80211_free_hw(). Note that urbs from the driver should be killed
before freeing 'wmi' with ath9k_destroy_wmi() as their callbacks will
access 'wmi'.
Found by a modified version of syzkaller.
==================================================================
BUG: KASAN: use-after-free in ath9k_destroy_wmi+0x38/0x40
Read of size 8 at addr
ffff8881069132a0 by task kworker/0:1/7
CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #131
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
dump_stack_lvl+0x8e/0xd1
print_address_description.constprop.0.cold+0x93/0x334
? ath9k_destroy_wmi+0x38/0x40
? ath9k_destroy_wmi+0x38/0x40
kasan_report.cold+0x83/0xdf
? ath9k_destroy_wmi+0x38/0x40
ath9k_destroy_wmi+0x38/0x40
ath9k_hif_usb_disconnect+0x329/0x3f0
? ath9k_hif_usb_suspend+0x120/0x120
? usb_disable_interface+0xfc/0x180
usb_unbind_interface+0x19b/0x7e0
? usb_autoresume_device+0x50/0x50
device_release_driver_internal+0x44d/0x520
bus_remove_device+0x2e5/0x5a0
device_del+0x5b2/0xe30
? __device_link_del+0x370/0x370
? usb_remove_ep_devs+0x43/0x80
? remove_intf_ep_devs+0x112/0x1a0
usb_disable_device+0x1e3/0x5a0
usb_disconnect+0x267/0x870
hub_event+0x168d/0x3950
? rcu_read_lock_sched_held+0xa1/0xd0
? hub_port_debounce+0x2e0/0x2e0
? check_irq_usage+0x860/0xf20
? drain_workqueue+0x281/0x360
? lock_release+0x640/0x640
? rcu_read_lock_sched_held+0xa1/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? lockdep_hardirqs_on_prepare+0x273/0x3e0
process_one_work+0x92b/0x1460
? pwq_dec_nr_in_flight+0x330/0x330
? rwlock_bug.part.0+0x90/0x90
worker_thread+0x95/0xe00
? __kthread_parkme+0x115/0x1e0
? process_one_work+0x1460/0x1460
kthread+0x3a1/0x480
? set_kthread_struct+0x120/0x120
ret_from_fork+0x1f/0x30
The buggy address belongs to the page:
page:
ffffea00041a44c0 refcount:0 mapcount:0 mapping:
0000000000000000 index:0x0 pfn:0x106913
flags: 0x200000000000000(node=0|zone=2)
raw:
0200000000000000 0000000000000000 dead000000000122 0000000000000000
raw:
0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as freed
page last allocated via order 3, migratetype Unmovable, gfp_mask 0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 7, ts
38347963444, free_ts
41399957635
prep_new_page+0x1aa/0x240
get_page_from_freelist+0x159a/0x27c0
__alloc_pages+0x2da/0x6a0
alloc_pages+0xec/0x1e0
kmalloc_order+0x39/0xf0
kmalloc_order_trace+0x19/0x120
__kmalloc+0x308/0x390
wiphy_new_nm+0x6f5/0x1dd0
ieee80211_alloc_hw_nm+0x36d/0x2230
ath9k_htc_probe_device+0x9d/0x1e10
ath9k_htc_hw_init+0x34/0x50
ath9k_hif_usb_firmware_cb+0x25f/0x4e0
request_firmware_work_func+0x131/0x240
process_one_work+0x92b/0x1460
worker_thread+0x95/0xe00
kthread+0x3a1/0x480
page last free stack trace:
free_pcp_prepare+0x3d3/0x7f0
free_unref_page+0x1e/0x3d0
device_release+0xa4/0x240
kobject_put+0x186/0x4c0
put_device+0x20/0x30
ath9k_htc_disconnect_device+0x1cf/0x2c0
ath9k_htc_hw_deinit+0x26/0x30
ath9k_hif_usb_disconnect+0x2d9/0x3f0
usb_unbind_interface+0x19b/0x7e0
device_release_driver_internal+0x44d/0x520
bus_remove_device+0x2e5/0x5a0
device_del+0x5b2/0xe30
usb_disable_device+0x1e3/0x5a0
usb_disconnect+0x267/0x870
hub_event+0x168d/0x3950
process_one_work+0x92b/0x1460
Memory state around the buggy address:
ffff888106913180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888106913200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
ffff888106913280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff888106913300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888106913380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Signed-off-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20221205014308.1617597-1-linuxlovemin@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kan Liang [Fri, 10 Feb 2023 19:02:38 +0000 (11:02 -0800)]
perf/x86/intel/uncore: Add Meteor Lake support
[ Upstream commit
c828441f21ddc819a28b5723a72e3c840e9de1c6 ]
The uncore subsystem for Meteor Lake is similar to the previous Alder
Lake. The main difference is that MTL provides PMU support for different
tiles, while ADL only provides PMU support for the whole package. On
ADL, there are CBOX, ARB, and clockbox uncore PMON units. On MTL, they
are split into CBOX/HAC_CBOX, ARB/HAC_ARB, and cncu/sncu which provides
a fixed counter for clockticks. Also, new MSR addresses are introduced
on MTL.
The IMC uncore PMON is the same as Alder Lake. Add new PCIIDs of IMC for
Meteor Lake.
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230210190238.1726237-1-kan.liang@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Thu, 26 Jan 2023 15:08:31 +0000 (16:08 +0100)]
cpuidle: lib/bug: Disable rcu_is_watching() during WARN/BUG
[ Upstream commit
5a5d7e9badd2cb8065db171961bd30bd3595e4b6 ]
In order to avoid WARN/BUG from generating nested or even recursive
warnings, force rcu_is_watching() true during
WARN/lockdep_rcu_suspicious().
Notably things like unwinding the stack can trigger rcu_dereference()
warnings, which then triggers more unwinding which then triggers more
warnings etc..
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230126151323.408156109@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mark Rutland [Thu, 26 Jan 2023 15:08:30 +0000 (16:08 +0100)]
cpuidle: drivers: firmware: psci: Dont instrument suspend code
[ Upstream commit
393e2ea30aec634b37004d401863428e120d5e1b ]
The PSCI suspend code is currently instrumentable, which is not safe as
instrumentation (e.g. ftrace) may try to make use of RCU during idle
periods when RCU is not watching.
To fix this we need to ensure that psci_suspend_finisher() and anything
it calls are not instrumented. We can do this fairly simply by marking
psci_suspend_finisher() and the psci*_cpu_suspend() functions as
noinstr, and the underlying helper functions as __always_inline.
When CONFIG_DEBUG_VIRTUAL=y, __pa_symbol() can expand to an out-of-line
instrumented function, so we must use __pa_symbol_nodebug() within
psci_suspend_finisher().
The raw SMCCC invocation functions are written in assembly, and are not
subject to compiler instrumentation.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230126151323.349423061@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jens Axboe [Tue, 24 Jan 2023 15:23:20 +0000 (08:23 -0700)]
x86/fpu: Don't set TIF_NEED_FPU_LOAD for PF_IO_WORKER threads
[ Upstream commit
cb3ea4b7671b7cfbac3ee609976b790aebd0bbda ]
We don't set it on PF_KTHREAD threads as they never return to userspace,
and PF_IO_WORKER threads are identical in that regard. As they keep
running in the kernel until they die, skip setting the FPU flag on them.
More of a cosmetic thing that was found while debugging and
issue and pondering why the FPU flag is set on these threads.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/r/560c844c-f128-555b-40c6-31baff27537f@kernel.dk
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Thu, 12 Jan 2023 19:43:33 +0000 (20:43 +0100)]
cpuidle, intel_idle: Fix CPUIDLE_FLAG_INIT_XSTATE
[ Upstream commit
821ad23d0eaff73ef599ece39ecc77482df20a8c ]
Fix instrumentation bugs objtool found:
vmlinux.o: warning: objtool: intel_idle_s2idle+0xd5: call to fpu_idle_fpregs() leaves .noinstr.text section
vmlinux.o: warning: objtool: intel_idle_xstate+0x11: call to fpu_idle_fpregs() leaves .noinstr.text section
vmlinux.o: warning: objtool: fpu_idle_fpregs+0x9: call to xfeatures_in_use() leaves .noinstr.text section
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Frederic Weisbecker <frederic@kernel.org>
Link: https://lore.kernel.org/r/20230112195540.494977795@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Grzeschik [Sun, 23 Oct 2022 21:56:49 +0000 (23:56 +0200)]
arm64: zynqmp: Enable hs termination flag for USB dwc3 controller
[ Upstream commit
32405e532d358a2f9d4befae928b9883c8597616 ]
Since we need to support legacy phys with the dwc3 controller,
we enable this quirk on the zynqmp platforms.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20221023215649.221726-1-m.grzeschik@pengutronix.de
Signed-off-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qu Wenruo [Sat, 17 Dec 2022 02:34:29 +0000 (10:34 +0800)]
btrfs: scrub: improve tree block error reporting
[ Upstream commit
28232909ba43561887508a6ef46d7f33a648f375 ]
[BUG]
When debugging a scrub related metadata error, it turns out that our
metadata error reporting is not ideal.
The only 3 error messages are:
- BTRFS error (device dm-2): bdev /dev/mapper/test-scratch1 errs: wr 0, rd 0, flush 0, corrupt 0, gen 1
Showing we have metadata generation mismatch errors.
- BTRFS error (device dm-2): unable to fixup (regular) error at logical 7110656 on dev /dev/mapper/test-scratch1
Showing which tree blocks are corrupted.
- BTRFS warning (device dm-2): checksum/header error at logical
24772608 on dev /dev/mapper/test-scratch2, physical 3801088: metadata node (level 1) in tree 5
Showing which physical range the corrupted metadata is at.
We have to combine the above 3 to know we have a corrupted metadata with
generation mismatch.
And this is already the better case, if we have other problems, like
fsid mismatch, we can not even know the cause.
[CAUSE]
The problem is caused by the fact that, scrub_checksum_tree_block()
never outputs any error message.
It just return two bits for scrub: sblock->header_error, and
sblock->generation_error.
And later we report error in scrub_print_warning(), but unfortunately we
only have two bits, there is not really much thing we can done to print
any detailed errors.
[FIX]
This patch will do the following to enhance the error reporting of
metadata scrub:
- Add extra warning (ratelimited) for every error we hit
This can help us to distinguish the different types of errors.
Some errors can help us to know what's going wrong immediately,
like bytenr mismatch.
- Re-order the checks
Currently we check bytenr first, then immediately generation.
This can lead to false generation mismatch reports, while the fsid
mismatches.
Here is the new output for the bug I'm debugging (we forgot to
writeback tree blocks for commit roots):
BTRFS warning (device dm-2): tree block
24117248 mirror 1 has bad fsid, has
b77cd862-f150-4c71-90ec-
7baf0544d83f want
17df6abf-23cd-445f-b350-
5b3e40bfd2fc
BTRFS warning (device dm-2): tree block
24117248 mirror 0 has bad fsid, has
b77cd862-f150-4c71-90ec-
7baf0544d83f want
17df6abf-23cd-445f-b350-
5b3e40bfd2fc
Now we can immediately know it's some tree blocks didn't even get written
back, other than the original confusing generation mismatch.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Thu, 2 Feb 2023 14:19:56 +0000 (15:19 +0100)]
trace/blktrace: fix memory leak with using debugfs_lookup()
[ Upstream commit
83e8864fee26f63a7435e941b7c36a20fd6fe93e ]
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: linux-block@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-trace-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230202141956.2299521-1-gregkh@linuxfoundation.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yu Kuai [Thu, 19 Jan 2023 11:03:50 +0000 (19:03 +0800)]
blk-cgroup: synchronize pd_free_fn() from blkg_free_workfn() and blkcg_deactivate_policy()
[ Upstream commit
f1c006f1c6850c14040f8337753a63119bba39b9 ]
Currently parent pd can be freed before child pd:
t1: remove cgroup C1
blkcg_destroy_blkgs
blkg_destroy
list_del_init(&blkg->q_node)
// remove blkg from queue list
percpu_ref_kill(&blkg->refcnt)
blkg_release
call_rcu
t2: from t1
__blkg_release
blkg_free
schedule_work
t4: deactivate policy
blkcg_deactivate_policy
pd_free_fn
// parent of C1 is freed first
t3: from t2
blkg_free_workfn
pd_free_fn
If policy(for example, ioc_timer_fn() from iocost) access parent pd from
child pd after pd_offline_fn(), then UAF can be triggered.
Fix the problem by delaying 'list_del_init(&blkg->q_node)' from
blkg_destroy() to blkg_free_workfn(), and using a new disk level mutex to
synchronize blkg_free_workfn() and blkcg_deactivate_policy().
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230119110350.2287325-4-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yu Kuai [Thu, 19 Jan 2023 11:03:48 +0000 (19:03 +0800)]
blk-cgroup: dropping parent refcount after pd_free_fn() is done
[ Upstream commit
c7241babf0855d8a6180cd1743ff0ec34de40b4e ]
Some cgroup policies will access parent pd through child pd even
after pd_offline_fn() is done. If pd_free_fn() for parent is called
before child, then UAF can be triggered. Hence it's better to guarantee
the order of pd_free_fn().
Currently refcount of parent blkg is dropped in __blkg_release(), which
is before pd_free_fn() is called in blkg_free_work_fn() while
blkg_free_work_fn() is called asynchronously.
This patch make sure pd_free_fn() called from removing cgroup is ordered
by delaying dropping parent refcount after calling pd_free_fn() for
child.
BTW, pd_free_fn() will also be called from blkcg_deactivate_policy()
from deleting device, and following patches will guarantee the order.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Acked-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20230119110350.2287325-2-yukuai1@huaweicloud.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
projects / platform / kernel / linux-starfive.git / log