UBUNTU: SAUCE: Audit: Fix incorrect static inline function declration.
The LSM attributes SAUCE patches have incorrect syntax for the case
when AUDIT framework is turned off, such as zfcpdump_defconfig. This
in turn breaks building zfcpdump-kernel from Ubuntu patched sources.
Reproducer:
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- zfcpdump_defconfig
make ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- bzImage
BugLink: https://bugs.launchpad.net/bugs/1965766 Fixes: 558fd844dd ("UBUNTU: SAUCE: Audit: Add a new record for multiple object LSM attributes") Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
zouxiaoh [Wed, 23 Feb 2022 02:21:25 +0000 (10:21 +0800)]
UBUNTU: SAUCE: iommu: intel-ipu: use IOMMU passthrough mode for Intel IPUs
BugLink: https://bugs.launchpad.net/bugs/1958004
Intel IPU(Image Processing Unit) has its own (IO)MMU hardware,
The IPU driver allocates its own page table that is not mapped
via the DMA, and thus the Intel IOMMU driver blocks access giving
this error: DMAR: DRHD: handling fault status reg 3 DMAR:
[DMA Read] Request device [00:05.0] PASID ffffffff
fault addr 76406000 [fault reason 06] PTE Read access is not set
As IPU is not an external facing device which is not risky, so use
IOMMU passthrough mode for Intel IPUs.
Change-Id: I6dcccdadac308cf42e20a18e1b593381391e3e6b
Depends-On: Iacd67578e8c6a9b9ac73285f52b4081b72fb68a6
Tracked-On: #JIITL8-411 Signed-off-by: Bingbu Cao <bingbu.cao@intel.com> Signed-off-by: zouxiaoh <xiaohong.zou@intel.com> Signed-off-by: Xu Chongyang <chongyang.xu@intel.com>
(cherry picked from https://github.com/intel/ipu6-drivers/blob/5d5526d2b2811aa52590c2fa513ba989e7e594ab/patch/IOMMU-passthrough-for-intel-ipu.diff) Signed-off-by: You-Sheng Yang <vicamo.yang@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
It should be better to reverse the check on codec_dai
and returned early in order to be easier to understand.
Fixes: de2c6f98817f ("ASoC: soc-compress: prevent the potentially use of null pointer") Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220310030041.1556323-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The fan curve control patches introduced a regression for at least the
TUF FX506 and possibly other TUF series laptops that do not have support
for fan curve control.
As part of the probing process, asus_wmi_evaluate_method_buf is called
to get the factory default fan curve . The WMI management function
returns 0 on certain laptops to indicate lack of fan curve control
instead of ASUS_WMI_UNSUPPORTED_METHOD. This 0 is transformed to
-ENODATA which results in failure when probing.
Fixes: 0f0ac158d28f ("platform/x86: asus-wmi: Add support for custom fan curves") Reported-and-tested-by: Abhijeet V <abhijeetviswa@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220205112840.33095-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The Nextbook Ares 8 is a x86 ACPI tablet which ships with Android x86
as factory OS. Its DSDT contains a bunch of I2C devices which are not
actually there, causing various resource conflicts (the Android x86
kernel fork ignores I2C devices described in the DSDT).
Add a ACPI_QUIRK_SKIP_I2C_CLIENTS for the Nextbook Ares 8 to the
acpi_quirk_skip_dmi_ids table to woraround this.
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> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
GCC12 appears to be much smarter about its dependency tracking and is
aware that the relaxed variants are just normal loads and stores and
this is causing problems like:
The assumption when these were relaxed seems to be that device memory
would be mapped non reordering, and that other constructs
(spinlocks/etc) would provide the barriers to assure that packet data
and in memory rings/queues were ordered with respect to device
register reads/writes. This itself seems a bit sketchy, but the real
problem with GCC12 is that it is moving the actual reads/writes around
at will as though they were independent operations when in truth they
are not, but the compiler can't know that. When looking at the
assembly dumps for many of these routines its possible to see very
clean, but not strictly in program order operations occurring as the
compiler would be free to do if these weren't actually register
reads/write operations.
Its possible to suppress the timeout with a liberal bit of dma_mb()'s
sprinkled around but the device still seems unable to reliably
send/receive data. A better plan is to use the safer readl/writel
everywhere.
Since this partially reverts an older commit, which notes the use of
the relaxed variants for performance reasons. I would suggest that
any performance problems with this commit are targeted at relaxing only
the performance critical code paths after assuring proper barriers.
Fixes: 69d2ea9c79898 ("net: bcmgenet: Use correct I/O accessors") Reported-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Acked-by: Peter Robinson <pbrobinson@gmail.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220310045358.224350-1-jeremy.linton@arm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
There is one call trace that snd_soc_register_card()
->snd_soc_bind_card()->soc_init_pcm_runtime()
->snd_soc_dai_compress_new()->snd_soc_new_compress().
In the trace the 'codec_dai' transfers from card->dai_link,
and we can see from the snd_soc_add_pcm_runtime() in
snd_soc_bind_card() that, if value of card->dai_link->num_codecs
is 0, then 'codec_dai' could be null pointer caused
by index out of bound in 'asoc_rtd_to_codec(rtd, 0)'.
And snd_soc_register_card() is called by various platforms.
Therefore, it is better to add the check in the case of misusing.
And because 'cpu_dai' has already checked in soc_init_pcm_runtime(),
there is no need to check again.
Adding the check as follow, then if 'codec_dai' is null,
snd_soc_new_compress() will not pass through the check
'if (playback + capture != 1)', avoiding the leftover use of
'codec_dai'.
Fixes: 467fece ("ASoC: soc-dai: move snd_soc_dai_stream_valid() to soc-dai.c") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/1634285633-529368-1-git-send-email-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
The mapping from enum port to whatever port numbering scheme is used by
the SWSCI Display Power State Notification is odd, and the memory of it
has faded. In any case, the parameter only has space for ports numbered
[0..4], and UBSAN reports bit shift beyond it when the platform has port
F or more.
Since the SWSCI functionality is supposed to be obsolete for new
platforms (i.e. ones that might have port F or more), just bail out
early if the mapped and mangled port number is beyond what the Display
Power State Notification can support.
Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable") Cc: <stable@vger.kernel.org> # v3.13+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
In the current PCM design, the read/write syscalls (as well as the
equivalent ioctls) are allowed before the PCM stream is running, that
is, at PCM PREPARED state. Meanwhile, we also allow to re-issue
hw_params and hw_free ioctl calls at the PREPARED state that may
change or free the buffers, too. The problem is that there is no
protection against those mix-ups.
This patch applies the previously introduced runtime->buffer_mutex to
the read/write operations so that the concurrent hw_params or hw_free
call can no longer interfere during the operation. The mutex is
unlocked before scheduling, so we don't take it too long.
Cc: <stable@vger.kernel.org> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Link: https://lore.kernel.org/r/20220322170720.3529-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Wed, 13 Apr 2022 13:26:22 +0000 (15:26 +0200)]
UBUNTU: SAUCE: shiftfs: always rely on init_user_ns
With the porting of shiftfs from 5.15 to 5.17 some filesystem-related
functions are now passing struct user_namespace as argument, however
shiftfs logic is still relying on the fact that these functions need to
use the main filesystem namespace.
Make sure to always use init_user_ns to prevent breakage of system
components that rely on shiftfs.
Without this fix lxd was showing some issues, like failing to create any
file inside a container when shiftfs was used (e.g., using zfs as
storage pool).
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Juerg Haefliger [Mon, 14 Feb 2022 10:29:36 +0000 (11:29 +0100)]
UBUNTU: SAUCE: Makefile: Fix compiler warnings
When building out-of-tree (which we do for package builds), the compiler
emits the following warning:
cc1: warning: ubuntu/include: No such file or directory [-Wmissing-include-dirs]
Fix that by (always) using the absolute path of the include directory.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Juerg Haefliger [Mon, 14 Feb 2022 10:29:35 +0000 (11:29 +0100)]
UBUNTU: SAUCE: Makefile: Remove inclusion of lbm header files
We haven't produced linux-headers-lbm packages in ages so stop trying
to include their header files.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Acked-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
UBUNTU: [Packaging] do not use compression for image packages
linux-image-ABI packages contain compressed content only (vmlinuz,
changelog) and thus the deb does not benefit at all from being
recompressed again. Only copyring file is compressed. We can actually
avoid shipping /doc/ at all, by symlinking it to the modules package
provided /doc/.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
The previous commit incorrectly stated that jammy dpkg default has
switched from xz to zstd. This change was done late in impish
cycle. [1] It also incorrectly states that there are no evident benefits
for the kernel packages to use zstd.
It is correct that zstd compression may require more
resources. However, the decompression speed and decompression memory
requirements are a lot faster. The choice to switch from xz to zstd by
default in Ubuntu was done to speed up installation and upgrade of all
packages, at the expense of slightly larger download sizes.
If we do want to futher optimize compression methods it should
probably be done on per subpackage type. For example, linux-image-ABI
already contains compressed kernel image and not much else, we can
choose to not compress that deb at all with compression method
none. Debug symbols are usually rarely installed, thus it might make
sense to keep them small and thus choose compress ddebs with
xz. However modules and tools should remain compressed with zstd.
With this patch in the tree, Chromebooks running the affected hardware
no longer boot. Bisect points to this patch, and reverting it fixes
the problem.
An analysis of the code with this patch applied shows:
ret = init_clks(pdev, clk);
if (ret)
return ERR_PTR(ret);
...
for (j = 0; j < MAX_CLKS && data->clk_id[j]; j++) {
struct clk *c = clk[data->clk_id[j]];
Not all clocks in the clk_names array have to be present. Only the clocks
in the data->clk_id array are actually needed. The code already checks if
the required clocks are available and bails out if not. The assumption that
all clocks have to be present is wrong, and commit 9de2b9286a6d needs to be
reverted.
Fixes: 9de2b9286a6d ("ASoC: mediatek: Check for error clk pointer") Cc: Jiasheng Jiang <jiasheng@iscas.ac.cn> Cc: Mark Brown <broonie@kernel.org> Cc: James Liao <jamesjj.liao@mediatek.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Matthias Brugger <matthias.bgg@gmail.com Cc: Frank Wunderlich <frank-w@public-files.de> Cc: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/lkml/20220205014755.699603-1-linux@roeck-us.net/ Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
While all userspace tried to limit commandstreams to 64K in size,
a bug in the Mesa driver lead to command streams of up to 128K
being submitted. Allow those to avoid breaking existing userspace.
Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Andrea Righi [Fri, 28 Jan 2022 15:56:27 +0000 (16:56 +0100)]
UBUNTU: [Packaging] Update dependency of pahole / dwarves
We need pahole >= 1.21 to properly support BTF, pahole used to be
provided by dwarves, but this package is going to be renamed into pahole
starting with jammy.
So to be as generic as possible, and facilitate the porting of this rule
across all kernels, specify a single dependency as following:
- if we are in jammy => just depend on pahole
- all the releases < jammy => depend on dwarves >= 1.21
Also add riscv64 to the list of architectures that require pahole.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
When resetting the device, wait for the PhyRstCmplt bit to be set
in the interrupt status register before continuing initialization, to
ensure that the core is actually ready. When using an external PHY, this
also ensures we do not start trying to access the PHY while it is still
in reset. The PHY reset is initiated by the core reset which is
triggered just above, but remains asserted for 5ms after the core is
reset according to the documentation.
The MgtRdy bit could also be waited for, but unfortunately when using
7-series devices, the bit does not appear to work as documented (it
seems to behave as some sort of link state indication and not just an
indication the transceiver is ready) so it can't really be relied on for
this purpose.
Fixes: 8a3b7a252dca9 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Robert Hancock <robert.hancock@calian.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Currently we allow rediculous amounts of kernel memory being allocated
via the etnaviv GEM_SUBMIT ioctl, which is a pretty easy DoS vector. Put
some reasonable limits in to fix this.
The commandstream size is limited to 64KB, which was already a soft limit
on older kernels after which the kernel only took submits on a best effort
base, so there is no userspace that tries to submit commandstreams larger
than this. Even if the whole commandstream is a single incrementing address
load, the size limit also limits the number of potential relocs and
referenced buffers to slightly under 64K, so use the same limit for those
arguments. The performance monitoring infrastructure currently supports
less than 50 performance counter signals, so limiting them to 128 on a
single submit seems like a reasonably future-proof number for now. This
number can be bumped if needed without breaking the interface.
Cc: stable@vger.kernel.org Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Large pkt_len can lead to out-out-bound memcpy. Current
ath9k_hif_usb_rx_stream allows combining the content of two urb
inputs to one pkt. The first input can indicate the size of the
pkt. Any remaining size is saved in hif_dev->rx_remain_len.
While processing the next input, memcpy is used with rx_remain_len.
4-byte pkt_len can go up to 0xffff, while a single input is 0x4000
maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for
pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE.
BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23
I found the bug using a custome USBFuzz port. It's a research work
to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only,
providing hand-crafted usb descriptors to QEMU.
After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU
emulation, I found the KASAN report. The bug is triggerable whenever
pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes
to test the driver works when applying the patch.
Yes, you are right and now the return code depending on the
init_clks().
Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20211222015157.1025853-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Many Intel based platforms face system random freeze after commit 9e2fd29864c5 ("rtw88: add napi support").
The commit itself shouldn't be the culprit. My guess is that the 8821CE
only leaves ASPM L1 for a short period when IRQ is raised. Since IRQ is
masked during NAPI polling, the PCIe link stays at L1 and makes RX DMA
extremely slow. Eventually the RX ring becomes messed up:
[ 1133.194697] rtw_8821ce 0000:02:00.0: pci bus timeout, check dma status
Since the 8821CE hardware may fail to leave ASPM L1, manually do it in
the driver to resolve the issue.
Fixes: 9e2fd29864c5 ("rtw88: add napi support")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215131 BugLink: https://bugs.launchpad.net/bugs/1927808 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Jian-Hong Pan <jhp@endlessos.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211215114635.333767-1-kai.heng.feng@canonical.com Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Gongjun Song [Wed, 5 Jan 2022 08:13:05 +0000 (16:13 +0800)]
ASoC: Intel: sof_sdw: Add support for SKU 0B12 product
BugLink: https://bugs.launchpad.net/bugs/1951563
This product supports a SoundWire headset codec, SoundWire
capture from local microphones and two SoundWire amplifiers.
Signed-off-by: Libin Yang <libin.yang@intel.com> Signed-off-by: Gongjun Song <gongjun.song@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211105022646.26305-10-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit f55af7055cd465f6b767a0c1126977d4529c63c8) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Gongjun Song [Wed, 5 Jan 2022 08:13:03 +0000 (16:13 +0800)]
ASoC: Intel: sof_sdw: Add support for SKU 0B29 product
BugLink: https://bugs.launchpad.net/bugs/1951563
This product supports a SoundWire headset codec, SoundWire
capture from local microphones and two SoundWire amplifiers.
Signed-off-by: Gongjun Song <gongjun.song@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211105022646.26305-8-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 0c2ed4f03f0bfe2be34efbabbebe9875c3aa9ca9) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Gongjun Song [Wed, 5 Jan 2022 08:13:01 +0000 (16:13 +0800)]
ASoC: Intel: sof_sdw: Add support for SKU 0B13 product
BugLink: https://bugs.launchpad.net/bugs/1951563
This product supports SoundWire capture from local microphones
and one SoundWire amplifier(no headset codec).
Signed-off-by: Gongjun Song <gongjun.song@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Rander Wang <rander.wang@intel.com> Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20211105022646.26305-6-yung-chuan.liao@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 6448d0596e48dbc16a910f04ffc248c3f3c0a65c) Signed-off-by: Hui Wang <hui.wang@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Deepak Sharma [Thu, 6 Jan 2022 21:08:37 +0000 (14:08 -0700)]
x86: ACPI: cstate: Optimize C3 entry on AMD CPUs
BugLink: https://bugs.launchpad.net/bugs/1941893
All Zen or newer CPU which support C3 shares cache. Its not necessary to
flush the caches in software before entering C3. This will cause drop in
performance for the cores which share some caches. ARB_DIS is not used
with current AMD C state implementation. So set related flags correctly.
Signed-off-by: Deepak Sharma <deepak.sharma@amd.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit a8fb40966f19ff81520d9ccf8f7e2b95201368b8) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kai-Heng Feng [Wed, 5 Jan 2022 10:02:28 +0000 (18:02 +0800)]
net: wwan: iosm: Keep device at D0 for s2idle case
BugLink: https://bugs.launchpad.net/bugs/1956443
We are seeing spurious wakeup caused by Intel 7560 WWAN on AMD laptops.
This prevent those laptops to stay in s2idle state.
>From what I can understand, the intention of ipc_pcie_suspend() is to
put the device to D3cold, and ipc_pcie_suspend_s2idle() is to keep the
device at D0. However, the device can still be put to D3hot/D3cold by
PCI core.
So explicitly let PCI core know this device should stay at D0, to solve
the spurious wakeup.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit f4dd5174e2739ab0aeda14b32847e587e78ff3d9 linux-next) Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
UBUNTU: SAUCE: vfs: test that one given mount param is not larger than PAGE_SIZE
In order to avoid potential overflows, test that one given mount parameter
is not larger than PAGE_SIZE when parsing it through legacy_parse_param.
Suggested-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
CVE-2022-0185 Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com> Acked-by: Ben Romer <ben.romer@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Fri, 17 Dec 2021 10:14:24 +0000 (11:14 +0100)]
UBUNTU: SAUCE: allow to use __wake_up_pollfree() from GPL modules
commit ebafbcf7f32d ("UBUNTU: SAUCE: binder: turn into module")
is changing binder to be a module, but __wake_up_pollfree() can only be
used internally by the kernel.
Make __wake_up_pollfree an EXPORT_SYMBOL_GPL so that it can be used by
the binder module.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1947206
Additional patch to fix the build errors after applying the
ib_peer_memory patch set forward-ported from impish.
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Jason Gunthorpe [Wed, 17 Nov 2021 15:49:00 +0000 (16:49 +0100)]
UBUNTU: SAUCE: RDMA/core: Updated ib_peer_memory
BugLink: https://launchpad.net/bugs/1947206
- Allow clients to opt out of unmap during invalidation
- Fix some bugs in the sequencing of mlx5 MRs
- Enable ATS for peer memory
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
(provided by Nvidia via private email) Signed-off-by: dann frazier <dann.frazier@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: Andrea Righi <andrea.righi@canonical.com>
The peer_memory_client scheme allows a driver to register with the ib_umem
system that it has the ability to understand user virtual address ranges
that are not compatible with get_user_pages(). For instance VMAs created
with io_remap_pfn_range(), or other driver special VMA.
For ranges the interface understands it can provide a DMA mapped sg_table
for use by the ib_umem, allowing user virtual ranges that cannot be
supported by get_user_pages() to be used as umems for RDMA.
This is designed to preserve the kABI, no functions or structures are
changed, only new symbols are added:
This interface is compatible with the two out of tree GPU drivers:
https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/blob/master/drivers/gpu/drm/amd/amdkfd/kfd_peerdirect.c
https://github.com/Mellanox/nv_peer_memory/blob/master/nv_peer_mem.c
Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Feras Daoud <ferasda@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
(cherry picked from commit a42989294cf39d6e829424734ab0e7ec48bebcef
git://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git) Signed-off-by: dann frazier <dann.frazier@canonical.com>
[ saf: resolve conflicts with updates in 5.12 ] Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
It looks like commit 0857d6f8c759 ("ipv6: When forwarding count rx stats
on the orig netdev") tries to determine the right netdev to account the
rx stats, but in this particular case it's failing and the netdev is
NULL.
Fallback to the previous method of determining the netdev interface (via
skb->dev) to account the rx stats when the orig netdev can't be
determined.
Fixes: 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig netdev") Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
(cherry picked from https://lore.kernel.org/lkml/20211206163447.991402-1-andrea.righi@canonical.com/T/#u) Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Andrea Righi [Mon, 15 Nov 2021 16:52:27 +0000 (17:52 +0100)]
UBUNTU: SAUCE: selftests/seccomp: fix check of fds being assigned
There might be an arbitrary free open fd slot when we run the addfd
sub-test, so checking for progressive numbers of file descriptors
starting from memfd is not always a reliable check and we could get the
following failure:
# RUN global.user_notification_addfd ...
# seccomp_bpf.c:3989:user_notification_addfd:Expected listener (18) == nextfd++ (9)
# user_notification_addfd: Test terminated by assertion
Simply check if memfd and listener are valid file descriptors and start
counting for progressive file checking with the listener fd.
Fixes: 93e720d710df ("selftests/seccomp: More closely track fds being assigned") Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
(cherry picked from https://lore.kernel.org/all/20211115165227.101124-1-andrea.righi@canonical.com/) Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1942215
When the Timer operation is called, there are no arguments, and
acpi_ex_resolve_operands will be called with an out-of-bounds stack pointer
as num_operands is 0.
This does not usually cause any problems, as acpi_ex_resolve_operands will
ignore the parameter when the operation requires no arguments, as is the
case.
However, when the code is compiled with UBSAN, it will trigger, leading to
an oops with invalid opcode on Linux.
Fix it by using a NULL parameter when num_operands is 0.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by: Andrea Righi <andrea.righi@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Shrirang Bagul [Mon, 4 Oct 2021 05:57:50 +0000 (13:57 +0800)]
UBUNTU: SAUCE: xr-usb-serial: remove driver
BugLink: https://bugs.launchpad.net/bugs/1945938
This custom driver was added in Xenial LTS kernel to add support for USB
UART chips:
Product Family: USB UART
Part Numbers:
XR21V1410, XR21V1412, XR21V1414,
XR21B1411, XR21B1420, XR21B1422,
XR21B1424, XR22801, XR22802,
XR22804
Signed-off-by: Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
This is used to re-enable ASPM on RTL8106e, if it is possible.
Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Kunyang_Fan [Tue, 24 Aug 2021 07:26:59 +0000 (15:26 +0800)]
UBUNTU: ODM: mfd: Check AAEON BFPI version before adding device
BugLink: https://bugs.launchpad.net/bugs/1937897
For the below: error log occurring in some devices:
gpio gpiochip0: (gpio_aaeon): tried to insert a GPIO chip with zero lines
gpiochip_add_data_with_key: GPIOs 0..-1 (gpio_aaeon) failed to register
Add the BFPI version checking mechanism to prevent error log bumping.
Fixes: 424945128781 ("UBUNTU: ODM: mfd: Add support for IO functions of AAEON devices") Signed-off-by: Kunyang_Fan <kunyang_fan@asus.com> Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Juerg Haefliger [Mon, 9 Aug 2021 15:22:38 +0000 (17:22 +0200)]
UBUNTU: SAUCE: arm: Fix instruction set selection for GCC 11
BugLink: https://bugs.launchpad.net/bugs/1939308
GCC 11 on ARM now complains like the following when trying to determine if
an arch is supported. Presumably because it enforces the default option
which (in our case) is '--with-float=hard'?
$ arm-linux-gnueabihf-gcc-11 -march=armv7-a -c -x c /dev/null
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
Due to that, the kernel build system selects the wrong compiler options
which throws errros like this:
/tmp/ccrHfZPj.s: Assembler messages:
/tmp/ccrHfZPj.s:116: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccrHfZPj.s:150: Error: selected processor does not support `isb ' in ARM mode
/tmp/ccrHfZPj.s:160: Error: selected processor does not support `mrrc p15,1,r4,r5,c14' in ARM mode
/tmp/ccrHfZPj.s:245: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccrHfZPj.s:503: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccrHfZPj.s:527: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccrHfZPj.s:698: Error: selected processor does not support `dmb ish' in ARM mode
/tmp/ccrHfZPj.s:731: Error: selected processor does not support `isb ' in ARM mode
Fix that by moving the option '-msoft-float' up before the
'arch-$(CONFIG_CPU_<foo>)' instruction selection macros.
Signed-off-by: Juerg Haefliger <juergh@canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
> default_file_splice_write is the last piece of generic code that uses
> set_fs to make the uaccess routines operate on kernel pointers. It
> implements a "fallback loop" for splicing from files that do not actually
> provide a proper splice_read method. The usual file systems and other
> high bandwidth instances all provide a ->splice_read, so this just removes
> support for various device drivers and procfs/debugfs files. If splice
> support for any of those turns out to be important it can be added back
> by switching them to the iter ops and using generic_file_splice_read.
this means that currently all workloads making use of sendfile() on
shiftfs fail. This includes LXD, Anbox and a range of others. Fix this
by providing explicit .splice_read() and .splice_write() methods which
jus restores the status quo and we keep using a generic method provided
by the vfs.
Cc: Seth Forshee <sforshee@kernel.org> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Kunyang_Fan [Wed, 16 Jun 2021 05:56:58 +0000 (13:56 +0800)]
UBUNTU: ODM: mfd: Add support for IO functions of AAEON devices
BugLink: https://bugs.launchpad.net/bugs/1929504
This adds the supports for multiple IO functions of the
AAEON x86 devices and makes use of the WMI interface to
control the these IO devices including:
- GPIO
- LED
- Watchdog
- HWMON
It also adds the mfd child device drivers to support
the above IO functions.
Signed-off-by: Kunyang_Fan <kunyang_fan@asus.com> Review-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Review-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Kunyang_Fan [Wed, 16 Jun 2021 05:57:01 +0000 (13:57 +0800)]
UBUNTU: ODM: hwmon: add driver for AAEON devices
BugLink: https://bugs.launchpad.net/bugs/1929504
This refator patch adds support for the hwmon information
which are transported to userspace through ASUS WMI interface.
Signed-off-by: Kunyang_Fan <kunyang_fan@asus.com> Review-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Review-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
projects / mirror_ubuntu-kernels.git / log