drm/amd: Don't reset dGPUs if the system is going to s2idle
BugLink: https://bugs.launchpad.net/bugs/1975804
An A+A configuration on ASUS ROG Strix G513QY proves that the ASIC
reset for handling aborted suspend can't work with s2idle.
This functionality was introduced in commit daf8de0874ab5b ("drm/amdgpu:
always reset the asic in suspend (v2)"). A few other commits have
gone on top of the ASIC reset, but this still doesn't work on the A+A
configuration in s2idle.
Avoid doing the reset on dGPUs specifically when using s2idle.
Fixes: daf8de0874ab5b ("drm/amdgpu: always reset the asic in suspend (v2)") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2008 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
(cherry picked from commit 7123d39dc24dcd21ff23d75f46f926b15269b9da) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Commit ebc002e3ee78 ("drm/amdgpu: don't use BACO for reset in S3")
stops using BACO for reset during suspend, so it's no longer
necessary to leave BACO enabled during suspend. This fixes
resume from suspend on the navy flounder dGPU in the ASUS ROG
Strix G513QY.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2008
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1982 Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
(cherry picked from commit a56f445f807b0276fc0660c330bf93a9ea78e8ea) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1975798
Sensor discovery status fails in case of broken sensors or
platform not supported. Hence disable driver on failure
of sensor discovery.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
(cherry picked from commit b5d7f43e97dabfa04a4be5ff027ce7da119332be) Signed-off-by: Aaron Ma <aaron.ma@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Cengiz Can <cengiz.can@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1974017
there are cases that trigger a 2nd shadow event for the same
vmaddr/raddr combination. (prefix changes, reboots, some known races)
This will increase memory usages and it will result in long latencies
when cleaning up, e.g. on shutdown. To avoid cases with a list that has
hundreds of identical raddrs we check existing entries at insert time.
As this measurably reduces the list length this will be faster than
traversing the list at shutdown time.
In the long run several places will be optimized to create less entries
and a shrinker might be necessary.
Fixes: 4be130a08420 ("s390/mm: add shadow gmap support") Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20220429151526.1560-1-borntraeger@linux.ibm.com Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
(cherry picked from commit a06afe8383080c630a7a528b8382fc6bb4925b61) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Trond Myklebust [Tue, 17 May 2022 05:46:00 +0000 (07:46 +0200)]
NFS: Fix up nfs_ctx_key_to_expire()
BugLink: https://bugs.launchpad.net/bugs/1968096
If the cached credential exists but doesn't have any expiration callback
then exit early.
Fix up atomicity issues when replacing the credential with a new one
since the existing code could lead to refcount leaks.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
(cherry picked from commit ca05cbae2a0468e5d78e9b4605936a8bf5da328b) Signed-off-by: Frank Heimes <frank.heimes@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by: Bartlomiej Zolnierkiewicz <bartlomiej.zolnierkiewicz@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Jimmy Kizito [Tue, 17 May 2022 08:28:00 +0000 (10:28 +0200)]
drm/amd/display: Initialise encoder assignment when initialising dc_state
BugLink: https://bugs.launchpad.net/bugs/1971417
[Why]
Link encoder assignment tracking variables need to be (re)initialised
whenever dc_state is (re)initialised. Otherwise variables used for
dynamic encoder assignment (especially the link encoder availability
pool) are out of sync with dc_state and future encoder assignments are
invalid.
[How]
Initialise encoder assignment variables when creating new dc_state
resource.
Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 7a47c8820a1d97e6cb5bcef6b65529f1389b0e13) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Jimmy Kizito [Tue, 17 May 2022 08:28:00 +0000 (10:28 +0200)]
drm/amd/display: Query all entries in assignment table during updates.
BugLink: https://bugs.launchpad.net/bugs/1971417
[Why]
Stream ordering and count can vary from one state to the next. Only
checking a subset of entries in the encoder assignment table can lead to
invalid encoder assignments.
[How]
Check all entries in encoder assignment table when querying it.
Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit aadb06f9c9729ee3af1543f54da966644ebc5be7) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Roy Chan [Tue, 17 May 2022 08:28:00 +0000 (10:28 +0200)]
drm/amd/display: fix stale info in link encoder assignment
BugLink: https://bugs.launchpad.net/bugs/1971417
[Why]
The link encoder assignment leaves the old stream data when it was
unassigned. When the clear encoder assignment is called, it based on the
old stale data to access the de-allocated stream.
[How]
There should be no need to explicitly clean up the link encoder
assignment if the unassign loop does the work properly, the loop should
base on the current state to clean up the assignment.
Also, the unassignment should better clean up the values in the
assignement slots as well.
Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Roy Chan <roy.chan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e43098f6abb033142810e695c1b3d9cf61e19849) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Jimmy Kizito [Tue, 17 May 2022 08:28:00 +0000 (10:28 +0200)]
drm/amd/display: Clear encoder assignments when state cleared.
BugLink: https://bugs.launchpad.net/bugs/1971417
[Why]
State can be cleared without removing individual streams (by
calling dc_remove_stream_from_ctx()). This can leave the
encoder assignment module in an incoherent state and cause
future assignments to be incorrect.
[How]
Clear encoder assignments when committing 0 streams or
re-initializing hardware.
Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Jimmy Kizito <Jimmy.Kizito@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 589bd2f03f87563d6dc4f480d47e5aabc09e4784) Signed-off-by: Koba Ko <koba.ko@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Po-Hao Huang [Thu, 19 May 2022 08:16:00 +0000 (10:16 +0200)]
rtw88: add ieee80211:sta_rc_update ops
BugLink: https://bugs.launchpad.net/bugs/1969326
Adding this allows us to get notification when bitrate configuration
of the station changes. Update according parameters to firmware so
the rate control algorithm can work properly.
Signed-off-by: Po-Hao Huang <phhuang@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/20220407095858.46807-2-pkshih@realtek.com
(backported from commit c1edc86472fc3a5aa3b5c5c53c4e20f6a24992a6 linux-next) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Po-Hao Huang [Thu, 19 May 2022 08:16:00 +0000 (10:16 +0200)]
rtw88: 8821c: fix debugfs rssi value
BugLink: https://bugs.launchpad.net/bugs/1969326
RSSI value per frame is reported to mac80211 but not maintained in
our own statistics, add it back to help us debug.
Signed-off-by: Po-Hao Huang <phhuang@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/20220407095858.46807-7-pkshih@realtek.com
(cherry picked from commit ece31c93d4d68f7eb8eea4431b052aacdb678de2 linux-next) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ping-Ke Shih [Thu, 19 May 2022 08:16:00 +0000 (10:16 +0200)]
rtw88: do PHY calibration while starting AP
BugLink: https://bugs.launchpad.net/bugs/1969326
Calling calibration to yield expected PHY performance. We do this in STA
mode, so do this in AP mode as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220407095858.46807-6-pkshih@realtek.com
(cherry picked from commit f5207c122102cac22c78f438610d937a924aee3a linux-next) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Po-Hao Huang [Thu, 19 May 2022 08:16:00 +0000 (10:16 +0200)]
rtw88: 8821c: Enable TX report for management frames
BugLink: https://bugs.launchpad.net/bugs/1969326
Without this setting, hardware would not report to driver even if
management frames are transmitted successfully. So we fix it.
Signed-off-by: Po-Hao Huang <phhuang@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/20220407095858.46807-5-pkshih@realtek.com
(cherry picked from commit f1c4dabfe68df7321cba0a07a30b2776a303abb2 linux-next) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Po-Hao Huang [Thu, 19 May 2022 08:16:00 +0000 (10:16 +0200)]
rtw88: Add update beacon flow for AP mode
BugLink: https://bugs.launchpad.net/bugs/1969326
To support stations in power saving mode, AP should notify stations
that there are frames buffered at the AP via TIM during beacons.
Driver used to transmit identical beacons that were downloaded to
hardware during the initiation phase. This beacon will become
obsolete over time.
If the beacon does not contain sufficient information, station would
not be able to percept that there is data to receive. Hence it won't
wake up and start the PS-poll procedure, this could lead to timeout
and/or lost data segments. In order to resolve this issue, driver will
now download beacon to hardware whenever the content is updated.
Enable hardware to update dtim_count for more efficiency, this reduces
the overhead of downloading beacon at every beacon interval since most
of the time only the dtim_count needs to be updated.
Change queue mapping for broadcast/multicast frames to high queue, so
these frames can be prioritized and sent when dtim_count is zero.
Signed-off-by: Po-Hao Huang <phhuang@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/20220407095858.46807-4-pkshih@realtek.com
(backported from commit f2217968ffdae702c21cc00fa804fbbd9ee6bb4b linux-next) Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
This panic happens only when AUFS is enabled (that is required to
"activates" this feature).
This bug happens because we don't need to decrement anymore the refcount
for the previous vm_file value in ovl_vm_prfile_set(). So make sure to
drop the offending fput() to prevent the kernel panic above.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Even if upstream decided to enable these options by default, it is
probably safer for now to keep IOMMU disabled, to prevent potential
issues like those mentioned above.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Zachary Tahenakos <zachary.tahenakos@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Andy Chi [Thu, 19 May 2022 06:26:00 +0000 (08:26 +0200)]
ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machine
BugLink: https://bugs.launchpad.net/bugs/1974111
The HP EliteBook 630 is using ALC236 codec which used 0x02 to control mute LED
and 0x01 to control micmute LED. Therefore, add a quirk to make it works.
Signed-off-by: Andy Chi <andy.chi@canonical.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20220513121648.28584-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 024a7ad9eb4df626ca8c77fef4f67fd0ebd559d2 linux-next) Signed-off-by: Andy Chi <andy.chi@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1972899
This header file provides forward declartion for pgd_lock but does not
include the header defining its type. This works since the definition of
spinlock_t is usually included somehow via printk.
By trying to avoid recursive includes on PREEMPT_RT I avoided the loop
in printk and as a consequnce kernel/intel.c failed to compile due to
missing type definition.
Include the needed definition for spinlock_t.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: https://lkml.kernel.org/r/20211102165224.wpz4zyhsvwccx5p3@linutronix.de
(cherry picked from commit 35fa745286ac44ee26ed100c2bd2553368ad193b) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Philip Cox <philip.cox@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Hao Yao <hao.yao@intel.com>
(backported from commit c3da4198f8fa357e916cc11ee155b8a38685a270 github.com/intel/ipu6-drivers) Signed-off-by: You-Sheng Yang (vicamo) <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ye Xiang [Wed, 23 Feb 2022 08:58:53 +0000 (16:58 +0800)]
UBUNTU: SAUCE: ljca: assume stub enum failed as a warning
BugLink: https://bugs.launchpad.net/bugs/1964983
Because some old version FW does not support USB2SPI function,
this patch assumes stub enum failed as a warning, so that this
driver can be compatible with old version FW. This patch
reduces the stub enum timeout, so it blocks os start less
time when USB2SPI does not being supported. And this patch
also optimize error handling path when probing failed.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit 4c5b2a125b75b8dde47e0cd4ec2bbcdc32cd0a2e github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang (vicamo) <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ye Xiang [Sat, 19 Feb 2022 16:46:32 +0000 (00:46 +0800)]
UBUNTU: SAUCE: i2c-ljca: fix a null pointer access issue on tgl
BugLink: https://bugs.launchpad.net/bugs/1964983
When there is no UID method in DSDT for LJCA I2C device, uid1 will
be NULL. So we precheck uid1 before using it.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit e8064f0f127bc1a6b4ccae3146d00a7beff435c3 github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang (vicamo) <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ye Xiang [Thu, 10 Feb 2022 04:06:40 +0000 (12:06 +0800)]
UBUNTU: SAUCE: ljca: fix race condition issue in runtime PM
BugLink: https://bugs.launchpad.net/bugs/1964983
A parent device may begin to write, when device is in autosuspend
path. That will make them waiting for each other done.
And the active_transfers may be unbalenced. This patch fixes the
issues.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit efcac8e33ae68cf4e8b148f2042e4d2ef616c863 github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang (vicamo) <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Hao Yao [Wed, 30 Mar 2022 12:44:40 +0000 (20:44 +0800)]
UBUNTU: SAUCE: media: pci: intel: Avoid UBSAN warnings of index bound and shift
BugLink: https://bugs.launchpad.net/bugs/1958006
UBSAN is default enabled on 5.15 kernel on Ubuntu. The code to
allocate resources in IPU can cause some array-index-out-of-bounds
and shift-out-of-bounds warnings, so it needs to be fixed.
Signed-off-by: Hao Yao <hao.yao@intel.com>
(cherry picked from commit 8dcb7d8df28fd311a72f3d996b02231e38aac8a7 github.com/intel/ipu6-drivers) Signed-off-by: You-Sheng Yang (vicamo) <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ye Xiang [Wed, 1 Dec 2021 02:14:37 +0000 (10:14 +0800)]
UBUNTU: SAUCE: ljca: disable autosuspend by default
BugLink: https://bugs.launchpad.net/bugs/1955383
Because it will cost more than 100ms in PM before calling LJCA
resume when enabling autosuspend, which will make first LJCA transfer
after resume use more than 100ms, we disable autosuspend temporarily.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit 3cc092e1e2ccee536c5da23a105431bfdd8952d6 github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ye Xiang [Thu, 11 Nov 2021 13:25:55 +0000 (21:25 +0800)]
UBUNTU: SAUCE: mei_vsc: distinguish platform with different camera sensor
BugLink: https://bugs.launchpad.net/bugs/1955383
Distinguish platform with different camera sensor by
camera model name from acpi. Then we could download
different FW to VSC according to the camera model.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit 85cac41780cd4a1f5d84bd7e64aa9b1036cf877e github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit 11f55ee365786229f6a77885a817ead89e5e5a56 github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Ye Xiang [Wed, 10 Nov 2021 02:23:17 +0000 (10:23 +0800)]
UBUNTU: SAUCE: mei-vsc: switch wait event to uninterruptible
BugLink: https://bugs.launchpad.net/bugs/1955383
Change wakeup ack wait queue to uninterruptible to avoid
unexpected signal interrupt normal hardware transaction.
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit c130eb32d87f76974dd2a47d320a6e7ee26cc880 github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Ye Xiang <xiang.ye@intel.com>
(cherry picked from commit 1ec53c517383e7537e66e80049788578c2c1ccba github.com/intel/ivsc-driver) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Signed-off-by: Hao Yao <hao.yao@intel.com>
(backported from commit 1f26f0c8cb13d14c22d9f7010b1b4774b89136a9 github.com/intel/ipu6-drivers
added CONFIG_VIDEO_OV01A10 to drivers/media/i2c/Kconfig) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Wang Yating [Thu, 29 Jul 2021 06:48:24 +0000 (14:48 +0800)]
UBUNTU: SAUCE: IPU driver release WW04
BugLink: https://bugs.launchpad.net/bugs/1955383 Signed-off-by: Wang Yating <yating.wang@intel.com>
(backported from commit 626e9311e21f3f36f41f756f22f43d589d9de781 github.com/intel/ipu6-drivers
still build ipu3) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Stephen Brennan [Thu, 14 Apr 2022 20:27:45 +0000 (13:27 -0700)]
UBUNTU: SAUCE: debug: Lock down kgdb
KGDB and KDB allow read and write access to kernel memory, and thus
should not be allowed during lockdown. An attacker with access to a
serial port (for example, via a hypervisor console, which some cloud
vendors provide over the network) could trigger the debugger and use it
to bypass lockdown. Ensure KDB and KGDB cannot be used during lockdown.
This fixes CVE-2022-21499.
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
CVE-2022-21499 Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com>
drm/amdgpu: explicitly check for s0ix when evicting resources
BugLink: https://bugs.launchpad.net/bugs/1972134
This codepath should be running in both s0ix and s3, but only does
currently because s3 and s0ix are both set in the s0ix case.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Acked-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e53d9665ab003df0ece8f869fcd3c2bbbecf7190) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 58144d283712c9e80e528e001af6ac5aeee71af2) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1971597
Commit 5467801f1fcb ("gpio: Restrict usage of GPIO chip irq members
before initialization") attempted to fix a race condition that lead to a
NULL pointer, but in the process caused a regression for _AEI/_EVT
declared GPIOs.
This manifests in messages showing deferred probing while trying to
allocate IRQs like so:
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x0000 to IRQ, err -517
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x002C to IRQ, err -517
amd_gpio AMDI0030:00: Failed to translate GPIO pin 0x003D to IRQ, err -517
[ .. more of the same .. ]
The code for walking _AEI doesn't handle deferred probing and so this
leads to non-functional GPIO interrupts.
Fix this issue by moving the call to `acpi_gpiochip_request_interrupts`
to occur after gc->irc.initialized is set.
Ike Panhc [Fri, 29 Apr 2022 06:45:58 +0000 (14:45 +0800)]
UBUNTU: [Config] CONFIG_HISI_PMU=m
BugLink: https://launchpad.net/bugs/1956086 Signed-off-by: Ike Panhc <ike.pan@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
So apply the quirk, and make it the last one since it's an LED quirk.
Signed-off-by: Andy Chi <andy.chi@canonical.com> Fixes: 07bcab93946c ("ALSA: hda/realtek: Add support for HP Laptops") Link: https://lore.kernel.org/r/20220422090845.230071-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 5f5d8890789c90470d9571a283f0b789acd594af linux-next) Signed-off-by: Andy Chi <andy.chi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
You-Sheng Yang [Mon, 11 Apr 2022 09:24:08 +0000 (17:24 +0800)]
UBUNTU: SAUCE: vmd: fixup bridge ASPM by driver name instead
BugLink: https://bugs.launchpad.net/bugs/1942160
Additional VMD bridge IDs needed for new Alder Lake platforms, but
actually there is no a complete list for them. Here we match bridge
devices if they're directly attached to a VMD controller instead.
Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Andy Chi [Mon, 25 Apr 2022 09:23:36 +0000 (17:23 +0800)]
ALSA: hda/realtek: Enable mute/micmute LEDs and limit mic boost on EliteBook 845/865 G9
BugLink: https://bugs.launchpad.net/bugs/1970178
On HP EliteBook 845 G9 and EliteBook 865 G9, the audio LEDs can be enabled by
ALC285_FIXUP_HP_MUTE_LED. So use it accordingly.
Signed-off-by: Andy Chi <andy.chi@canonical.com> Fixes: 07bcab93946c ("ALSA: hda/realtek: Add support for HP Laptops") Link: https://lore.kernel.org/r/20220421063606.39772-1-andy.chi@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit b3fbe53610b5ed8f0370ec4c7e6c8a1f261ddf70) Signed-off-by: Andy Chi <andy.chi@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Kai-Heng Feng [Wed, 30 Mar 2022 07:36:20 +0000 (15:36 +0800)]
ALSA: hda/realtek: Enable headset mic on Lenovo P360
BugLink: https://bugs.launchpad.net/bugs/1967069
Lenovo P360 is another platform equipped with ALC897, and it needs
ALC897_FIXUP_HEADSET_MIC_PIN quirk to make its headset mic work.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://lore.kernel.org/r/20220325160501.705221-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit 5a8738571747c1e275a40b69a608657603867b7e) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Zijun Hu [Fri, 1 Apr 2022 11:32:52 +0000 (19:32 +0800)]
Bluetooth: btusb: Improve stability for QCA devices
BugLink: https://bugs.launchpad.net/bugs/1967067
WCN6855 2.1 will reset to apply firmware downloaded, so wait
a moment for reset done then go ahead to improve stability.
Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
(cherry picked from commit 599ece4f8f073097904d411ee70280a2ec890ad3) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Uma Shankar [Thu, 21 Apr 2022 06:15:33 +0000 (14:15 +0800)]
drm/i915/xelpd: Add Pipe Color Lut caps to platform config
BugLink: https://bugs.launchpad.net/bugs/1967274
XE_LPD has 128 Lut entries for Degamma, with additional 3 entries for
extended range. It has 511 entries for gamma with additional 2 entries
for extended range.
v2: Updated lut size for 10bit gamma, added lut_tests (Ville)
Uma Shankar [Thu, 21 Apr 2022 06:15:32 +0000 (14:15 +0800)]
drm/i915/xelpd: Enable Pipe Degamma
BugLink: https://bugs.launchpad.net/bugs/1967274
Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
to incorparate the extended lut size for XE_LPD.
Ville Syrjälä [Thu, 21 Apr 2022 06:15:31 +0000 (14:15 +0800)]
drm/i915: Use unlocked register accesses for LUT loads
BugLink: https://bugs.launchpad.net/bugs/1967274
We have to bash in a lot of registers to load the higher
precision LUT modes. The locking overhead is significant, especially
as we have to get this done as quickly as possible during vblank.
So let's switch to unlocked accesses for these. Fortunately the LUT
registers are mostly spread around such that two pipes do not have
any registers on the same cacheline. So as long as commits on the
same pipe are serialized (which they are) we should get away with
this without angering the hardware.
The only exceptions are the PREC_PIPEGCMAX registers on ilk/snb which
we don't use atm as they are only used in the 12bit gamma mode. If/when
we add support for that we may need to remember to still serialize
those registers, though I'm not sure ilk/snb are actually affected
by the same cacheline issue. I think ivb/hsw at least were, but they
use a different set of registers for the precision LUT.
I have a test case which is updating the LUTs on two pipes from a
single atomic commit. Running that in a loop for a minute I get the
following worst case with the locks in place:
intel_crtc_vblank_work_start: pipe B, frame=10037, scanline=1081
intel_crtc_vblank_work_start: pipe A, frame=12274, scanline=769
intel_crtc_vblank_work_end: pipe A, frame=12274, scanline=58
intel_crtc_vblank_work_end: pipe B, frame=10037, scanline=74
And here's the worst case with the locks removed:
intel_crtc_vblank_work_start: pipe B, frame=5869, scanline=1081
intel_crtc_vblank_work_start: pipe A, frame=7616, scanline=769
intel_crtc_vblank_work_end: pipe B, frame=5869, scanline=1096
intel_crtc_vblank_work_end: pipe A, frame=7616, scanline=777
The test was done on a snb using the 10bit 1024 entry LUT mode.
The vtotals for the two displays are 793 and 1125. So we can
see that with the locks ripped out the LUT updates are pretty
nicely confined within the vblank, whereas with the locks in
place we're routinely blasting past the vblank end which causes
visual artifacts near the top of the screen.
Uma Shankar [Thu, 21 Apr 2022 06:15:30 +0000 (14:15 +0800)]
drm/i915/xelpd: Enable Pipe color support for D13 platform
BugLink: https://bugs.launchpad.net/bugs/1967274
Enable pipe color support for Display 13 platforms. Currently
limit to just 10bit gamma and later extend it for logarithmic
gamma, once the new UAPI is agreed by community and implemented
by a userspace consumer.
There are race conditions that may lead to UAF bugs in
ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(),
ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we call
ax25_release() to deallocate ax25_dev.
One of the UAF bugs caused by ax25_release() is shown below:
We increase the refcount of ax25_dev in position (1) and (2), and
decrease the refcount of ax25_dev in position (3) and (4).
The ax25_dev will be freed in position (4) and be used in
ax25_t1timer_expiry().
The fail log is shown below:
==============================================================
[ 106.116942] BUG: KASAN: use-after-free in ax25_t1timer_expiry+0x1c/0x60
[ 106.116942] Read of size 8 at addr ffff88800bda9028 by task swapper/0/0
[ 106.116942] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-06123-g0905eec574
[ 106.116942] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-14
[ 106.116942] Call Trace:
...
[ 106.116942] ax25_t1timer_expiry+0x1c/0x60
[ 106.116942] call_timer_fn+0x122/0x3d0
[ 106.116942] __run_timers.part.0+0x3f6/0x520
[ 106.116942] run_timer_softirq+0x4f/0xb0
[ 106.116942] __do_softirq+0x1c2/0x651
...
This patch adds del_timer_sync() in ax25_release(), which could ensure
that all timers stop before we deallocate ax25_dev.
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
The previous commit 7ec02f5ac8a5 ("ax25: fix NPD bug in ax25_disconnect")
move ax25_disconnect into lock_sock() in order to prevent NPD bugs. But
there are race conditions that may lead to null pointer dereferences in
ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(),
ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we use
ax25_kill_by_device() to detach the ax25 device.
One of the race conditions that cause null pointer dereferences can be
shown as below:
This patch moves ax25_disconnect() before s->ax25_dev = NULL
and uses del_timer_sync() to delete timers in ax25_disconnect().
If ax25_disconnect() is called by ax25_kill_by_device() or
ax25->ax25_dev is NULL, the reason in ax25_disconnect() will be
equal to ENETUNREACH, it will wait all timers to stop before we
set null to s->ax25_dev in ax25_kill_by_device().
Fixes: 7ec02f5ac8a5 ("ax25: fix NPD bug in ax25_disconnect") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
[OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
The ax25_disconnect() in ax25_kill_by_device() is not
protected by any locks, thus there is a race condition
between ax25_disconnect() and ax25_destroy_socket().
when ax25->sk is assigned as NULL by ax25_destroy_socket(),
a NULL pointer dereference bug will occur if site (1) or (2)
dereferences ax25->sk.
The refcount of ax25_dev increases in position (1) and (2), and
decreases in position (3) and (4). The ax25_dev will be freed
before dereference sites in ax25_send_control().
The previous commit d01ffb9eee4a ("ax25: add refcount in ax25_dev to
avoid UAF bugs") and commit feef318c855a ("ax25: fix UAF bugs of
net_device caused by rebinding operation") increase the refcounts of
ax25_dev and net_device in ax25_bind() and decrease the matching refcounts
in ax25_kill_by_device() in order to prevent UAF bugs, but there are
reference count leaks.
Firstly, we use ax25_bind() to increase the refcount of ax25_dev in
position (1) and increase the refcount of net_device in position (2).
Then, we use ax25_cb_del() invoked by ax25_destroy_socket() to delete
ax25_cb in hlist in position (3) before calling ax25_kill_by_device().
Finally, the decrements of refcounts in ax25_kill_by_device() will not
be executed, because no s->ax25_dev equals to ax25_dev in position (4).
This patch adds decrements of refcounts in ax25_release() and use
lock_sock() to do synchronization. If refcounts decrease in ax25_release(),
the decrements of refcounts in ax25_kill_by_device() will not be
executed and vice versa.
Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Fixes: 87563a043cef ("ax25: fix reference count leaks of ax25_dev") Fixes: feef318c855a ("ax25: fix UAF bugs of net_device caused by rebinding operation") Reported-by: Thomas Osterried <thomas@osterried.de> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
[OP: backport to 5.15: adjust dev_put_track()->dev_put()] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
The ax25_kill_by_device() will set s->ax25_dev = NULL and
call ax25_disconnect() to change states of ax25_cb and
sock, if we call ax25_bind() before ax25_kill_by_device().
However, if we call ax25_bind() again between the window of
ax25_kill_by_device() and ax25_dev_device_down(), the values
and states changed by ax25_kill_by_device() will be reassigned.
Finally, ax25_dev_device_down() will deallocate net_device.
If we dereference net_device in syscall functions such as
ax25_release(), ax25_sendmsg(), ax25_getsockopt(), ax25_getname()
and ax25_info_show(), a UAF bug will occur.
One of the possible race conditions is shown below:
the corresponding fail log is shown below:
===============================================================
BUG: KASAN: use-after-free in ax25_send_control+0x43/0x210
...
Call Trace:
...
ax25_send_control+0x43/0x210
ax25_release+0x2db/0x3b0
__sock_release+0x6d/0x120
sock_close+0xf/0x20
__fput+0x11f/0x420
...
Allocated by task 1283:
...
__kasan_kmalloc+0x81/0xa0
alloc_netdev_mqs+0x5a/0x680
mkiss_open+0x6c/0x380
tty_ldisc_open+0x55/0x90
...
Freed by task 1969:
...
kfree+0xa3/0x2c0
device_release+0x54/0xe0
kobject_put+0xa5/0x120
tty_ldisc_kill+0x3e/0x80
...
In order to fix these UAF bugs caused by rebinding operation,
this patch adds dev_hold_track() into ax25_bind() and
corresponding dev_put_track() into ax25_kill_by_device().
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
[OP: backport to 5.15: adjust dev_put_track()->dev_put() and
dev_hold_track()->dev_hold()] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
The previous commit d01ffb9eee4a ("ax25: add refcount in ax25_dev
to avoid UAF bugs") introduces refcount into ax25_dev, but there
are reference leak paths in ax25_ctl_ioctl(), ax25_fwd_ioctl(),
ax25_rt_add(), ax25_rt_del() and ax25_rt_opt().
This patch uses ax25_dev_put() and adjusts the position of
ax25_addr_ax25dev() to fix reference cout leaks of ax25_dev.
Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220203150811.42256-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
[OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
If we dereference ax25_dev after we call kfree(ax25_dev) in
ax25_dev_device_down(), it will lead to concurrency UAF bugs.
There are eight syscall functions suffer from UAF bugs, include
ax25_bind(), ax25_release(), ax25_connect(), ax25_ioctl(),
ax25_getname(), ax25_sendmsg(), ax25_getsockopt() and
ax25_info_show().
The root cause of UAF bugs is that kfree(ax25_dev) in
ax25_dev_device_down() is not protected by any locks.
When ax25_dev, which there are still pointers point to,
is released, the concurrency UAF bug will happen.
This patch introduces refcount into ax25_dev in order to
guarantee that there are no pointers point to it when ax25_dev
is released.
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
[OP: backport to 5.15: adjusted context] Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
On systems with overclocking enabled, CPPC Highest Performance can be
hard coded to 0xff. In this case even if we have cores with different
highest performance, ITMT can't be enabled as the current implementation
depends on CPPC Highest Performance.
On such systems we can use MSR_HWP_CAPABILITIES maximum performance field
when CPPC.Highest Performance is 0xff.
Due to legacy reasons, we can't solely depend on MSR_HWP_CAPABILITIES as
in some older systems CPPC Highest Performance is the only way to identify
different performing cores.
Reported-by: Michael Larabel <Michael@MichaelLarabel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Michael Larabel <Michael@MichaelLarabel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>