Author: Kent Overstreet <[email protected]> Date: Sun Jul 3 21:08:18 2022 -0400 9p: Add client parameter to p9_req_put() [ Upstream commit 8b11ff098af42b1fa57fc817daadd53c8b244a0c ] This is to aid in adding mempools, in the next patch. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kent Overstreet <[email protected]> Cc: Eric Van Hensbergen <[email protected]> Cc: Latchesar Ionkov <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kent Overstreet <[email protected]> Date: Sun Jul 3 21:02:49 2022 -0400 9p: Drop kref usage [ Upstream commit 6cda12864cb0f99810a5809e11e3ee5b102c9a47 ] An upcoming patch is going to require passing the client through p9_req_put() -> p9_req_free(), but that's awkward with the kref indirection - so this patch switches to using refcount_t directly. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Kent Overstreet <[email protected]> Cc: Eric Van Hensbergen <[email protected]> Cc: Latchesar Ionkov <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dominique Martinet <[email protected]> Date: Tue Nov 2 22:16:43 2021 +0900 9p: fix a bunch of checkpatch warnings [ Upstream commit 6e195b0f7c8e50927fa31946369c22a0534ec7e2 ] Sohaib Mohamed started a serie of tiny and incomplete checkpatch fixes but seemingly stopped halfway -- take over and do most of it. This is still missing net/9p/trans* and net/9p/protocol.c for a later time... Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Mon Jul 4 17:26:29 2022 -0400 __follow_mount_rcu(): verify that mount_lock remains unchanged commit 20aac6c60981f5bfacd66661d090d907bf1482f0 upstream. Validate mount_lock seqcount as soon as we cross into mount in RCU mode. Sure, ->mnt_root is pinned and will remain so until we do rcu_read_unlock() anyway, and we will eventually fail to unlazy if the mount_lock had been touched, but we might run into a hard error (e.g. -ENOENT) before trying to unlazy. And it's possible to end up with RCU pathwalk racing with rename() and umount() in a way that would fail with -ENOENT while non-RCU pathwalk would've succeeded with any timings. Once upon a time we hadn't needed that, but analysis had been subtle, brittle and went out of window as soon as RENAME_EXCHANGE had been added. It's narrow, hard to hit and won't get you anything other than stray -ENOENT that could be arranged in much easier way with the same priveleges, but it's a bug all the same. Cc: [email protected] X-sky-is-falling: unlikely Fixes: da1ce0670c14 "vfs: add cross-rename" Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shuai Xue <[email protected]> Date: Sun Feb 27 20:25:45 2022 +0800 ACPI: APEI: explicit init of HEST and GHES in apci_init() [ Upstream commit dc4e8c07e9e2f69387579c49caca26ba239f7270 ] From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage the estatus memory pool. On the other hand, ghes_init() relies on sdei_init() to detect the SDEI version and (un)register events. The dependencies are as follows: ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init() ghes_init() => sdei_init() HEST is not PCI-specific and initcall ordering is implicit and not well-defined within a level. Based on above, remove acpi_hest_init() from acpi_pci_root_init() and convert ghes_init() and sdei_init() from initcalls to explicit calls in the following order: acpi_hest_init() ghes_init() sdei_init() Signed-off-by: Shuai Xue <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Williams <[email protected]> Date: Fri Jun 24 16:05:26 2022 -0700 ACPI: APEI: Fix _EINJ vs EFI_MEMORY_SP [ Upstream commit b13a3e5fd40b7d1b394c5ecbb5eb301a4c38e7b2 ] When a platform marks a memory range as "special purpose" it is not onlined as System RAM by default. However, it is still suitable for error injection. Add IORES_DESC_SOFT_RESERVED to einj_error_inject() as a permissible memory type in the sanity checking of the arguments to _EINJ. Fixes: 262b45ae3ab4 ("x86/efi: EFI soft reservation to E820 enumeration") Reviewed-by: Tony Luck <[email protected]> Reported-by: Omar Avelar <[email protected]> Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Thu Jul 21 19:41:10 2022 +0200 ACPI: CPPC: Do not prevent CPPC from working in the future [ Upstream commit 4f4179fcf420873002035cf1941d844c9e0e7cb3 ] There is a problem with the current revision checks in is_cppc_supported() that they essentially prevent the CPPC support from working if a new _CPC package format revision being a proper superset of the v3 and only causing _CPC to return a package with more entries (while retaining the types and meaning of the entries defined by the v3) is introduced in the future and used by the platform firmware. In that case, as long as the number of entries in the _CPC return package is at least CPPC_V3_NUM_ENT, it should be perfectly fine to use the v3 support code and disregard the additional package entries added by the new package format revision. For this reason, drop is_cppc_supported() altogether, put the revision checks directly into acpi_cppc_processor_probe() so they are easier to follow and rework them to take the case mentioned above into account. Fixes: 4773e77cdc9b ("ACPI / CPPC: Add support for CPPC v3") Cc: 4.18+ <[email protected]> # 4.18+ Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 20 11:25:44 2022 +0200 ACPI: EC: Drop the EC_FLAGS_IGNORE_DSDT_GPE quirk [ Upstream commit f7090e0ef360d674f08a22fab90e4e209fb1f658 ] It seems that these quirks are no longer necessary since commit 69b957c26b32 ("ACPI: EC: Fix possible issues related to EC initialization order"), which has fixed this in a generic manner. There are 3 commits adding DMI entries with this quirk (adding multiple DMI entries per commit). 2/3 commits are from before the generic fix. Which leaves commit 6306f0431914 ("ACPI: EC: Make more Asus laptops use ECDT _GPE"), which was committed way after the generic fix. But this was just due to slow upstreaming of it. This commit stems from Endless from 15 Aug 2017 (committed upstream 20 May 2021): https://github.com/endlessm/linux/pull/288 The current code should work fine without this: 1. The EC_FLAGS_IGNORE_DSDT_GPE flag is only checked in ec_parse_device(), like this: if (boot_ec && boot_ec_is_ecdt && EC_FLAGS_IGNORE_DSDT_GPE) { ec->gpe = boot_ec->gpe; } else { /* parse GPE */ } 2. ec_parse_device() is only called from acpi_ec_add() and acpi_ec_dsdt_probe() 3. acpi_ec_dsdt_probe() starts with: if (boot_ec) return; so it only calls ec_parse_device() when boot_ec == NULL, meaning that the quirk never triggers for this call. So only the call in acpi_ec_add() matters. 4. acpi_ec_add() does the following after the ec_parse_device() call: if (boot_ec && ec->command_addr == boot_ec->command_addr && ec->data_addr == boot_ec->data_addr && !EC_FLAGS_TRUST_DSDT_GPE) { /* * Trust PNP0C09 namespace location rather than * ECDT ID. But trust ECDT GPE rather than _GPE * because of ASUS quirks, so do not change * boot_ec->gpe to ec->gpe. */ boot_ec->handle = ec->handle; acpi_handle_debug(ec->handle, "duplicated.\n"); acpi_ec_free(ec); ec = boot_ec; } The quirk only matters if boot_ec != NULL and EC_FLAGS_TRUST_DSDT_GPE is never set at the same time as EC_FLAGS_IGNORE_DSDT_GPE. That means that if the addresses match we always enter this if block and then only the ec->handle part of the data stored in ec by ec_parse_device() is used and the rest is thrown away, after which ec is made to point to boot_ec, at which point ec->gpe == boot_ec->gpe, so the same result as with the quirk set, independent of the value of the quirk. Also note the comment in this block which indicates that the gpe result from ec_parse_device() is deliberately not taken to deal with buggy Asus laptops and all DMI quirks setting EC_FLAGS_IGNORE_DSDT_GPE are for Asus laptops. Based on the above I believe that unless on some quirked laptops the ECDT and DSDT EC addresses do not match we can drop the quirk. I've checked dmesg output to ensure the ECDT and DSDT EC addresses match for quirked models using https://linux-hardware.org hw-probe reports. I've been able to confirm that the addresses match for the following models this way: GL702VMK, X505BA, X505BP, X550VXK, X580VD. Whereas for the following models I could find any dmesg output: FX502VD, FX502VE, X542BA, X542BP. Note the models without dmesg all were submitted in patches with a batch of models and other models from the same batch checkout ok. This, combined with that all the code adding the quirks was written before the generic fix makes me believe that it is safe to remove this quirk now. Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Daniel Drake <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Mon Jun 20 11:25:43 2022 +0200 ACPI: EC: Remove duplicate ThinkPad X1 Carbon 6th entry from DMI quirks [ Upstream commit 0dd6db359e5f206cbf1dd1fd40dd211588cd2725 ] Somehow the "ThinkPad X1 Carbon 6th" entry ended up twice in the struct dmi_system_id acpi_ec_no_wakeup[] array. Remove one of the entries. Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: huhai <[email protected]> Date: Thu Jun 23 21:21:27 2022 +0800 ACPI: LPSS: Fix missing check in register_device_clock() [ Upstream commit b4f1f61ed5928b1128e60e38d0dffa16966f06dc ] register_device_clock() misses a check for platform_device_register_simple(). Add a check to fix it. Signed-off-by: huhai <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manyi Li <[email protected]> Date: Wed Jun 22 15:42:48 2022 +0800 ACPI: PM: save NVS memory for Lenovo G40-45 [ Upstream commit 4b7ef7b05afcde44142225c184bf43a0cd9e2178 ] [821d6f0359b0614792ab8e2fb93b503e25a65079] is to make machines produced from 2012 to now not saving NVS region to accelerate S3. But, Lenovo G40-45, a platform released in 2015, still needs NVS memory saving during S3. A quirk is introduced for this platform. Signed-off-by: Manyi Li <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guilherme G. Piccoli <[email protected]> Date: Tue Jun 7 19:24:58 2022 -0300 ACPI: processor/idle: Annotate more functions to live in cpuidle section [ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ] Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") introduced a new text section called cpuidle; with that, we have a mechanism to add idling functions in such section and skip them from nmi_backtrace output, since they're useless and potentially flooding for such report. Happens that inlining might cause some real idle functions to end-up outside of such section; this is currently the case of ACPI processor_idle driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(), hence they stay out of the cpuidle section. Fix that by marking such functions to also live in the cpuidle section. Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") Signed-off-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Auger <[email protected]> Date: Thu Jun 30 11:40:59 2022 +0200 ACPI: VIOT: Fix ACS setup [ Upstream commit 3dcb861dbc6ab101838a1548b1efddd00ca3c3ec ] Currently acpi_viot_init() gets called after the pci device has been scanned and pci_enable_acs() has been called. So pci_request_acs() fails to be taken into account leading to wrong single iommu group topologies when dealing with multi-function root ports for instance. We cannot simply move the acpi_viot_init() earlier, similarly as the IORT init because the VIOT parsing relies on the pci scan. However we can detect VIOT is present earlier and in such a case, request ACS. Introduce a new acpi_viot_early_init() routine that allows to call pci_request_acs() before the scan. While at it, guard the call to pci_request_acs() with #ifdef CONFIG_PCI. Fixes: 3cf485540e7b ("ACPI: Add driver for the VIOT table") Signed-off-by: Eric Auger <[email protected]> Reported-by: Jin Liu <[email protected]> Reviewed-by: Jean-Philippe Brucker <[email protected]> Tested-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Tue Aug 9 14:32:13 2022 -0400 add barriers to buffer_uptodate and set_buffer_uptodate commit d4252071b97d2027d246f6a82cbee4d52f618b47 upstream. Let's have a look at this piece of code in __bread_slow: get_bh(bh); bh->b_end_io = end_buffer_read_sync; submit_bh(REQ_OP_READ, 0, bh); wait_on_buffer(bh); if (buffer_uptodate(bh)) return bh; Neither wait_on_buffer nor buffer_uptodate contain any memory barrier. Consequently, if someone calls sb_bread and then reads the buffer data, the read of buffer data may be executed before wait_on_buffer(bh) on architectures with weak memory ordering and it may return invalid data. Fix this bug by adding a memory barrier to set_buffer_uptodate and an acquire barrier to buffer_uptodate (in a similar way as folio_test_uptodate and folio_mark_uptodate). Signed-off-by: Mikulas Patocka <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Fri Jul 15 09:05:15 2022 +0800 ALSA: bcd2000: Fix a UAF bug on the error path of probing commit ffb2759df7efbc00187bfd9d1072434a13a54139 upstream. When the driver fails in snd_card_register() at probe time, it will free the 'bcd2k->midi_out_urb' before killing it, which may cause a UAF bug. The following log can reveal it: [ 50.727020] BUG: KASAN: use-after-free in bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] [ 50.727623] Read of size 8 at addr ffff88810fab0e88 by task swapper/4/0 [ 50.729530] Call Trace: [ 50.732899] bcd2000_input_complete+0x1f1/0x2e0 [snd_bcd2000] Fix this by adding usb_kill_urb() before usb_free_urb(). Fixes: b47a22290d58 ("ALSA: MIDI driver for Behringer BCD2000 USB device") Signed-off-by: Zheyu Ma <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Allen Ballway <[email protected]> Date: Wed Aug 10 15:27:22 2022 +0000 ALSA: hda/cirrus - support for iMac 12,1 model commit 74bba640d69914cf832b87f6bbb700e5ba430672 upstream. The 12,1 model requires the same configuration as the 12,2 model to enable headphones but has a different codec SSID. Adds 12,1 SSID for matching quirk. [ re-sorted in SSID order by tiwai ] Signed-off-by: Allen Ballway <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/20220810152701.1.I902c2e591bbf8de9acb649d1322fa1f291849266@changeid Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Meng Tang <[email protected]> Date: Mon Aug 8 15:34:06 2022 +0800 ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model commit f83bb2592482fe94c6eea07a8121763c80f36ce5 upstream. There is another LENOVO 20149 (Type1Sku0) Notebook model with CX20590, the device PCI SSID is 17aa:3977, which headphones are not responding, that requires the quirk CXT_PINCFG_LENOVO_NOTEBOOK. Add the corresponding entry to the quirk table. Signed-off-by: Meng Tang <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bedant Patnaik <[email protected]> Date: Tue Aug 9 19:54:55 2022 +0530 ALSA: hda/realtek: Add a quirk for HP OMEN 15 (8786) mute LED commit 30267718fe2d4dbea49015b022f6f1fe16ca31ab upstream. Board ID 8786 seems to be another variant of the Omen 15 that needs ALC285_FIXUP_HP_MUTE_LED for working mute LED. Signed-off-by: Bedant Patnaik <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Meng Tang <[email protected]> Date: Fri Aug 5 15:45:34 2022 +0800 ALSA: hda/realtek: Add quirk for another Asus K42JZ model commit f882c4bef9cb914d9f7be171afb10ed26536bfa7 upstream. There is another Asus K42JZ model with the PCI SSID 1043:1313 that requires the quirk ALC269VB_FIXUP_ASUS_MIC_NO_PRESENCE. Add the corresponding entry to the quirk table. Signed-off-by: Meng Tang <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tim Crawford <[email protected]> Date: Sat Jul 30 21:22:43 2022 -0600 ALSA: hda/realtek: Add quirk for Clevo NV45PZ commit be561ffad708f0cee18aee4231f80ffafaf7a419 upstream. Fixes headset detection on Clevo NV45PZ. Signed-off-by: Tim Crawford <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ivan Hasenkampf <[email protected]> Date: Wed Aug 3 18:40:01 2022 +0200 ALSA: hda/realtek: Add quirk for HP Spectre x360 15-eb0xxx commit 24df5428ef9d1ca1edd54eca7eb667110f2dfae3 upstream. Fixes speaker output on HP Spectre x360 15-eb0xxx [ re-sorted in SSID order by tiwai ] Signed-off-by: Ivan Hasenkampf <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Fri Jul 22 16:39:48 2022 +0200 ALSA: usb-audio: Add quirk for Behringer UMC202HD commit e086c37f876fd1f551e2b4f9be97d4a1923cd219 upstream. Just like other Behringer models, UMC202HD (USB ID 1397:0507) requires the quirk for the stable streaming, too. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215934 Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liam R. Howlett <[email protected]> Date: Mon Jun 20 21:09:09 2022 -0400 android: binder: stop saving a pointer to the VMA [ Upstream commit a43cfc87caaf46710c8027a8c23b8a55f1078f19 ] Do not record a pointer to a VMA outside of the mmap_lock for later use. This is unsafe and there are a number of failure paths *after* the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, change the binder_alloc struct to record the start address of the VMA and use vma_lookup() to get the vma when needed. Add lockdep mmap_lock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smp_wmb()/smp_rmb() was not necessary. [[email protected]: fix drivers/android/binder_alloc_selftest.c] Link: https://lkml.kernel.org/r/20220621140212.vpkio64idahetbyf@revolver Fixes: da1b9564e85b ("android: binder: fix the race mmap and alloc_new_buf_locked") Reported-by: [email protected] Signed-off-by: Liam R. Howlett <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Christian Brauner (Microsoft) <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Hridya Valsaraju <[email protected]> Cc: Joel Fernandes <[email protected]> Cc: Martijn Coenen <[email protected]> Cc: Suren Baghdasaryan <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Rutland <[email protected]> Date: Wed May 11 14:17:32 2022 +0100 arch: make TRACE_IRQFLAGS_NMI_SUPPORT generic [ Upstream commit 4510bffb4d0246cdcc1f14c7367c026b807a862d ] On most architectures, IRQ flag tracing is disabled in NMI context, and architectures need to define and select TRACE_IRQFLAGS_NMI_SUPPORT in order to enable this. Commit: 859d069ee1ddd878 ("lockdep: Prepare for NMI IRQ state tracking") Permitted IRQ flag tracing in NMI context, allowing lockdep to work in NMI context where an architecture had suitable entry logic. At the time, most architectures did not have such suitable entry logic, and this broke lockdep on such architectures. Thus, this was partially disabled in commit: ed00495333ccc80f ("locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs") ... with architectures needing to select TRACE_IRQFLAGS_NMI_SUPPORT to enable IRQ flag tracing in NMI context. Currently TRACE_IRQFLAGS_NMI_SUPPORT is defined under arch/x86/Kconfig.debug. Move it to arch/Kconfig so architectures can select it without having to provide their own definition. Since the regular TRACE_IRQFLAGS_SUPPORT is selected by arch/x86/Kconfig, the select of TRACE_IRQFLAGS_NMI_SUPPORT is moved there too. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Peter Zijlstra (Intel) <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexandru Elisei <[email protected]> Date: Fri Jun 17 12:13:32 2022 +0100 arm64: cpufeature: Allow different PMU versions in ID_DFR0_EL1 [ Upstream commit 506506cad3947b942425b119ffa2b06715d5d804 ] Commit b20d1ba3cf4b ("arm64: cpufeature: allow for version discrepancy in PMU implementations") made it possible to run Linux on a machine with PMUs with different versions without tainting the kernel. The patch relaxed the restriction only for the ID_AA64DFR0_EL1.PMUVer field, and missed doing the same for ID_DFR0_EL1.PerfMon , which also reports the PMU version, but for the AArch32 state. For example, with Linux running on two clusters with different PMU versions, the kernel is tainted when bringing up secondaries with the following message: [ 0.097027] smp: Bringing up secondary CPUs ... [..] [ 0.142805] Detected PIPT I-cache on CPU4 [ 0.142805] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_DFR0_EL1. Boot CPU: 0x00000004011088, CPU4: 0x00000005011088 [ 0.143555] CPU features: Unsupported CPU feature variation detected. [ 0.143702] GICv3: CPU4: found redistributor 10000 region 0:0x000000002f180000 [ 0.143702] GICv3: CPU4: using allocated LPI pending table @0x00000008800d0000 [ 0.144888] CPU4: Booted secondary processor 0x0000010000 [0x410fd0f0] The boot CPU implements FEAT_PMUv3p1 (ID_DFR0_EL1.PerfMon, bits 27:24, is 0b0100), but CPU4, part of the other cluster, implements FEAT_PMUv3p4 (ID_DFR0_EL1.PerfMon = 0b0101). Treat the PerfMon field as FTR_NONSTRICT and FTR_EXACT to pass the sanity check and to match how PMUVer is treated for the 64bit ID register. Fixes: b20d1ba3cf4b ("arm64: cpufeature: allow for version discrepancy in PMU implementations") Signed-off-by: Alexandru Elisei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Francis Laniel <[email protected]> Date: Wed Jun 8 17:24:46 2022 +0100 arm64: Do not forget syscall when starting a new thread. [ Upstream commit de6921856f99c11d3986c6702d851e1328d4f7f6 ] Enable tracing of the execve*() system calls with the syscalls:sys_exit_execve tracepoint by removing the call to forget_syscall() when starting a new thread and preserving the value of regs->syscallno across exec. Signed-off-by: Francis Laniel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Samuel Holland <[email protected]> Date: Sat Jul 2 08:28:15 2022 -0500 arm64: dts: allwinner: a64: orangepi-win: Fix LED node name [ Upstream commit b8eb2df19fbf97aa1e950cf491232c2e3bef8357 ] "status" does not match any pattern in the gpio-leds binding. Rename the node to the preferred pattern. This fixes a `make dtbs_check` error. Signed-off-by: Samuel Holland <[email protected]> Reviewed-by: Jernej Skrabec <[email protected]> Signed-off-by: Jernej Skrabec <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nick Hainke <[email protected]> Date: Thu Jun 30 13:16:57 2022 +0200 arm64: dts: mt7622: fix BPI-R64 WPS button [ Upstream commit c98e6e683632386a3bd284acda4342e68aec4c41 ] The bananapi R64 (BPI-R64) experiences wrong WPS button signals. In OpenWrt pushing the WPS button while powering on the device will set it to recovery mode. Currently, this also happens without any user interaction. In particular, the wrong signals appear while booting the device or restarting it, e.g. after doing a system upgrade. If the device is in recovery mode the user needs to manually power cycle or restart it. The official BPI-R64 sources set the WPS button to GPIO_ACTIVE_LOW in the device tree. This setting seems to suppress the unwanted WPS button press signals. So this commit changes the button from GPIO_ACTIVE_HIGH to GPIO_ACTIVE_LOW. The official BPI-R64 sources can be found on https://github.com/BPI-SINOVOIP/BPI-R64-openwrt Fixes: 0b6286dd96c0 ("arm64: dts: mt7622: add bananapi BPI-R64 board") Suggested-by: INAGAKI Hiroshi <[email protected]> Signed-off-by: Nick Hainke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: NÃcolas F. R. A. Prado <[email protected]> Date: Fri Jun 17 19:31:50 2022 -0400 arm64: dts: mt8192: Fix idle-states entry-method [ Upstream commit 2e599740f7e423ee89fb027896cb2635dd43784f ] The entry-method property of the idle-states node should be "psci" as described in the idle-states binding, since this is already the value of enable-method in the CPU nodes. Fix it to get rid of a dtbs_check warning. Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states") Signed-off-by: NÃcolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: NÃcolas F. R. A. Prado <[email protected]> Date: Fri Jun 17 19:31:49 2022 -0400 arm64: dts: mt8192: Fix idle-states nodes naming scheme [ Upstream commit 399e23ad51caaf62400a531c9268ad3c453c3d76 ] Tweak the name of the idle-states subnodes so that they follow the binding pattern, getting rid of dtbs_check warnings. Only the usage of "-" in the name was necessary, but "off" was also exchanged for "sleep" since that seems to be a more common wording in other dts files. Fixes: 9260918d3a4f ("arm64: dts: mt8192: Add cpu-idle-states") Signed-off-by: NÃcolas F. R. A. Prado <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Matthias Brugger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Tue Jun 21 14:06:42 2022 +0200 arm64: dts: qcom: ipq8074: fix NAND node name [ Upstream commit b39961659ffc3c3a9e3d0d43b0476547b5f35d49 ] Per schema it should be nand-controller@79b0000 instead of nand@79b0000. Fix it to match nand-controller.yaml requirements. Signed-off-by: Robert Marko <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sireesh Kodali <[email protected]> Date: Thu May 26 19:47:40 2022 +0530 arm64: dts: qcom: msm8916: Fix typo in pronto remoteproc node [ Upstream commit 5458d6f2827cd30218570f266b8d238417461f2f ] The smem-state properties for the pronto node were incorrectly labelled, reading `qcom,state*` rather than `qcom,smem-state*`. Fix that, allowing the stop state to be used. Fixes: 88106096cbf8 ("ARM: dts: msm8916: Add and enable wcnss node") Signed-off-by: Sireesh Kodali <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Stephan Gerhold <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sumit Garg <[email protected]> Date: Mon Jul 11 14:00:38 2022 +0530 arm64: dts: qcom: qcs404: Fix incorrect USB2 PHYs assignment [ Upstream commit 58577966a42fc0b660b5e2c7c9e5a2241363ea83 ] Currently the DT for QCS404 SoC has setup for 2 USB2 PHYs with one each assigned to USB3 controller and USB2 controller. This assignment is incorrect which only works by luck: as when each USB HCI comes up it configures the *other* controllers PHY which is enough to make them happy. If, for any reason, we were to disable one of the controllers then both would stop working. This was a difficult inconsistency to be caught which was found while trying to enable USB support in u-boot. So with all the required drivers ported to u-boot, I couldn't get the same USB storage device enumerated in u-boot which was being enumerated fine by the kernel. The root cause of the problem came out to be that I wasn't enabling USB2 PHY: "usb2_phy_prim" in u-boot. Then I realised that via simply disabling the same USB2 PHY currently assigned to USB2 host controller in the kernel disabled enumeration for USB3 host controller as well. So fix this inconsistency by correctly assigning USB2 PHYs. Fixes: 9375e7d719b3 ("arm64: dts: qcom: qcs404: Add USB devices and PHYs") Signed-off-by: Sumit Garg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Stephen Boyd <[email protected]> Date: Tue May 17 12:33:07 2022 -0700 arm64: dts: qcom: sc7180: Remove ipa_fw_mem node on trogdor [ Upstream commit e60414644cf3a703e10ed4429c15263095945ffe ] We don't use this carveout on trogdor boards, and having it defined in the sc7180 SoC file causes an overlap message to be printed at boot. OF: reserved mem: OVERLAP DETECTED! memory@86000000 (0x0000000086000000--0x000000008ec00000) overlaps with memory@8b700000 (0x000000008b700000--0x000000008b710000) Delete the node in the trogdor dtsi file to fix the overlap problem and remove the error message. Cc: Alex Elder <[email protected]> Cc: Matthias Kaehlcke <[email protected]> Fixes: 310b266655a3 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Alex Elder <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat May 21 23:27:00 2022 +0300 arm64: dts: qcom: sdm630: disable GPU by default [ Upstream commit 1c047919763b4548381d1ab3320af1df66ab83df ] The SoC's device tree file disables gpucc and adreno's SMMU by default. So let's disable the GPU too. Moreover it looks like SMMU might be not usable without additional patches (which means that GPU is unusable too). No board uses GPU at this moment. Fixes: 5cf69dcbec8b ("arm64: dts: qcom: sdm630: Add Adreno 508 GPU configuration") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat May 21 23:27:04 2022 +0300 arm64: dts: qcom: sdm630: fix gpu's interconnect path [ Upstream commit 3cd1c4f41d64a40ea6bc4575ae28e37542123d77 ] ICC path for the GPU incorrectly states <&gnoc 1 &bimc 5>, which is a path from SLAVE_GNOC_BIMC to SLAVE_EBI. According to the downstream kernel sources, the GPU uses MASTER_OXILI here, which is equivalent to <&bimc 1 ...>. While we are at it, use defined names instead of the numbers for this interconnect path. Fixes: 5cf69dcbec8b ("arm64: dts: qcom: sdm630: Add Adreno 508 GPU configuration") Reported-by: Marijn Suijten <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat May 21 23:27:01 2022 +0300 arm64: dts: qcom: sdm630: fix the qusb2phy ref clock [ Upstream commit 924bbd8dd60e094344711c3526a5b308d71dc008 ] According to the downstram DT file, the qusb2phy ref clock should be GCC_RX0_USB2_CLKREF_CLK, not GCC_RX1_USB2_CLKREF_CLK. Fixes: c65a4ed2ea8b ("arm64: dts: qcom: sdm630: Add USB configuration") Cc: Konrad Dybcio <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat May 21 23:27:05 2022 +0300 arm64: dts: qcom: sdm636-sony-xperia-ganges-mermaid: correct sdc2 pinconf [ Upstream commit 3a04cec9cba393abfe70fc62e523f381c9baec2e ] Fix the device tree node in the &sdc2_state_on override. The sdm630 uses 'clk' rather than 'pinconf-clk'. Fixes: 4c1d849ec047 ("arm64: dts: qcom: sdm630-xperia: Retire sdm630-sony-xperia-ganges.dtsi") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Marijn Suijten <[email protected]> Date: Sun May 8 12:03:34 2022 +0200 arm64: dts: qcom: sm6125: Append -state suffix to pinctrl nodes [ Upstream commit cbfb5668aece448877fa7826cde81c9d06f4a4ac ] According to qcom,sm6125-pinctrl.yaml all nodes inside the tlmm must be suffixed by -state: qcom/sm6125-sony-xperia-seine-pdx201.dtb: pinctrl@500000: 'sdc2-off', 'sdc2-on' do not match any of the regexes: '-state$', 'pinctrl-[0-9]+' The label names have been updated to match, going from sdc2_state_X to sdc2_X_state. Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125") Fixes: 82e1783890b7 ("arm64: dts: qcom: sm6125: Add support for Sony Xperia 10II") Signed-off-by: Marijn Suijten <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Marijn Suijten <[email protected]> Date: Sun May 8 12:03:33 2022 +0200 arm64: dts: qcom: sm6125: Move sdc2 pinctrl from seine-pdx201 to sm6125 [ Upstream commit 6990640a93ba4e76dd62ca3ea1082a7354db09d7 ] Both the sdc2-on and sdc2-off pinctrl nodes are used by the sdhci@4784000 node in sm6125.dtsi. Surprisingly sdc2-off is defined in sm6125, yet its sdc2-on counterpart is only defined in board-specific DT for the Sony Seine PDX201 board/device resulting in an "undefined label &sdc2_state_on" error if sm6125.dtsi were included elsewhere. This sm6125 base dtsi should not rely on externally defined labels; the properties referencing it should then also be written externally. Since the sdc2-on pin configuration is board-independent just like sdc2-off, move it from seine-pdx201.dts into sm6125.dtsi. The SDCard-detect pin (gpio98) is however board-specific, and remains as an overwrite in seine-pdx201.dts for both the on and off state. As a drive-by cleanup, reorder bias- and drive-strength properties. Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125") Fixes: 82e1783890b7 ("arm64: dts: qcom: sm6125: Add support for Sony Xperia 10II") Signed-off-by: Marijn Suijten <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 5 13:40:20 2022 +0200 arm64: dts: qcom: sm8250: add missing PCIe PHY clock-cells [ Upstream commit d9fd162ce764c227fcfd4242f6c1639895a9481f ] Add the missing '#clock-cells' properties to the PCIe QMP PHY nodes. Signed-off-by: Johan Hovold <[email protected]> Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Wed May 11 12:14:06 2022 +0200 arm64: dts: renesas: beacon: Fix regulator node names [ Upstream commit 7512af9f78dedea7e04225f665dad6750df7d095 ] Currently there are two nodes named "regulator_camera". This causes the former to be overwritten by the latter. Fix this by renaming them to unique names, using the preferred hyphen instead of an underscore. While at it, update the name of the audio regulator (which was added in the same commit) to use a hyphen. Fixes: a1d8a344f1ca0709 ("arm64: dts: renesas: Introduce r8a774a1-beacon-rzg2m-kit") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/a9ac82bdf108162487289d091c53a9b3de393f13.1652263918.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Wed Jun 15 16:04:26 2022 +0200 arm64: dts: renesas: Fix thermal-sensors on single-zone sensors [ Upstream commit 62e8a53431145e06e503b71625a34eaa87b72b2c ] "make dtbs_check": arch/arm64/boot/dts/renesas/r8a774c0-cat874.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[74], [0]] is too long arch/arm64/boot/dts/renesas/r8a774c0-ek874.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[79], [0]] is too long arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[82], [0]] is too long arch/arm64/boot/dts/renesas/r8a774c0-ek874-mipi-2.1.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[87], [0]] is too long arch/arm64/boot/dts/renesas/r8a77990-ebisu.dtb: thermal-zones: cpu-thermal:thermal-sensors: [[105], [0]] is too long From schema: Documentation/devicetree/bindings/thermal/thermal-zones.yaml Indeed, the thermal sensors on R-Car E3 and RZ/G2E support only a single zone, hence #thermal-sensor-cells = <0>. Fix this by dropping the bogus zero cell from the thermal sensor specifiers. Fixes: 8fa7d18f9ee2dc20 ("arm64: dts: renesas: r8a77990: Create thermal zone to support IPA") Fixes: 8438bfda9d768157 ("arm64: dts: renesas: r8a774c0: Create thermal zone to support IPA") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Niklas Söderlund <[email protected]> Link: https://lore.kernel.org/r/28b812fdd1fc3698311fac984ab8b91d3d655c1c.1655301684.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <[email protected]>
Author: Kunihiko Hayashi <[email protected]> Date: Tue Aug 2 22:36:47 2022 +0900 arm64: dts: uniphier: Fix USB interrupts for PXs3 SoC commit fe17b91a7777df140d0f1433991da67ba658796c upstream. An interrupt for USB device are shared with USB host. Set interrupt-names property to common "dwc_usb3" instead of "host" and "peripheral". Cc: [email protected] Fixes: d7b9beb830d7 ("arm64: dts: uniphier: Add USB3 controller nodes") Reported-by: Ryuta NAKANISHI <[email protected]> Signed-off-by: Kunihiko Hayashi <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: haibinzhang (å¼ æµ·æ–Œ) <[email protected]> Date: Sat Jul 2 05:43:19 2022 +0000 arm64: fix oops in concurrently setting insn_emulation sysctls [ Upstream commit af483947d472eccb79e42059276c4deed76f99a6 ] emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing. Co-developed-by: hewenliang <[email protected]> Signed-off-by: hewenliang <[email protected]> Signed-off-by: Haibin Zhang <[email protected]> Reviewed-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Catalin Marinas <[email protected]> Date: Fri Jun 10 16:21:41 2022 +0100 arm64: kasan: Revert "arm64: mte: reset the page tag in page->flags" [ Upstream commit 20794545c14692094a882d2221c251c4573e6adf ] This reverts commit e5b8d9218951e59df986f627ec93569a0d22149b. Pages mapped in user-space with PROT_MTE have the allocation tags either zeroed or copied/restored to some user values. In order for the kernel to access such pages via page_address(), resetting the tag in page->flags was necessary. This tag resetting was deferred to set_pte_at() -> mte_sync_page_tags() but it can race with another CPU reading the flags (via page_to_virt()): P0 (mte_sync_page_tags): P1 (memcpy from virt_to_page): Rflags!=0xff Wflags=0xff DMB (doesn't help) Wtags=0 Rtags=0 // fault Since now the post_alloc_hook() function resets the page->flags tag when unpoisoning is skipped for user pages (including the __GFP_ZEROTAGS case), revert the arm64 commit calling page_kasan_tag_reset(). Signed-off-by: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Peter Collingbourne <[email protected]> Reviewed-by: Vincenzo Frascino <[email protected]> Acked-by: Andrey Konovalov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Rutland <[email protected]> Date: Wed May 11 14:17:33 2022 +0100 arm64: select TRACE_IRQFLAGS_NMI_SUPPORT [ Upstream commit 3381da254fab37ba08c4b7c4f19b4ee28b1a27ec ] Due to an oversight, on arm64 lockdep IRQ state tracking doesn't work as intended in NMI context. This demonstrably results in bogus warnings from lockdep, and in theory could mask a variety of issues. On arm64, we've consistently tracked IRQ flag state for NMIs (and saved/restored the state of the interrupted context) since commit: f0cd5ac1e4c53cb6 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") That commit fixed most lockdep issues with NMI by virtue of the save/restore of the lockdep state of the interrupted context. However, for lockdep IRQ state tracking to consistently take effect in NMI context it has been necessary to select TRACE_IRQFLAGS_NMI_SUPPORT since commit: ed00495333ccc80f ("locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs") As arm64 does not select TRACE_IRQFLAGS_NMI_SUPPORT, this means that the lockdep state can be stale in NMI context, and some uses of that state can consume stale data. When an NMI is taken arm64 entry code will call arm64_enter_nmi(). This will enter NMI context via __nmi_enter() before calling lockdep_hardirqs_off() to inform lockdep that IRQs have been masked. Where TRACE_IRQFLAGS_NMI_SUPPORT is not selected, lockdep_hardirqs_off() will not update lockdep state if called in NMI context. Thus if IRQs were enabled in the original context, lockdep will continue to believe that IRQs are enabled despite the call to lockdep_hardirqs_off(). However, the lockdep_assert_*() checks do take effect in NMI context, and will consume the stale lockdep state. If an NMI is taken from a context which had IRQs enabled, and during the handling of the NMI something calls lockdep_assert_irqs_disabled(), this will result in a spurious warning based upon the stale lockdep state. This can be seen when using perf with GICv3 pseudo-NMIs. Within the perf NMI handler we may attempt a uaccess to record the userspace callchain, and is this faults the el1_abort() call in the nested context will call exit_to_kernel_mode() when returning, which has a lockdep_assert_irqs_disabled() assertion: | # ./perf record -a -g sh | ------------[ cut here ]------------ | WARNING: CPU: 0 PID: 164 at arch/arm64/kernel/entry-common.c:73 exit_to_kernel_mode+0x118/0x1ac | Modules linked in: | CPU: 0 PID: 164 Comm: perf Not tainted 5.18.0-rc5 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 004003c5 (nzcv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : exit_to_kernel_mode+0x118/0x1ac | lr : el1_abort+0x80/0xbc | sp : ffff8000080039f0 | pmr_save: 000000f0 | x29: ffff8000080039f0 x28: ffff6831054e4980 x27: ffff683103adb400 | x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000001 | x23: 00000000804000c5 x22: 00000000000000c0 x21: 0000000000000001 | x20: ffffbd51e635ec44 x19: ffff800008003a60 x18: 0000000000000000 | x17: ffffaadf98d23000 x16: ffff800008004000 x15: 0000ffffd14f25c0 | x14: 0000000000000000 x13: 00000000000018eb x12: 0000000000000040 | x11: 000000000000001e x10: 000000002b820020 x9 : 0000000100110000 | x8 : 000000000045cac0 x7 : 0000ffffd14f25c0 x6 : ffffbd51e639b000 | x5 : 00000000000003e5 x4 : ffffbd51e58543b0 x3 : 0000000000000001 | x2 : ffffaadf98d23000 x1 : ffff6831054e4980 x0 : 0000000100110000 | Call trace: | exit_to_kernel_mode+0x118/0x1ac | el1_abort+0x80/0xbc | el1h_64_sync_handler+0xa4/0xd0 | el1h_64_sync+0x74/0x78 | __arch_copy_from_user+0xa4/0x230 | get_perf_callchain+0x134/0x1e4 | perf_callchain+0x7c/0xa0 | perf_prepare_sample+0x414/0x660 | perf_event_output_forward+0x80/0x180 | __perf_event_overflow+0x70/0x13c | perf_event_overflow+0x1c/0x30 | armv8pmu_handle_irq+0xe8/0x160 | armpmu_dispatch_irq+0x2c/0x70 | handle_percpu_devid_fasteoi_nmi+0x7c/0xbc | generic_handle_domain_nmi+0x3c/0x60 | gic_handle_irq+0x1dc/0x310 | call_on_irq_stack+0x2c/0x54 | do_interrupt_handler+0x80/0x94 | el1_interrupt+0xb0/0xe4 | el1h_64_irq_handler+0x18/0x24 | el1h_64_irq+0x74/0x78 | lockdep_hardirqs_off+0x50/0x120 | trace_hardirqs_off+0x38/0x214 | _raw_spin_lock_irq+0x98/0xa0 | pipe_read+0x1f8/0x404 | new_sync_read+0x140/0x150 | vfs_read+0x190/0x1dc | ksys_read+0xdc/0xfc | __arm64_sys_read+0x20/0x30 | invoke_syscall+0x48/0x114 | el0_svc_common.constprop.0+0x158/0x17c | do_el0_svc+0x28/0x90 | el0_svc+0x60/0x150 | el0t_64_sync_handler+0xa4/0x130 | el0t_64_sync+0x19c/0x1a0 | irq event stamp: 483 | hardirqs last enabled at (483): [<ffffbd51e636aa24>] _raw_spin_unlock_irqrestore+0xa4/0xb0 | hardirqs last disabled at (482): [<ffffbd51e636acd0>] _raw_spin_lock_irqsave+0xb0/0xb4 | softirqs last enabled at (468): [<ffffbd51e5216f58>] put_cpu_fpsimd_context+0x28/0x70 | softirqs last disabled at (466): [<ffffbd51e5216ed4>] get_cpu_fpsimd_context+0x0/0x5c | ---[ end trace 0000000000000000 ]--- Note that as lockdep_assert_irqs_disabled() uses WARN_ON_ONCE(), and this uses a BRK, the warning is logged with the real PSTATE at the time of the warning, which clearly has DAIF.I set, meaning IRQs (and pseudo-NMIs) were definitely masked and the warning is spurious. Fix this by selecting TRACE_IRQFLAGS_NMI_SUPPORT such that the existing entry tracking takes effect, as we had originally intended when the arm64 entry code was fixed for transitions to/from NMI. Arguably the lockdep_assert_*() functions should have the same NMI checks as the rest of the code to prevent spurious warnings when TRACE_IRQFLAGS_NMI_SUPPORT is not selected, but the real fix for any architecture is to explicitly handle the transitions to/from NMI in the entry code. Fixes: f0cd5ac1e4c5 ("arm64: entry: fix NMI {user, kernel}->kernel transitions") Signed-off-by: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Peter Zijlstra (Intel) <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Deacon <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tamás Szűcs <[email protected]> Date: Sun Jun 12 14:59:45 2022 +0000 arm64: tegra: Fix SDMMC1 CD on P2888 [ Upstream commit b415bb7c976f1d595ed752001c0938f702645dab ] Hook SDMMC1 CD up with CVM GPIO02 (SOC_GPIO11) used for card detection on J4 (uSD socket) on the carrier. Fixes: ef633bfc21e9 ("arm64: tegra: Enable card detect for SD card on P2888") Signed-off-by: Tamás Szűcs <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thierry Reding <[email protected]> Date: Fri Nov 12 13:35:37 2021 +0100 arm64: tegra: Fixup SYSRAM references [ Upstream commit 7fa307524a4d721d4a04523018509882c5414e72 ] The json-schema bindings for SRAM expect the nodes to be called "sram" rather than "sysram" or "shmem". Furthermore, place the brackets around the SYSRAM references such that a two-element array is created rather than a two-element array nested in a single-element array. This is not relevant for device tree itself, but allows the nodes to be properly validated against json-schema bindings. Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikko Perttunen <[email protected]> Date: Wed Jun 22 16:23:00 2022 +0300 arm64: tegra: Mark BPMP channels as no-memory-wc [ Upstream commit 61192a9d8a6367ae1b8234876941b037910a2459 ] The Tegra SYSRAM contains regions access to which is restricted to certain hardware blocks on the system, and speculative accesses to those will cause issues. Patch 'misc: sram: Only map reserved areas in Tegra SYSRAM' attempted to resolve this by only mapping the regions specified in the device tree on the assumption that there are no such restricted areas within the 64K-aligned area of memory that contains the memory we wish to map. Turns out this assumption is wrong, as there are such areas above the 4K pages described in the device trees. As such, we need to use the bigger hammer that is no-memory-wc, which causes the memory to be mapped as Device memory to which speculative accesses are disallowed. As such, the previous patch in the series, 'firmware: tegra: bpmp: do only aligned access to IPC memory area', is required with this patch to make the BPMP driver only issue aligned memory accesses as those are also required with Device memory. Fixes: fec29bf04994 ("misc: sram: Only map reserved areas in Tegra SYSRAM") Signed-off-by: Mikko Perttunen <[email protected]> Reviewed-by: Yousaf Kaukab <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikko Perttunen <[email protected]> Date: Fri Nov 12 13:35:39 2021 +0100 arm64: tegra: Update Tegra234 BPMP channel addresses [ Upstream commit 98094be152d34f8014ca67fbdc210e5261c4b09d ] On final Tegra234 systems, shared memory for communication with BPMP is located at offset 0x70000 in SYSRAM. Signed-off-by: Mikko Perttunen <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu May 26 12:13:25 2022 +0400 ARM: bcm: Fix refcount leak in bcm_kona_smc_init [ Upstream commit cb23389a2458c2e4bfd6c86a513cbbe1c4d35e76 ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: b8eb35fd594a ("ARM: bcm281xx: Add L2 cache enable code") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun May 29 12:49:25 2022 +0200 ARM: dts: ast2500-evb: fix board compatible [ Upstream commit 30b276fca5c0644f3cb17bceb1bd6a626c670184 ] The AST2500 EVB board should have dedicated compatible. Fixes: 02440622656d ("arm/dst: Add Aspeed ast2500 device tree") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun May 29 12:49:27 2022 +0200 ARM: dts: ast2600-evb-a1: fix board compatible [ Upstream commit 33c39140cc298e0d4e36083cb9a665a837773a60 ] The AST2600 EVB A1 board should have dedicated compatible. Fixes: a72955180372 ("ARM: dts: aspeed: ast2600evb: Add dts file for A1 and A0") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sun May 29 12:49:26 2022 +0200 ARM: dts: ast2600-evb: fix board compatible [ Upstream commit aa5e06208500a0db41473caebdee5a2e81d5a277 ] The AST2600 EVB board should have dedicated compatible. Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Lamparter <[email protected]> Date: Sat Jun 18 00:00:29 2022 +0200 ARM: dts: BCM5301X: Add DT for Meraki MR26 [ Upstream commit 935327a73553001f8d81375c76985d05f604507f ] Meraki MR26 is an EOL wireless access point featuring a PoE ethernet port and two dual-band 3x3 MIMO 802.11n radios and 1x1 dual-band WIFI dedicated to scanning. Thank you Amir for the unit and PSU. Hardware info: SOC : Broadcom BCM53015A1KFEBG (dual-core Cortex-A9 CPU at 800 MHz) RAM : SK Hynix Inc. H5TQ1G63EFR, 1 GBit DDR3 SDRAM = 128 MiB NAND : Spansion S34ML01G100TF100, 1 GBit SLC NAND Flash = 128 MiB ETH : 1 GBit Ethernet Port - PoE (TPS23754 PoE Interface) WIFI0 : Broadcom BCM43431KMLG, BCM43431 802.11 abgn (3x3:3) WIFI1 : Broadcom BCM43431KMLG, BCM43431 802.11 abgn (3x3:3) WIFI2 : Broadcom BCM43428 "Air Marshal" 802.11 abgn (1x1:1) BUTTON: One reset key behind a small hole next to the Ethernet Port LEDS : One amber (fault), one white (indicator) LED, separate RGB-LED MISC : Atmel AT24C64 8KiB EEPROM i2c : Ti INA219 26V, 12-bit, i2c output current/voltage/power monitor SERIAL: WARNING: The serial port needs a TTL/RS-232 3V3 level converter! The Serial setting is 115200-8-N-1. The board has a populated right angle 1x4 0.1" pinheader. The pinout is: VCC (next to J3, has the pin 1 indicator), RX, TX, GND. Odd stuff: - uboot does not support lzma compression, but gzip'd uImage/DTB work. - uboot claims to support FIT, but fails to pass the DTB to the kernel. Appending the dtb after the kernel image works. - RGB-controller is supported through an external userspace program. - The ubi partition contains a "board-config" volume. It stores the MAC Address (0x66 in binary) and Serial No. (0x7c alpha-numerical). - SoC's temperature sensor always reports that it is on fire. This causes the system to immediately shutdown! Looking at reported "418 degree Celsius" suggests that this sensor is not working. WIFI: b43 is able to initialize all three WIFIs @ 802.11bg. | b43-phy0: Broadcom 43431 WLAN found (core revision 29) | bcma-pci-bridge 0000:01:00.0: bus1: Switched to core: 0x812 | b43-phy0: Found PHY: Analog 9, Type 7 (HT), Revision 1 | b43-phy0: Found Radio: Manuf 0x17F, ID 0x2059, Revision 0, Version 1 | b43-phy0 warning: 5 GHz band is unsupported on this PHY | b43-phy1: Broadcom 43431 WLAN found (core revision 29) | bcma-pci-bridge 0001:01:00.0: bus2: Switched to core: 0x812 | b43-phy1: Found PHY: Analog 9, Type 7 (HT), Revision 1 | b43-phy1: Found Radio: Manuf 0x17F, ID 0x2059, Revision 0, Version 1 | b43-phy1 warning: 5 GHz band is unsupported on this PHY | b43-phy2: Broadcom 43228 WLAN found (core revision 30) | bcma-pci-bridge 0002:01:00.0: bus3: Switched to core: 0x812 | b43-phy2: Found PHY: Analog 9, Type 4 (N), Revision 16 | b43-phy2: Found Radio: Manuf 0x17F, ID 0x2057, Revision 9, Version 1 | Broadcom 43xx driver loaded [ Features: NL ] Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Mon Jun 13 14:33:51 2022 +0200 ARM: dts: imx6ul: add missing properties for sram [ Upstream commit 5655699cf5cff9f4c4ee703792156bdd05d1addf ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Mon Jun 13 14:33:52 2022 +0200 ARM: dts: imx6ul: change operating-points to uint32-matrix [ Upstream commit edb67843983bbdf61b4c8c3c50618003d38bb4ae ] operating-points is a uint32-matrix as per opp-v1.yaml. Change it accordingly. While at it, change fsl,soc-operating-points as well, although there is no bindings file (yet). But they should have the same format. Fixes the dt_binding_check warning: cpu@0: operating-points:0: [696000, 1275000, 528000, 1175000, 396000, 1025000, 198000, 950000] is too long cpu@0: operating-points:0: Additional items are not allowed (528000, 1175000, 396000, 1025000, 198000, 950000 were unexpected) Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Mon Jun 13 14:33:55 2022 +0200 ARM: dts: imx6ul: fix csi node compatible [ Upstream commit e0aca931a2c7c29c88ebf37f9c3cd045e083483d ] "fsl,imx6ul-csi" was never listed as compatible to "fsl,imx7-csi", neither in yaml bindings, nor previous txt binding. Remove the imx7 part. Fixes the dt schema check warning: csi@21c4000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx6ul-csi', 'fsl,imx7-csi'] is too long Additional items are not allowed ('fsl,imx7-csi' was unexpected) 'fsl,imx8mm-csi' was expected Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Mon Jun 13 14:33:53 2022 +0200 ARM: dts: imx6ul: fix keypad compatible [ Upstream commit 7d15e0c9a515494af2e3199741cdac7002928a0e ] According to binding, the compatible shall only contain imx6ul and imx21 compatibles. Fixes the dt_binding_check warning: keypad@20b8000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx6ul-kpp', 'fsl,imx6q-kpp', 'fsl,imx21-kpp'] is too long Additional items are not allowed ('fsl,imx6q-kpp', 'fsl,imx21-kpp' were unexpected) Additional items are not allowed ('fsl,imx21-kpp' was unexpected) 'fsl,imx21-kpp' was expected Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Mon Jun 13 14:33:56 2022 +0200 ARM: dts: imx6ul: fix lcdif node compatible [ Upstream commit 1a884d17ca324531634cce82e9f64c0302bdf7de ] In yaml binding "fsl,imx6ul-lcdif" is listed as compatible to imx6sx-lcdif, but not imx28-lcdif. Change the list accordingly. Fixes the dt_binding_check warning: lcdif@21c8000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx6ul-lcdif', 'fsl,imx28-lcdif'] is too long Additional items are not allowed ('fsl,imx28-lcdif' was unexpected) 'fsl,imx6ul-lcdif' is not one of ['fsl,imx23-lcdif', 'fsl,imx28-lcdif', 'fsl,imx6sx-lcdif'] 'fsl,imx6sx-lcdif' was expected Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Stein <[email protected]> Date: Mon Jun 13 14:33:57 2022 +0200 ARM: dts: imx6ul: fix qspi node compatible [ Upstream commit 0c6cf86e1ab433b2d421880fdd9c6e954f404948 ] imx6ul is not compatible to imx6sx, both have different erratas. Fixes the dt_binding_check warning: spi@21e0000: compatible: 'oneOf' conditional failed, one must be fixed: ['fsl,imx6ul-qspi', 'fsl,imx6sx-qspi'] is too long Additional items are not allowed ('fsl,imx6sx-qspi' was unexpected) 'fsl,imx6ul-qspi' is not one of ['fsl,ls1043a-qspi'] 'fsl,imx6ul-qspi' is not one of ['fsl,imx8mq-qspi'] 'fsl,ls1021a-qspi' was expected 'fsl,imx7d-qspi' was expected Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marcel Ziswiler <[email protected]> Date: Mon May 16 15:47:23 2022 +0200 ARM: dts: imx7d-colibri-emmc: add cpu1 supply [ Upstream commit ba28db60d34271e8a3cf4d7158d71607e8b1e57f ] Each cpu-core is supposed to list its supply separately, add supply for cpu1. Fixes: 2d7401f8632f ("ARM: dts: imx7d: Add cpu1 supply") Signed-off-by: Marcel Ziswiler <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Sun May 22 10:36:18 2022 +0200 ARM: dts: qcom-msm8974: fix irq type on blsp2_uart1 [ Upstream commit ab1489017aa7a9f02e24bee73cf9ec8079cd3909 ] IRQ_TYPE_NONE is invalid, so use the correct interrupt type. Signed-off-by: Luca Weiss <[email protected]> Fixes: b05f82b152c9 ("ARM: dts: qcom: msm8974: Add blsp2_uart7 for bluetooth on sirius") Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Sat May 7 21:49:12 2022 +0200 ARM: dts: qcom: mdm9615: add missing PMIC GPIO reg [ Upstream commit dc590cdc31f636ea15658f1206c3e380a53fb78e ] 'reg' property is required in SSBI children: qcom-mdm9615-wp8548-mangoh-green.dtb: gpio@150: 'reg' is a required property Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi") Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Wed Jun 8 13:27:02 2022 +0200 ARM: dts: qcom: pm8841: add required thermal-sensor-cells [ Upstream commit e2759fa0676c9a32bbddb9aff955b54bb35066ad ] The PM8841 temperature sensor has to define thermal-sensor-cells. Fixes: dab8134ca072 ("ARM: dts: qcom: Add PM8841 functions device nodes") Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Mon May 30 13:38:40 2022 +0530 ARM: dts: qcom: sdx55: Fix the IRQ trigger type for UART [ Upstream commit ae500b351ab0006d933d804a2b7507fe1e98cecc ] The trigger type should be LEVEL_HIGH. So fix it! Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Kunihiko Hayashi <[email protected]> Date: Tue Aug 2 22:36:25 2022 +0900 ARM: dts: uniphier: Fix USB interrupts for PXs2 SoC commit 9b0dc7abb5cc43a2dbf90690c3c6011dcadc574d upstream. An interrupt for USB device are shared with USB host. Set interrupt-names property to common "dwc_usb3" instead of "host" and "peripheral". Cc: [email protected] Fixes: 45be1573ad19 ("ARM: dts: uniphier: Add USB3 controller nodes") Reported-by: Ryuta NAKANISHI <[email protected]> Signed-off-by: Kunihiko Hayashi <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Linus Walleij <[email protected]> Date: Sat Jun 11 22:42:49 2022 +0200 ARM: dts: ux500: Fix Codina accelerometer mounting matrix [ Upstream commit 0b2152e428ab91533a02888ff24e52e788dc4637 ] This was fixed wrong so fix it again. Now verified by using iio-sensor-proxy monitor-sensor test program. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linus Walleij <[email protected]> Date: Sat Jun 11 22:51:38 2022 +0200 ARM: dts: ux500: Fix Gavini accelerometer mounting matrix [ Upstream commit e24c75f02a81d6ddac0072cbd7a03e799c19d558 ] This was fixed wrong so fix it. Now verified by using iio-sensor-proxy monitor-sensor test program. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Russell King (Oracle) <[email protected]> Date: Tue Jul 26 23:51:48 2022 +0100 ARM: findbit: fix overflowing offset [ Upstream commit ec85bd369fd2bfaed6f45dd678706429d4f75b48 ] When offset is larger than the size of the bit array, we should not attempt to access the array as we can perform an access beyond the end of the array. Fix this by changing the pre-condition. Using "cmp r2, r1; bhs ..." covers us for the size == 0 case, since this will always take the branch when r1 is zero, irrespective of the value of r2. This means we can fix this bug without adding any additional code! Tested-by: Guenter Roeck <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Fri Jun 17 22:58:03 2022 +0800 ARM: OMAP2+: display: Fix refcount leak bug [ Upstream commit 50b87a32a79bca6e275918a711fb8cc55e16d739 ] In omapdss_init_fbdev(), of_find_node_by_name() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Signed-off-by: Liang He <[email protected]> Message-Id: <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu May 26 11:37:24 2022 +0400 ARM: OMAP2+: Fix refcount leak in omap3xxx_prm_late_init [ Upstream commit 942228fbf5d4901112178b93d41225be7c0dd9de ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 1e037794f7f0 ("ARM: OMAP3+: PRM: register interrupt information from DT") Signed-off-by: Miaoqian Lin <[email protected]> Message-Id: <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed Jun 1 08:48:58 2022 +0400 ARM: OMAP2+: Fix refcount leak in omapdss_init_of [ Upstream commit 9705db1eff38d6b9114121f9e253746199b759c9 ] omapdss_find_dss_of_node() calls of_find_compatible_node() to get device node. of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in later error path and normal path. Fixes: e0c827aca0730 ("drm/omap: Populate DSS children in omapdss driver") Signed-off-by: Miaoqian Lin <[email protected]> Message-Id: <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Sat Jun 18 10:06:03 2022 +0800 ARM: OMAP2+: pdata-quirks: Fix refcount leak bug [ Upstream commit 5cdbab96bab314c6f2f5e4e8b8a019181328bf5f ] In pdata_quirks_init_clocks(), the loop contains of_find_node_by_name() but without corresponding of_node_put(). Signed-off-by: Liang He <[email protected]> Message-Id: <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ard Biesheuvel <[email protected]> Date: Tue Oct 5 09:15:34 2021 +0200 ARM: remove some dead code [ Upstream commit 08572cd41955166e387d9b4984294d37f8f7526c ] This code appears to be no longer used so let's get rid of it. Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Acked-by: Linus Walleij <[email protected]> Tested-by: Keith Packard <[email protected]> Tested-by: Marc Zyngier <[email protected]> Tested-by: Vladimir Murzin <[email protected]> # ARMv7M Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Fri Jul 1 20:18:04 2022 +0800 ARM: shmobile: rcar-gen2: Increase refcount for new reference [ Upstream commit 75a185fb92e58ccd3670258d8d3b826bd2fa6d29 ] In rcar_gen2_regulator_quirk(), for_each_matching_node_and_match() will automatically increase and decrease the refcount. However, we should call of_node_get() for the new reference created in 'quirk->np'. Besides, we also should call of_node_put() before the 'quirk' being freed. Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Thu Jul 21 22:43:08 2022 +0800 ASoC: audio-graph-card: Add of_node_put() in fail path [ Upstream commit 65fb8e2ef3531a6e950060fca6e551c923fb0f0e ] In asoc_simple_parse_dai(), we should call of_node_put() for the reference returned by of_graph_get_port_parent() in fail path. Fixes: ae30a694da4c ("ASoC: simple-card-utils: add asoc_simple_card_parse_dai()") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Tue May 31 17:47:12 2022 +0800 ASoC: codecs: da7210: add check for i2c_add_driver [ Upstream commit 82fa8f581a954ddeec1602bed9f8b4a09d100e6e ] As i2c_add_driver could return error if fails, it should be better to check the return value. However, if the CONFIG_I2C and CONFIG_SPI_MASTER are both true, the return value of i2c_add_driver will be covered by spi_register_driver. Therefore, it is necessary to add check and return error if fails. Fixes: aa0e25caafb7 ("ASoC: da7210: Add support for spi regmap") Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Kandagatla <[email protected]> Date: Thu Jun 9 12:19:00 2022 +0100 ASoC: codecs: msm8916-wcd-digital: move gains from SX_TLV to S8_TLV [ Upstream commit 5babb012c847beb6c8c7108fd78f650b7a2c6054 ] move all the digital gains form using SX_TLV to S8_TLV, these gains are actually 8 bit gains with 7th signed bit and ranges from -84dB to +40dB rest of the Qualcomm wcd codecs uses these properly. Fixes: ef8a4757a6db ("ASoC: msm8916-wcd-digital: Add sidetone support") Fixes: 150db8c5afa1 ("ASoC: codecs: Add msm8916-wcd digital codec") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Kandagatla <[email protected]> Date: Thu Jun 9 12:19:01 2022 +0100 ASoC: codecs: wcd9335: move gains from SX_TLV to S8_TLV [ Upstream commit 2fbe0953732e06b471cdedbf6f615b84235580d8 ] move all the digital gains form using SX_TLV to S8_TLV, these gains are actually 8 bit gains with 7th signed bit and ranges from -84dB to +40dB rest of the Qualcomm wcd codecs uses these properly. Fixes: 8c4f021d806a ("ASoC: wcd9335: add basic controls") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 17:10:43 2022 +0400 ASoC: cros_ec_codec: Fix refcount leak in cros_ec_codec_platform_probe [ Upstream commit 0a034d93ee929a9ea89f3fa5f1d8492435b9ee6e ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: b6bc07d4360d ("ASoC: cros_ec_codec: support WoV") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Tzung-Bi Shih <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:51 2022 +0800 ASoC: fsl-asoc-card: force cast the asrc_format type [ Upstream commit 6c7b077dad62178c33f9a3ae17f90d6b0bf6e2e5 ] Fix sparse warning: sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl-asoc-card.c:833:45: sparse: got restricted snd_pcm_format_t * Fixes: 859e364302c5 ("ASoC: fsl-asoc-card: Support new property fsl, asrc-format") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:50 2022 +0800 ASoC: fsl_asrc: force cast the asrc_format type [ Upstream commit c49932726de24405d45516b3f8ad2735714fdf05 ] Fix sparse warning: sound/soc/fsl/fsl_asrc.c:1177:60: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_asrc.c:1177:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_asrc.c:1177:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_asrc.c:1200:47: sparse: warning: restricted snd_pcm_format_t degrades to integer Fixes: 4520af41fd21 ("ASoC: fsl_asrc: Support new property fsl,asrc-format") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:52 2022 +0800 ASoC: fsl_easrc: use snd_pcm_format_t type for sample_format [ Upstream commit de27216cf2d645c2fd14e513707bdcd54e5b1de4 ] Fix sparse warning: sound/soc/fsl/fsl_easrc.c:562:33: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:563:34: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:565:38: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:566:39: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:608:33: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:609:34: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:615:40: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:616:41: sparse: warning: restricted snd_pcm_format_t degrades to integer sound/soc/fsl/fsl_easrc.c:1465:51: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1465:51: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1465:51: sparse: got restricted snd_pcm_format_t [usertype] format sound/soc/fsl/fsl_easrc.c:1467:52: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1467:52: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1467:52: sparse: got restricted snd_pcm_format_t [usertype] asrc_format sound/soc/fsl/fsl_easrc.c:1470:52: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1470:52: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1470:52: sparse: got restricted snd_pcm_format_t [usertype] format sound/soc/fsl/fsl_easrc.c:1472:51: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/fsl_easrc.c:1472:51: sparse: expected unsigned int sample_format sound/soc/fsl/fsl_easrc.c:1472:51: sparse: got restricted snd_pcm_format_t [usertype] asrc_format sound/soc/fsl/fsl_easrc.c:1484:41: sparse: warning: incorrect type in argument 2 (different base types) sound/soc/fsl/fsl_easrc.c:1484:41: sparse: expected restricted snd_pcm_format_t [usertype] *in_raw_format sound/soc/fsl/fsl_easrc.c:1484:41: sparse: got unsigned int * sound/soc/fsl/fsl_easrc.c:1485:41: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_easrc.c:1485:41: sparse: expected restricted snd_pcm_format_t [usertype] *out_raw_format sound/soc/fsl/fsl_easrc.c:1485:41: sparse: got unsigned int * sound/soc/fsl/fsl_easrc.c:1937:60: sparse: warning: incorrect type in argument 3 (different base types) sound/soc/fsl/fsl_easrc.c:1937:60: sparse: expected unsigned int [usertype] *out_value sound/soc/fsl/fsl_easrc.c:1937:60: sparse: got restricted snd_pcm_format_t * sound/soc/fsl/fsl_easrc.c:1943:49: sparse: warning: restricted snd_pcm_format_t degrades to integer Fixes: 955ac624058f ("ASoC: fsl_easrc: Add EASRC ASoC CPU DAI drivers") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabio Estevam <[email protected]> Date: Wed May 25 22:05:43 2022 -0300 ASoC: imx-audmux: Silence a clang warning [ Upstream commit 2f4a8171da06609bb6a063630ed546ee3d93dad7 ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: sound/soc/fsl/imx-audmux.c:301:16: warning: cast to smaller integer type 'enum imx_audmux_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: 6a8b8b582db1 ("ASoC: imx-audmux: Remove unused .id_table") Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Wed Jul 6 17:42:55 2022 +0800 ASoC: imx-card: Fix DSD/PDM mclk frequency [ Upstream commit c0fabd12a8570cb932f13d9388f3d887ad44369b ] The DSD/PDM rate not only DSD64/128/256/512, which are the multiple rate of 44.1kHz, but also support the multiple rate of 8kHz, so can't force all mclk frequency to be 22579200Hz, need to assign the frequency according to rate. Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Thu Jul 21 18:29:53 2022 +0800 ASoC: imx-card: use snd_pcm_format_t type for asrc_format [ Upstream commit 409a8652e909e323c715f3088e6c3133e37c8881 ] Fix sparse warning: sound/soc/fsl/imx-card.c:653:59: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/imx-card.c:653:59: sparse: expected unsigned int [usertype] asrc_format sound/soc/fsl/imx-card.c:653:59: sparse: got restricted snd_pcm_format_t [usertype] sound/soc/fsl/imx-card.c:655:59: sparse: warning: incorrect type in assignment (different base types) sound/soc/fsl/imx-card.c:655:59: sparse: expected unsigned int [usertype] asrc_format sound/soc/fsl/imx-card.c:655:59: sparse: got restricted snd_pcm_format_t [usertype] Fixes: aa736700f42f ("ASoC: imx-card: Add imx-card machine driver") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Wed Jul 27 12:08:13 2022 +0300 ASoC: mchp-spdifrx: disable end of block interrupt on failures [ Upstream commit 768ac4f12ca0fda935f58eb8c5120e9d795bc6e3 ] Disable end of block interrupt in case of wait for completion timeout or errors to undo previously enable operation (done in mchp_spdifrx_isr_blockend_en()). Otherwise we can end up with an unbalanced reference counter for this interrupt. Fixes: ef265c55c1ac ("ASoC: mchp-spdifrx: add driver for SPDIF RX") Signed-off-by: Claudiu Beznea <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 16:42:41 2022 +0400 ASoC: mediatek: mt8173-rt5650: Fix refcount leak in mt8173_rt5650_dev_probe [ Upstream commit efe2178d1a32492f99e7f1f2568eea5c88a85729 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix refcount leak in some error paths. Fixes: 0f83f9296d5c ("ASoC: mediatek: Add machine driver for ALC5650 codec") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu Jun 2 07:41:42 2022 +0400 ASoC: mediatek: mt8173: Fix refcount leak in mt8173_rt5650_rt5676_dev_probe [ Upstream commit ae4f11c1ed2d67192fdf3d89db719ee439827c11 ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Fix missing of_node_put() in error paths. Fixes: 94319ba10eca ("ASoC: mediatek: Use platform_of_node for machine drivers") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Wed Jul 13 18:20:13 2022 +0800 ASoC: mt6359: Fix refcount leak bug [ Upstream commit a8d5df69e2ec702d979f7d04ed519caf8691a032 ] In mt6359_parse_dt() and mt6359_accdet_parse_dt(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 683530285316 ("ASoC: mt6359: fix failed to parse DT properties") Fixes: eef07b9e0925 ("ASoC: mediatek: mt6359: add MT6359 accdet jack driver") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 12:34:15 2022 +0400 ASoC: mt6797-mt6351: Fix refcount leak in mt6797_mt6351_dev_probe [ Upstream commit 7472eb8d7dd12b6b9b1a4f4527719cc9c7f5965f ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: f0ab0bf250da ("ASoC: add mt6797-mt6351 driver and config option") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Sat Jul 2 10:01:09 2022 +0800 ASoC: qcom: Fix missing of_node_put() in asoc_qcom_lpass_cpu_platform_probe() [ Upstream commit f507c0c67dac57d2bcd5dcae4b6139b0305d8957 ] We should call of_node_put() for the reference 'dsp_of_node' returned by of_parse_phandle() which will increase the refcount. Fixes: 9bae4880acee ("ASoC: qcom: move ipq806x specific bits out of lpass driver.") Co-authored-by: Miaoqian Lin <[email protected]> Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Thu Jul 21 11:02:22 2022 +0200 ASoC: qcom: q6dsp: Fix an off-by-one in q6adm_alloc_copp() [ Upstream commit 673f58f62ca6fc98979d1cf3fe89c3ff33f29b2e ] find_first_zero_bit() returns MAX_COPPS_PER_PORT at max here. So 'idx' should be tested with ">=" or the test can't match. Fixes: 7b20b2be51e1 ("ASoC: qdsp6: q6adm: Add q6adm driver") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/0fca3271649736053eb9649d87e1ca01b056be40.1658394124.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tom Rix <[email protected]> Date: Wed Jun 29 14:53:45 2022 -0400 ASoC: samsung: change gpiod_speaker_power and rx1950_audio from global to static variables [ Upstream commit d2294461b90e0c5b3bbfaaf2c8baff4fd3e2bb13 ] sparse reports sound/soc/samsung/rx1950_uda1380.c:131:18: warning: symbol 'gpiod_speaker_power' was not declared. Should it be static? sound/soc/samsung/rx1950_uda1380.c:231:24: warning: symbol 'rx1950_audio' was not declared. Should it be static? Both gpiod_speaker_power and rx1950_audio are only used in rx1950_uda1380.c, so their storage class specifiers should be static. Fixes: 83d74e354200 ("ASoC: samsung: rx1950: turn into platform driver") Signed-off-by: Tom Rix <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 17:06:39 2022 +0400 ASoC: samsung: Fix error handling in aries_audio_probe [ Upstream commit 3e2649c5e8643bea0867bb1dd970fedadb0eb7f3 ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function is missing of_node_put(cpu) in the error path. Fix this by goto out label. of_node_put() will check NULL pointer. Fixes: 7a3a7671fa6c ("ASoC: samsung: Add driver for Aries boards") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Mon Jun 27 16:19:00 2022 +0200 ASoC: samsung: h1940_uda1380: include proepr GPIO consumer header [ Upstream commit bd10b0dafdcf0ec1677cad70101e1f97b9e28f2e ] h1940_uda1380 uses gpiod*/GPIOD* so it should include GPIO consumer header. Fixes: 9666e27f90b9 ("ASoC: samsung: h1940: turn into platform driver") Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Wed May 18 10:27:26 2022 +0300 ath10k: do not enforce interrupt trigger type [ Upstream commit 1ee6c5abebd3cacf2ac4378d0ed4f57fd4850421 ] Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge rising - but instead rely on Devicetree to configure it. All Qualcomm DTSI with WCN3990 define the interrupt type as level high, so the mismatch between DTSI and driver causes rebind issues: $ echo 18800000.wifi > /sys/bus/platform/drivers/ath10k_snoc/unbind $ echo 18800000.wifi > /sys/bus/platform/drivers/ath10k_snoc/bind [ 44.763114] irq: type mismatch, failed to map hwirq-446 for interrupt-controller@17a00000! [ 44.763130] ath10k_snoc 18800000.wifi: error -ENXIO: IRQ index 0 not found [ 44.763140] ath10k_snoc 18800000.wifi: failed to initialize resource: -6 Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.2.0.c8-00009-QCAHLSWSC8180XMTPLZ-1 Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 Fixes: c963a683e701 ("ath10k: add resource init and deinit for WCN3990") Signed-off-by: Krzysztof Kozlowski <[email protected]> Tested-by: Steev Klimaszewski <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Manikanta Pubbisetty <[email protected]> Date: Thu Jun 2 17:26:21 2022 +0530 ath11k: Fix incorrect debug_mask mappings [ Upstream commit 9331f7d3c54a263bede5055e106e40b28d0bd937 ] Currently a couple of debug_mask entries are mapped to the same value, this could enable unintended driver logging. If enabling DP_TX logs was the intention, then this could also enable PCI logs flooding the dmesg buffer or vice versa. Fix this by correctly assigning the debug masks. Found during code review. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Fixes: aa2092a9bab3f ("ath11k: add raw mode and software crypto support") Signed-off-by: Manikanta Pubbisetty <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Sun May 22 15:33:16 2022 +0300 ath11k: fix netdev open race [ Upstream commit d4ba1ff87b17e81686ada8f429300876f55f95ad ] Make sure to allocate resources needed before registering the device. This specifically avoids having a racing open() trigger a BUG_ON() in mod_timer() when ath11k_mac_op_start() is called before the mon_reap_timer as been set up. I did not see this issue with next-20220310, but I hit it on every probe with next-20220511. Perhaps some timing changed in between. Here's the backtrace: [ 51.346947] kernel BUG at kernel/time/timer.c:990! [ 51.346958] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ... [ 51.578225] Call trace: [ 51.583293] __mod_timer+0x298/0x390 [ 51.589518] mod_timer+0x14/0x20 [ 51.595368] ath11k_mac_op_start+0x41c/0x4a0 [ath11k] [ 51.603165] drv_start+0x38/0x60 [mac80211] [ 51.610110] ieee80211_do_open+0x29c/0x7d0 [mac80211] [ 51.617945] ieee80211_open+0x60/0xb0 [mac80211] [ 51.625311] __dev_open+0x100/0x1c0 [ 51.631420] __dev_change_flags+0x194/0x210 [ 51.638214] dev_change_flags+0x24/0x70 [ 51.644646] do_setlink+0x228/0xdb0 [ 51.650723] __rtnl_newlink+0x460/0x830 [ 51.657162] rtnl_newlink+0x4c/0x80 [ 51.663229] rtnetlink_rcv_msg+0x124/0x390 [ 51.669917] netlink_rcv_skb+0x58/0x130 [ 51.676314] rtnetlink_rcv+0x18/0x30 [ 51.682460] netlink_unicast+0x250/0x310 [ 51.688960] netlink_sendmsg+0x19c/0x3e0 [ 51.695458] ____sys_sendmsg+0x220/0x290 [ 51.701938] ___sys_sendmsg+0x7c/0xc0 [ 51.708148] __sys_sendmsg+0x68/0xd0 [ 51.714254] __arm64_sys_sendmsg+0x28/0x40 [ 51.720900] invoke_syscall+0x48/0x120 Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Fixes: 840c36fa727a ("ath11k: dp: stop rx pktlog before suspend") Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Skripkin <[email protected]> Date: Mon Jun 13 21:43:59 2022 +0300 ath9k: fix use-after-free in ath9k_hif_usb_rx_cb [ Upstream commit 0ac4827f78c7ffe8eef074bc010e7e34bc22f533 ] Syzbot reported use-after-free Read in ath9k_hif_usb_rx_cb() [0]. The problem was in incorrect htc_handle->drv_priv initialization. Probable call trace which can trigger use-after-free: ath9k_htc_probe_device() /* htc_handle->drv_priv = priv; */ ath9k_htc_wait_for_target() <--- Failed ieee80211_free_hw() <--- priv pointer is freed <IRQ> ... ath9k_hif_usb_rx_cb() ath9k_hif_usb_rx_stream() RX_STAT_INC() <--- htc_handle->drv_priv access In order to not add fancy protection for drv_priv we can move htc_handle->drv_priv initialization at the end of the ath9k_htc_probe_device() and add helper macro to make all *_STAT_* macros NULL safe, since syzbot has reported related NULL deref in that macros [1] Link: https://syzkaller.appspot.com/bug?id=6ead44e37afb6866ac0c7dd121b4ce07cb665f60 [0] Link: https://syzkaller.appspot.com/bug?id=b8101ffcec107c0567a0cd8acbbacec91e9ee8de [1] Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Reported-and-tested-by: [email protected] Reported-and-tested-by: [email protected] Signed-off-by: Pavel Skripkin <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/d57bbedc857950659bfacac0ab48790c1eda00c8.1655145743.git.paskripkin@gmail.com Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Llamas <[email protected]> Date: Fri Jul 1 18:20:41 2022 +0000 binder: fix redefinition of seq_file attributes [ Upstream commit b7e241bbff24f9e106bf616408fd58bcedc44bae ] The patchset in [1] exported some definitions to binder_internal.h in order to make the debugfs entries such as 'stats' and 'transaction_log' available in a binderfs instance. However, the DEFINE_SHOW_ATTRIBUTE macro expands into a static function/variable pair, which in turn get redefined each time a source file includes this internal header. This problem was made evident after a report from the kernel test robot <[email protected]> where several W=1 build warnings are seen in downstream kernels. See the following example: include/../drivers/android/binder_internal.h:111:23: warning: 'binder_stats_fops' defined but not used [-Wunused-const-variable=] 111 | DEFINE_SHOW_ATTRIBUTE(binder_stats); | ^~~~~~~~~~~~ include/linux/seq_file.h:174:37: note: in definition of macro 'DEFINE_SHOW_ATTRIBUTE' 174 | static const struct file_operations __name ## _fops = { \ | ^~~~~~ This patch fixes the above issues by moving back the definitions into binder.c and instead creates an array of the debugfs entries which is more convenient to share with binderfs and iterate through. [1] https://lore.kernel.org/all/[email protected]/ Fixes: 0e13e452dafc ("binder: Add stats, state and transactions files") Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs") Reported-by: kernel test robot <[email protected]> Signed-off-by: Carlos Llamas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Lei <[email protected]> Date: Mon Jul 11 17:08:08 2022 +0800 blk-mq: don't create hctx debugfs dir until q->debugfs_dir is created [ Upstream commit f3ec5d11554778c24ac8915e847223ed71d104fc ] blk_mq_debugfs_register_hctx() can be called by blk_mq_update_nr_hw_queues when gendisk isn't added yet, such as nvme tcp. Fixes the warning of 'debugfs: Directory 'hctx0' with parent '/' already present!' which can be observed reliably when running blktests nvme/005. Fixes: 6cfc0081b046 ("blk-mq: no need to check return value of debugfs_create functions") Reported-by: Yi Zhang <[email protected]> Signed-off-by: Ming Lei <[email protected]> Tested-by: Yi Zhang <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Thu Jul 14 11:06:36 2022 -0700 blktrace: Trace remapped requests correctly [ Upstream commit 22c80aac882f712897b88b7ea8f5a74ea19019df ] Trace the remapped operation and its flags instead of only the data direction of remapped operations. This issue was detected by analyzing the warnings reported by sparse related to the new blk_opf_t type. Reviewed-by: Jun'ichi Nomura <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: Mike Christie <[email protected]> Cc: Li Zefan <[email protected]> Cc: Chaitanya Kulkarni <[email protected]> Fixes: 1b9a9ab78b0a ("blktrace: use op accessors") Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keith Busch <[email protected]> Date: Fri Jun 10 12:58:21 2022 -0700 block/bio: remove duplicate append pages code [ Upstream commit c58c0074c54c2e2bb3bb0d5a4d8896bb660cc8bc ] The getting pages setup for zone append and normal IO are identical. Use common code for each. Signed-off-by: Keith Busch <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Thu Jul 7 16:31:21 2022 +0200 block/rnbd-srv: Set keep_id to true after mutex_trylock [ Upstream commit 4bc14f3101364877dd59085f39e068a2a7ec9f2d ] After setting keep_id if the mutex trylock fails, the keep_id stays set for the rest of the sess_dev lifetime. Therefore, set keep_id to true after mutex_trylock succeeds, so that a failure of trylock does'nt touch keep_id. Fixes: b168e1d85cf3 ("block/rnbd-srv: Prevent a deadlock generated by accessing sysfs in parallel") Cc: [email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Signed-off-by: Jack Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jinke Han <[email protected]> Date: Wed Jul 20 17:36:16 2022 +0800 block: don't allow the same type rq_qos add more than once [ Upstream commit 14a6e2eb7df5c7897c15b109cba29ab0c4a791b6 ] In our test of iocost, we encountered some list add/del corruptions of inner_walk list in ioc_timer_fn. The reason can be described as follows: cpu 0 cpu 1 ioc_qos_write ioc_qos_write ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ... } When the io.cost.qos file is written by two cpus concurrently, rq_qos may be added to one disk twice. In that case, there will be two iocs enabled and running on one disk. They own different iocgs on their active list. In the ioc_timer_fn function, because of the iocgs from two iocs have the same root iocg, the root iocg's walk_list may be overwritten by each other and this leads to list add/del corruptions in building or destroying the inner_walk list. And so far, the blk-rq-qos framework works in case that one instance for one type rq_qos per queue by default. This patch make this explicit and also fix the crash above. Signed-off-by: Jinke Han <[email protected]> Reviewed-by: Muchun Song <[email protected]> Acked-by: Tejun Heo <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keith Busch <[email protected]> Date: Tue Jul 12 08:32:54 2022 -0700 block: ensure iov_iter advances for added pages [ Upstream commit 325347d965e7ccf5424a05398807a6d801846612 ] There are cases where a bio may not accept additional pages, and the iov needs to advance to the last data length that was accepted. The zone append used to handle this correctly, but was inadvertently broken when the setup was made common with the normal r/w case. Fixes: 576ed9135489c ("block: use bio_add_page in bio_iov_iter_get_pages") Fixes: c58c0074c54c2 ("block/bio: remove duplicate append pages code") Signed-off-by: Keith Busch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keith Busch <[email protected]> Date: Fri Jun 10 12:58:20 2022 -0700 block: fix infinite loop for invalid zone append [ Upstream commit b82d9fa257cb3725c49d94d2aeafc4677c34448a ] Returning 0 early from __bio_iov_append_get_pages() for the max_append_sectors warning just creates an infinite loop since 0 means success, and the bio will never fill from the unadvancing iov_iter. We could turn the return into an error value, but it will already be turned into an error value later on, so just remove the warning. Clearly no one ever hit it anyway. Fixes: 0512a75b98f84 ("block: Introduce REQ_OP_ZONE_APPEND") Signed-off-by: Keith Busch <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Sep 20 14:33:22 2021 +0200 block: remove the struct blk_queue_ctx forward declaration [ Upstream commit 9778ac77c2027827ffdbb33d3e936b3a0ae9f0f9 ] This type doesn't exist at all, so no need to forward declare it. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Fri Jun 3 09:24:36 2022 +0800 Bluetooth: hci_intel: Add check for platform_driver_register [ Upstream commit ab2d2a982ff721f4b029282d9a40602ea46a745e ] As platform_driver_register() could fail, it should be better to deal with the return value in order to maintain the code consisitency. Fixes: 1ab1f239bf17 ("Bluetooth: hci_intel: Add support for platform driver") Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luiz Augusto von Dentz <[email protected]> Date: Mon Aug 1 13:52:07 2022 -0700 Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regression commit 332f1795ca202489c665a75e62e18ff6284de077 upstream. The patch d0be8347c623: "Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put" from Jul 21, 2022, leads to the following Smatch static checker warning: net/bluetooth/l2cap_core.c:1977 l2cap_global_chan_by_psm() error: we previously assumed 'c' could be null (see line 1996) Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tadeusz Struk <[email protected]> Date: Tue May 17 11:04:20 2022 -0700 bpf: Fix KASAN use-after-free Read in compute_effective_progs commit 4c46091ee985ae84c60c5e95055d779fcd291d87 upstream. Syzbot found a Use After Free bug in compute_effective_progs(). The reproducer creates a number of BPF links, and causes a fault injected alloc to fail, while calling bpf_link_detach on them. Link detach triggers the link to be freed by bpf_link_free(), which calls __cgroup_bpf_detach() and update_effective_progs(). If the memory allocation in this function fails, the function restores the pointer to the bpf_cgroup_link on the cgroup list, but the memory gets freed just after it returns. After this, every subsequent call to update_effective_progs() causes this already deallocated pointer to be dereferenced in prog_list_length(), and triggers KASAN UAF error. To fix this issue don't preserve the pointer to the prog or link in the list, but remove it and replace it with a dummy prog without shrinking the table. The subsequent call to __cgroup_bpf_detach() or __cgroup_bpf_detach() will correct it. Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment") Reported-by: <[email protected]> Signed-off-by: Tadeusz Struk <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Cc: <[email protected]> Link: https://syzkaller.appspot.com/bug?id=8ebf179a95c2a2670f7cf1ba62429ec044369db4 Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexei Starovoitov <[email protected]> Date: Thu Jul 14 14:16:37 2022 -0700 bpf: Fix subprog names in stack traces. [ Upstream commit 9c7c48d6a1e2eb5192ad5294c1c4dbd42a88e88b ] The commit 7337224fc150 ("bpf: Improve the info.func_info and info.func_info_rec_size behavior") accidently made bpf_prog_ksym_set_name() conservative for bpf subprograms. Fixed it so instead of "bpf_prog_tag_F" the stack traces print "bpf_prog_tag_full_subprog_name". Fixes: 7337224fc150 ("bpf: Improve the info.func_info and info.func_info_rec_size behavior") Reported-by: Tejun Heo <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Naohiro Aota <[email protected]> Date: Tue Jun 21 15:40:59 2022 +0900 btrfs: ensure pages are unlocked on cow_file_range() failure [ Upstream commit 9ce7466f372d83054c7494f6b3e4b9abaf3f0355 ] There is a hung_task report on zoned btrfs like below. https://github.com/naota/linux/issues/59 [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] <TASK> [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] </TASK> While we debug the issue, we found running fstests generic/551 on 5GB non-zoned null_blk device in the emulated zoned mode also had a similar hung issue. Also, we can reproduce the same symptom with an error injected cow_file_range() setup. The hang occurs when cow_file_range() fails in the middle of allocation. cow_file_range() called from do_allocation_zoned() can split the give region ([start, end]) for allocation depending on current block group usages. When btrfs can allocate bytes for one part of the split regions but fails for the other region (e.g. because of -ENOSPC), we return the error leaving the pages in the succeeded regions locked. Technically, this occurs only when @unlock == 0. Otherwise, we unlock the pages in an allocated region after creating an ordered extent. Considering the callers of cow_file_range(unlock=0) won't write out the pages, we can unlock the pages on error exit from cow_file_range(). So, we can ensure all the pages except @locked_page are unlocked on error case. In summary, cow_file_range now behaves like this: - page_started == 1 (return value) - All the pages are unlocked. IO is started. - unlock == 1 - All the pages except @locked_page are unlocked in any case - unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @locked_page are unlocked Fixes: 42c011000963 ("btrfs: zoned: introduce dedicated data write path for zoned filesystems") CC: [email protected] # 5.12+ Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Naohiro Aota <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Borisov <[email protected]> Date: Thu Jun 23 10:55:47 2022 +0300 btrfs: properly flag filesystem with BTRFS_FEATURE_INCOMPAT_BIG_METADATA [ Upstream commit e26b04c4c91925dba57324db177a24e18e2d0013 ] Commit 6f93e834fa7c seemingly inadvertently moved the code responsible for flagging the filesystem as having BIG_METADATA to a place where setting the flag was essentially lost. This means that filesystems created with kernels containing this bug (starting with 5.15) can potentially be mounted by older (pre-3.4) kernels. In reality chances for this happening are low because there are other incompat flags introduced in the mean time. Still the correct behavior is to set INCOMPAT_BIG_METADATA flag and persist this in the superblock. Fixes: 6f93e834fa7c ("btrfs: fix upper limit for max_inline for page size 64K") CC: [email protected] # 5.4+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Nikolay Borisov <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qu Wenruo <[email protected]> Date: Tue Jun 7 19:48:24 2022 +0800 btrfs: reject log replay if there is unsupported RO compat flag commit dc4d31684974d140250f3ee612c3f0cab13b3146 upstream. [BUG] If we have a btrfs image with dirty log, along with an unsupported RO compatible flag: log_root 30474240 ... compat_flags 0x0 compat_ro_flags 0x40000003 ( FREE_SPACE_TREE | FREE_SPACE_TREE_VALID | unknown flag: 0x40000000 ) Then even if we can only mount it RO, we will still cause metadata update for log replay: BTRFS info (device dm-1): flagging fs with big metadata feature BTRFS info (device dm-1): using free space tree BTRFS info (device dm-1): has skinny extents BTRFS info (device dm-1): start tree-log replay This is definitely against RO compact flag requirement. [CAUSE] RO compact flag only forces us to do RO mount, but we will still do log replay for plain RO mount. Thus this will result us to do log replay and update metadata. This can be very problematic for new RO compat flag, for example older kernel can not understand v2 cache, and if we allow metadata update on RO mount and invalidate/corrupt v2 cache. [FIX] Just reject the mount unless rescue=nologreplay is provided: BTRFS error (device dm-1): cannot replay dirty log with unsupport optional features (0x40000000), try rescue=nologreplay instead We don't want to set rescue=nologreply directly, as this would make the end user to read the old data, and cause confusion. Since the such case is really rare, we're mostly fine to just reject the mount with an error message, which also includes the proper workaround. CC: [email protected] #4.9+ Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Josef Bacik <[email protected]> Date: Mon Jun 13 18:31:17 2022 -0400 btrfs: reset block group chunk force if we have to wait [ Upstream commit 1314ca78b2c35d3e7d0f097268a2ee6dc0d369ef ] If you try to force a chunk allocation, but you race with another chunk allocation, you will end up waiting on the chunk allocation that just occurred and then allocate another chunk. If you have many threads all doing this at once you can way over-allocate chunks. Fix this by resetting force to NO_FORCE, that way if we think we need to allocate we can, otherwise we don't force another chunk allocation if one is already happening. Reviewed-by: Filipe Manana <[email protected]> CC: [email protected] # 5.4+ Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Yingliang <[email protected]> Date: Fri Jul 1 17:43:52 2022 +0800 bus: hisi_lpc: fix missing platform_device_put() in hisi_lpc_acpi_probe() [ Upstream commit 54872fea6a5ac967ec2272aea525d1438ac6735a ] In error case in hisi_lpc_acpi_probe() after calling platform_device_add(), hisi_lpc_acpi_remove() can't release the failed 'pdev', so it will be leak, call platform_device_put() to fix this problem. I'v constructed this error case and tested this patch on D05 board. Fixes: 99c0228d6ff1 ("HISI LPC: Re-Add ACPI child enumeration support") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Acked-by: John Garry <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:48 2022 +0900 can: error: specify the values of data[5..7] of CAN error frames [ Upstream commit e70a3263a7eed768d5f947b8f2aff8d2a79c9d97 ] Currently, data[5..7] of struct can_frame, when used as a CAN error frame, are defined as being "controller specific". Device specific behaviours are problematic because it prevents someone from writing code which is portable between devices. As a matter of fact, data[5] is never used, data[6] is always used to report TX error counter and data[7] is always used to report RX error counter. can-utils also relies on this. This patch updates the comment in the uapi header to specify that data[5] is reserved (and thus should not be used) and that data[6..7] are used for error counters. Fixes: 0d66548a10cb ("[CAN]: Add PF_CAN core module") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:43 2022 +0900 can: hi311x: do not report txerr and rxerr during bus-off [ Upstream commit a22bd630cfff496b270211745536e50e98eb3a45 ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:45 2022 +0900 can: kvaser_usb_hydra: do not report txerr and rxerr during bus-off [ Upstream commit 936e90595376e64b6247c72d3ea8b8b164b7ac96 ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family") Link: https://lore.kernel.org/all/[email protected] CC: Jimmy Assarsson <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:46 2022 +0900 can: kvaser_usb_leaf: do not report txerr and rxerr during bus-off [ Upstream commit a57732084e06791d37ea1ea447cca46220737abd ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: 7259124eac7d1 ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c") Link: https://lore.kernel.org/all/[email protected] CC: Jimmy Assarsson <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Kleine-Budde <[email protected]> Date: Sat Jun 11 16:20:58 2022 +0200 can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback [ Upstream commit 7e193a42c37cf40eba8ac5af2d5e8eeb8b9506f9 ] Usually CAN devices support configurable bit rates. The limits are defined by struct can_priv::bittiming_const. Another way is to implement the struct can_priv::do_set_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::bittiming_const or struct can_priv::do_set_bittiming is implemented. In commit 431af779256c ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_bittiming callback on devices with fixed bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/[email protected] Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates") Reported-by: Max Staudt <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Kleine-Budde <[email protected]> Date: Sat Jun 11 16:20:58 2022 +0200 can: netlink: allow configuring of fixed data bit rates without need for do_set_data_bittiming callback [ Upstream commit ec30c109391c5eac9b1d689a61e4bfed88148947 ] This patch is similar to 7e193a42c37c ("can: netlink: allow configuring of fixed bit rates without need for do_set_bittiming callback") but for data bit rates instead of bit rates. Usually CAN devices support configurable data bit rates. The limits are defined by struct can_priv::data_bittiming_const. Another way is to implement the struct can_priv::do_set_data_bittiming callback. If the bit rate is configured via netlink, the can_changelink() function checks that either can_priv::data_bittiming_const or struct can_priv::do_set_data_bittiming is implemented. In commit 431af779256c ("can: dev: add CAN interface API for fixed bitrates") an API for configuring bit rates on CAN interfaces that only support fixed bit rates was added. The supported bit rates are defined by struct can_priv::bitrate_const. However the above mentioned commit forgot to add the struct can_priv::data_bitrate_const to the check in can_changelink(). In order to avoid to implement a no-op can_priv::do_set_data_bittiming callback on devices with fixed data bit rates, extend the check in can_changelink() accordingly. Link: https://lore.kernel.org/all/[email protected] Fixes: 431af779256c ("can: dev: add CAN interface API for fixed bitrates") Acked-by: Max Staudt <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:39 2022 +0900 can: pch_can: do not report txerr and rxerr during bus-off [ Upstream commit 3a5c7e4611ddcf0ef37a3a17296b964d986161a6 ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: 0c78ab76a05c ("pch_can: Add setting TEC/REC statistics processing") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Fri Jul 22 01:00:32 2022 +0900 can: pch_can: pch_can_error(): initialize errc before using it [ Upstream commit 9950f11211331180269867aef848c7cf56861742 ] After commit 3a5c7e4611dd, the variable errc is accessed before being initialized, c.f. below W=2 warning: | In function 'pch_can_error', | inlined from 'pch_can_poll' at drivers/net/can/pch_can.c:739:4: | drivers/net/can/pch_can.c:501:29: warning: 'errc' may be used uninitialized [-Wmaybe-uninitialized] | 501 | cf->data[6] = errc & PCH_TEC; | | ^ | drivers/net/can/pch_can.c: In function 'pch_can_poll': | drivers/net/can/pch_can.c:484:13: note: 'errc' was declared here | 484 | u32 errc, lec; | | ^~~~ Moving errc initialization up solves this issue. Fixes: 3a5c7e4611dd ("can: pch_can: do not report txerr and rxerr during bus-off") Reported-by: Nathan Chancellor <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:40 2022 +0900 can: rcar_can: do not report txerr and rxerr during bus-off [ Upstream commit a37b7245e831a641df360ca41db6a71c023d3746 ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: fd1159318e55 ("can: add Renesas R-Car CAN driver") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:41 2022 +0900 can: sja1000: do not report txerr and rxerr during bus-off [ Upstream commit 164d7cb2d5a30f1b3a5ab4fab1a27731fb1494a8 ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: 215db1856e83 ("can: sja1000: Consolidate and unify state change handling") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:44 2022 +0900 can: sun4i_can: do not report txerr and rxerr during bus-off [ Upstream commit 0ac15a8f661b941519379831d09bfb12271b23ee ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module") Link: https://lore.kernel.org/all/[email protected] CC: Chen-Yu Tsai <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Mailhol <[email protected]> Date: Tue Jul 19 23:35:47 2022 +0900 can: usb_8dev: do not report txerr and rxerr during bus-off [ Upstream commit aebe8a2433cd090ccdc222861f44bddb75eb01de ] During bus off, the error count is greater than 255 and can not fit in a u8. Fixes: 0024d8ad1639 ("can: usb_8dev: Add support for USB2CAN interface from 8 devices") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rex-BC Chen <[email protected]> Date: Mon May 23 17:33:29 2022 +0800 clk: mediatek: reset: Fix written reset bit offset [ Upstream commit edabcf71d100fd433a0fc2d0c97057c446c33b2a ] Original assert/deassert bit is BIT(0), but it's more resonable to modify them to BIT(id % 32) which is based on id. This patch will not influence any previous driver because the reset is only used for thermal. The id (MT8183_INFRACFG_AO_THERM_SW_RST) is 0. Fixes: 64ebb57a3df6 ("clk: reset: Modify reset-controller driver") Signed-off-by: Rex-BC Chen <[email protected]> Reviewed-by: Chen-Yu Tsai <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: NÃcolas F. R. A. Prado <[email protected]> Tested-by: NÃcolas F. R. A. Prado <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Fri May 20 00:41:32 2022 +0300 clk: qcom: camcc-sdm845: Fix topology around titan_top power domain [ Upstream commit 103dd2338bbff567bce7acd00fc5a09c806b38ec ] On SDM845 two found VFE GDSC power domains shall not be operated, if titan top is turned off, thus the former power domains will be set as subdomains by a GDSC registration routine. Fixes: 78412c262004 ("clk: qcom: Add camera clock controller driver for SDM845") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Wed May 18 13:35:54 2022 +0300 clk: qcom: camcc-sm8250: Fix halt on boot by reducing driver's init level [ Upstream commit c4f40351901a10cd662ac2c081396d8fb04f584d ] Access to I/O of SM8250 camera clock controller IP depends on enabled GCC_CAMERA_AHB_CLK clock supplied by global clock controller, the latter one is inited on subsys level, so, to satisfy the dependency, it would make sense to deprive the init level of camcc-sm8250 driver. If both drivers are compiled as built-in, there is a change that a board won't boot up due to a race, which happens on the same init level. Fixes: 5d66ca79b58c ("clk: qcom: Add camera clock controller driver for SM8250") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Tested-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Fri May 20 00:41:33 2022 +0300 clk: qcom: camcc-sm8250: Fix topology around titan_top power domain [ Upstream commit f8acf01a6a4f84baf05181e24bd48def4ba23f5b ] On SM8250 two found VFE GDSC power domains shall not be operated, if titan top is turned off, thus the former power domains will be set as subdomains by a GDSC registration routine. Fixes: 5d66ca79b58c ("clk: qcom: Add camera clock controller driver for SM8250") Signed-off-by: Vladimir Zapolskiy <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Marangi <[email protected]> Date: Sat Apr 30 07:44:57 2022 +0200 clk: qcom: clk-krait: unlock spin after mux completion [ Upstream commit df83d2c9e72910416f650ade1e07cc314ff02731 ] Unlock spinlock after the mux switch is completed to prevent any corner case of mux request while the switch still needs to be done. Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks") Signed-off-by: Ansuel Smith <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Travkin <[email protected]> Date: Sun Jun 12 19:59:52 2022 +0500 clk: qcom: clk-rcg2: Fail Duty-Cycle configuration if MND divider is not enabled. [ Upstream commit bdafb609c3bb848d710ad9cd4debd2ee9d6a4049 ] In cases when MND is not enabled (e.g. when only Half Integer Divider is used), setting D registers makes no effect. Fail instead of making ineffective write. Fixes: 7f891faf596e ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Nikita Travkin <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Travkin <[email protected]> Date: Sun Jun 12 19:59:53 2022 +0500 clk: qcom: clk-rcg2: Make sure to not write d=0 to the NMD register [ Upstream commit d0696770cef35a1fd16ea2167e2198c18aa6fbfe ] Sometimes calculation of d value may result in 0 because of the rounding after integer division. This causes the following error: [ 113.969689] camss_gp1_clk_src: rcg didn't update its configuration. [ 113.969754] WARNING: CPU: 3 PID: 35 at drivers/clk/qcom/clk-rcg2.c:122 update_config+0xc8/0xdc Make sure that D value is never zero. Fixes: 7f891faf596e ("clk: qcom: clk-rcg2: Add support for duty-cycle for RCG") Signed-off-by: Nikita Travkin <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:34 2022 +0100 clk: qcom: gcc-msm8939: Add missing system_mm_noc_bfdcd_clk_src [ Upstream commit dd363e2f7196278e7a30f509a0e8a841cb763b14 ] The msm8939 has an additional higher operating point for the multi-media peripherals. The higher throughput MM componets operate off of the system-mm noc not the system noc. system_mm_noc_bfdcd_clk_src is the source clock for the higher frequency capable system noc mm. Maximum frequency for the MM SNOC is 400 MHz. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:32 2022 +0100 clk: qcom: gcc-msm8939: Add missing SYSTEM_MM_NOC_BFDCD_CLK_SRC [ Upstream commit 07e7fcf1714c5f9930ad27613fea940aedba68da ] When adding in the indexes for this clock-controller we missed SYSTEM_MM_NOC_BFDCD_CLK_SRC. Add it in now. Fixes: 4c71d6abc4fc ("clk: qcom: Add DT bindings for MSM8939 GCC") Cc: Rob Herring <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Cc: [email protected] Signed-off-by: Bryan O'Donoghue <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:33 2022 +0100 clk: qcom: gcc-msm8939: Fix bimc_ddr_clk_src rcgr base address [ Upstream commit 63d42708320d6d2ca9ed505123d50ff4a542c36f ] Reviewing qcom docs for the 8939 we can see the command rcgr is pointing to the wrong address. bimc_ddr_clk_src_rcgr is @ 0x01832024 not 0x01832004. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Tue Jul 12 13:59:17 2022 +0100 clk: qcom: gcc-msm8939: Fix weird field spacing in ftbl_gcc_camss_cci_clk [ Upstream commit 2bc308ebc453ba22f3f120f777b9ac48f973ee80 ] Adding a new item to this frequency table I see the existing indentation is incorrect. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Wed May 4 17:38:35 2022 +0100 clk: qcom: gcc-msm8939: Point MM peripherals to system_mm_noc clock [ Upstream commit 05eed0990927aa9634682fec58660e30f7b7ae30 ] Qcom docs indciate the following peripherals operating from System NOC MM not from System NOC clocks. - MDP - VFE - JPEGe - Venus Switch over the relevant parent pointers. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Signed-off-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:38 2022 +0200 clk: qcom: ipq8074: fix NSS core PLL-s [ Upstream commit ca41ec1b30434636c56c5600b24a8d964d359d9c ] Like in IPQ6018 the NSS related Alpha PLL-s require initial configuration to work. So, obtain the regmap that is required for the Alpha PLL configuration and thus utilize the qcom_cc_really_probe() as we already have the regmap. Then utilize the Alpha PLL configs from the downstream QCA 5.4 based kernel to configure them. This fixes the UBI32 and NSS crypto PLL-s failing to get enabled by the kernel. Fixes: b8e7e519625f ("clk: qcom: ipq8074: add remaining PLL’s") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:40 2022 +0200 clk: qcom: ipq8074: fix NSS port frequency tables [ Upstream commit 0e9e61a2815b5cd34f1b495b2d72e8127ce9b794 ] NSS port 5 and 6 frequency tables are currently broken and are causing a wide ranges of issue like 1G not working at all on port 6 or port 5 being clocked with 312 instead of 125 MHz as UNIPHY1 gets selected. So, update the frequency tables with the ones from the downstream QCA 5.4 based kernel which has already fixed this. Fixes: 7117a51ed303 ("clk: qcom: ipq8074: add NSS ethernet port clocks") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:43 2022 +0200 clk: qcom: ipq8074: set BRANCH_HALT_DELAY flag for UBI clocks [ Upstream commit 2bd357e698207e2e65db03007e4be65bf9d6a7b3 ] Currently, attempting to enable the UBI clocks will cause the stuck at off warning to be printed and clk_enable will fail. [ 14.936694] gcc_ubi1_ahb_clk status stuck at 'off' Downstream 5.4 QCA kernel has fixed this by seting the BRANCH_HALT_DELAY flag on UBI clocks, so lets do the same. Fixes: 5736294aef83 ("clk: qcom: ipq8074: add NSS clocks") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Sun May 15 23:00:39 2022 +0200 clk: qcom: ipq8074: SW workaround for UBI32 PLL lock [ Upstream commit 3401ea2856ef84f39b75f0dc5ebcaeda81cb90ec ] UBI32 Huayra PLL fails to lock in 5 us in some SoC silicon and thus it will cause the wait_for_pll() to timeout and thus return the error indicating that the PLL failed to lock. This is bug in Huayra PLL HW for which SW workaround is to set bit 26 of TEST_CTL register. This is ported from the QCA 5.4 based downstream kernel. Fixes: b8e7e519625f ("clk: qcom: ipq8074: add remaining PLL’s") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ralph Siemsen <[email protected]> Date: Wed May 18 14:25:27 2022 -0400 clk: renesas: r9a06g032: Fix UART clkgrp bitsel [ Upstream commit 2dee50ab9e72a3cae75b65e5934c8dd3e9bf01bc ] There are two UART clock groups, each having a mux to select its upstream clock source. The register/bit definitions for accessing these two muxes appear to have been reversed since introduction. Correct them so as to match the hardware manual. Fixes: 4c3d88526eba ("clk: renesas: Renesas R9A06G032 clock driver") Signed-off-by: Ralph Siemsen <[email protected]> Reviewed-by: Phil Edworthy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Suzuki K Poulose <[email protected]> Date: Tue Jun 14 22:40:24 2022 +0100 coresight: Clear the connection field properly commit 2af89ebacf299b7fba5f3087d35e8a286ec33706 upstream. coresight devices track their connections (output connections) and hold a reference to the fwnode. When a device goes away, we walk through the devices on the coresight bus and make sure that the references are dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data() b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match(). However, the coresight_remove_match() doesn't clear the fwnode field, after dropping the reference, this causes use-after-free and additional refcount drops on the fwnode. e.g., if we have two devices, A and B, with a connection, A -> B. If we remove B first, B would clear the reference on B, from A via coresight_remove_match(). But when A is removed, it still has a connection with fwnode still pointing to B. Thus it tries to drops the reference in coresight_release_platform_data(), raising the bells like : [ 91.990153] ------------[ cut here ]------------ [ 91.990163] refcount_t: addition on 0; use-after-free. [ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144 [ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug] [ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53 [ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019 [ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 91.990454] pc : refcount_warn_saturate+0xa0/0x144 [ 91.990476] lr : refcount_warn_saturate+0xa0/0x144 [ 91.990496] sp : ffff80000c843640 [ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8 [ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8 [ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2 [ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40 [ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0 [ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375 [ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28 [ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572 [ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027 [ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00 [ 91.991000] Call trace: [ 91.991012] refcount_warn_saturate+0xa0/0x144 [ 91.991034] kobject_get+0xac/0xb0 [ 91.991055] of_node_get+0x2c/0x40 [ 91.991076] of_fwnode_get+0x40/0x60 [ 91.991094] fwnode_handle_get+0x3c/0x60 [ 91.991116] fwnode_get_nth_parent+0xf4/0x110 [ 91.991137] fwnode_full_name_string+0x48/0xc0 [ 91.991158] device_node_string+0x41c/0x530 [ 91.991178] pointer+0x320/0x3ec [ 91.991198] vsnprintf+0x23c/0x750 [ 91.991217] vprintk_store+0x104/0x4b0 [ 91.991238] vprintk_emit+0x8c/0x360 [ 91.991257] vprintk_default+0x44/0x50 [ 91.991276] vprintk+0xcc/0xf0 [ 91.991295] _printk+0x68/0x90 [ 91.991315] of_node_release+0x13c/0x14c [ 91.991334] kobject_put+0x98/0x114 [ 91.991354] of_node_put+0x24/0x34 [ 91.991372] of_fwnode_put+0x40/0x5c [ 91.991390] fwnode_handle_put+0x38/0x50 [ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight] [ 91.991472] coresight_unregister+0x64/0xcc [coresight] [ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x] [ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x] [ 91.991598] amba_remove+0x3c/0x19c Reproducible by: (Build all coresight components as modules): #!/bin/sh while true do for m in tmc stm cpu_debug etm4x replicator funnel do modprobe coresight_${m} done for m in tmc stm cpu_debug etm4x replicator funnel do rmmode coresight_${m} done done Cc: [email protected] Cc: Mathieu Poirier <[email protected]> Cc: Mike Leach <[email protected]> Cc: Leo Yan <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Fixes: 37ea1ffddffa ("coresight: Use fwnode handle instead of device names") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 12:28:07 2022 +0400 cpufreq: zynq: Fix refcount leak in zynq_get_revision [ Upstream commit d1ff2559cef0f6f8d97fba6337b28adb10689e16 ] of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 00f7dc636366 ("ARM: zynq: Add support for SOC_BUS") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qian Cai <[email protected]> Date: Fri Jun 24 07:13:38 2022 -0400 crypto: arm64/gcm - Select AEAD for GHASH_ARM64_CE [ Upstream commit fac76f2260893dde5aa05bb693b4c13e8ed0454b ] Otherwise, we could fail to compile. ld: arch/arm64/crypto/ghash-ce-glue.o: in function 'ghash_ce_mod_exit': ghash-ce-glue.c:(.exit.text+0x24): undefined reference to 'crypto_unregister_aead' ld: arch/arm64/crypto/ghash-ce-glue.o: in function 'ghash_ce_mod_init': ghash-ce-glue.c:(.init.text+0x34): undefined reference to 'crypto_register_aead' Fixes: 537c1445ab0b ("crypto: arm64/gcm - implement native driver using v8 Crypto Extensions") Signed-off-by: Qian Cai <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Sat May 28 21:44:07 2022 +0200 crypto: blake2s - remove shash module [ Upstream commit 2d16803c562ecc644803d42ba98a8e0aef9c014e ] BLAKE2s has no currently known use as an shash. Just remove all of this unnecessary plumbing. Removing this shash was something we talked about back when we were making BLAKE2s a built-in, but I simply never got around to doing it. So this completes that project. Importantly, this fixs a bug in which the lib code depends on crypto_simd_disabled_for_test, causing linker errors. Also add more alignment tests to the selftests and compare SIMD and non-SIMD compression functions, to make up for what we lose from testmgr.c. Reported-by: gaochao <[email protected]> Cc: Eric Biggers <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: [email protected] Fixes: 6048fdcc5f26 ("lib/crypto: blake2s: include as built-in") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tom Lendacky <[email protected]> Date: Thu Jun 16 10:26:18 2022 -0500 crypto: ccp - During shutdown, check SEV data pointer before using [ Upstream commit 1b05ece0c931536c0a38a9385e243a7962e933f6 ] On shutdown, each CCP device instance performs shutdown processing. However, __sev_platform_shutdown_locked() uses the controlling psp structure to obtain the pointer to the sev_device structure. However, during driver initialization, it is possible that an error can be received from the firmware that results in the sev_data pointer being cleared from the controlling psp structure. The __sev_platform_shutdown_locked() function does not check for this situation and will segfault. While not common, this scenario should be accounted for. Add a check for a NULL sev_device structure before attempting to use it. Fixes: 5441a07a127f ("crypto: ccp - shutdown SEV firmware on kexec") Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: John Allen <[email protected]> Date: Wed May 18 15:31:26 2022 +0000 crypto: ccp - Use kzalloc for sev ioctl interfaces to prevent kernel memory leak commit 13dc15a3f5fd7f884e4bfa8c011a0ae868df12ae upstream. For some sev ioctl interfaces, input may be passed that is less than or equal to SEV_FW_BLOB_MAX_SIZE, but larger than the data that PSP firmware returns. In this case, kmalloc will allocate memory that is the size of the input rather than the size of the data. Since PSP firmware doesn't fully overwrite the buffer, the sev ioctl interfaces with the issue may return uninitialized slab memory. Currently, all of the ioctl interfaces in the ccp driver are safe, but to prevent future problems, change all ioctl interfaces that allocate memory with kmalloc to use kzalloc and memset the data buffer to zero in sev_ioctl_do_platform_status. Fixes: 38103671aad3 ("crypto: ccp: Use the stack and common buffer for status commands") Fixes: e799035609e15 ("crypto: ccp: Implement SEV_PEK_CSR ioctl command") Fixes: 76a2b524a4b1d ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Fixes: d6112ea0cb344 ("crypto: ccp - introduce SEV_GET_ID2 command") Cc: [email protected] Reported-by: Andy Nguyen <[email protected]> Suggested-by: David Rientjes <[email protected]> Suggested-by: Peter Gonda <[email protected]> Signed-off-by: John Allen <[email protected]> Reviewed-by: Peter Gonda <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhengchao Shao <[email protected]> Date: Fri Jul 1 09:59:54 2022 +0800 crypto: hisilicon - Kunpeng916 crypto driver don't sleep when in softirq [ Upstream commit 68740ab505431f268dc1ee26a54b871e75f0ddaa ] When kunpeng916 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver") Signed-off-by: Zhengchao Shao <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhengchao Shao <[email protected]> Date: Tue Jul 19 12:23:23 2022 +0800 crypto: hisilicon/hpre - don't use GFP_KERNEL to alloc mem during softirq [ Upstream commit 98dfa9343f37bdd4112966292751e3a93aaf2e56 ] The hpre encryption driver may be used to encrypt and decrypt packets during the rx softirq, it is not allowed to use GFP_KERNEL. Fixes: c8b4b477079d ("crypto: hisilicon - add HiSilicon HPRE accelerator") Signed-off-by: Zhengchao Shao <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhengchao Shao <[email protected]> Date: Fri Jul 1 09:55:11 2022 +0800 crypto: hisilicon/sec - don't sleep when in softirq [ Upstream commit 02884a4f12de11f54d4ca67a07dd1f111d96fdbd ] When kunpeng920 encryption driver is used to deencrypt and decrypt packets during the softirq, it is not allowed to use mutex lock. The kernel will report the following error: BUG: scheduling while atomic: swapper/57/0/0x00000300 Call trace: dump_backtrace+0x0/0x1e4 show_stack+0x20/0x2c dump_stack+0xd8/0x140 __schedule_bug+0x68/0x80 __schedule+0x728/0x840 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x24 __mutex_lock.constprop.0+0x594/0x5dc __mutex_lock_slowpath+0x1c/0x30 mutex_lock+0x50/0x60 sec_request_init+0x8c/0x1a0 [hisi_sec2] sec_process+0x28/0x1ac [hisi_sec2] sec_skcipher_crypto+0xf4/0x1d4 [hisi_sec2] sec_skcipher_encrypt+0x1c/0x30 [hisi_sec2] crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp_output_tail+0x348/0x5c0 [esp4] esp_output+0x120/0x19c [esp4] xfrm_output_one+0x25c/0x4d4 xfrm_output_resume+0x6c/0x1fc xfrm_output+0xac/0x3c0 xfrm4_output+0x64/0x130 ip_build_and_send_pkt+0x158/0x20c tcp_v4_send_synack+0xdc/0x1f0 tcp_conn_request+0x7d0/0x994 tcp_v4_conn_request+0x58/0x6c tcp_v6_conn_request+0xf0/0x100 tcp_rcv_state_process+0x1cc/0xd60 tcp_v4_do_rcv+0x10c/0x250 tcp_v4_rcv+0xfc4/0x10a4 ip_protocol_deliver_rcu+0xf4/0x200 ip_local_deliver_finish+0x58/0x70 ip_local_deliver+0x68/0x120 ip_sublist_rcv_finish+0x70/0x94 ip_list_rcv_finish.constprop.0+0x17c/0x1d0 ip_sublist_rcv+0x40/0xb0 ip_list_rcv+0x140/0x1dc __netif_receive_skb_list_core+0x154/0x28c __netif_receive_skb_list+0x120/0x1a0 netif_receive_skb_list_internal+0xe4/0x1f0 napi_complete_done+0x70/0x1f0 gro_cell_poll+0x9c/0xb0 napi_poll+0xcc/0x264 net_rx_action+0xd4/0x21c __do_softirq+0x130/0x358 irq_exit+0x11c/0x13c __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x78/0x2c0 el1_irq+0xb8/0x140 arch_cpu_idle+0x18/0x40 default_idle_call+0x5c/0x1c0 cpuidle_idle_call+0x174/0x1b0 do_idle+0xc8/0x160 cpu_startup_entry+0x30/0x11c secondary_start_kernel+0x158/0x1e4 softirq: huh, entered softirq 3 NET_RX 0000000093774ee4 with preempt_count 00000100, exited with fffffe00? Fixes: 416d82204df4 ("crypto: hisilicon - add HiSilicon SEC V2 driver") Signed-off-by: Zhengchao Shao <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kai Ye <[email protected]> Date: Thu Jul 21 10:18:31 2022 +0800 crypto: hisilicon/sec - fix auth key size error [ Upstream commit 45f5d0176d8426cc1ab0bab84fbd8ef5c57526c6 ] The authentication algorithm supports a maximum of 128-byte keys. The allocated key memory is insufficient. Fixes: 2f072d75d1ab ("crypto: hisilicon - Add aead support on SEC2") Signed-off-by: Kai Ye <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Tue Jul 19 09:54:03 2022 +0200 crypto: inside-secure - Add missing MODULE_DEVICE_TABLE for of [ Upstream commit fa4d57b85786ec0e16565c75a51c208834b0c24d ] Without MODULE_DEVICE_TABLE, crypto_safexcel.ko module is not automatically loaded on platforms where inside-secure crypto HW is specified in device tree (e.g. Armada 3720). So add missing MODULE_DEVICE_TABLE for of. Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver") Signed-off-by: Pali Rohár <[email protected]> Acked-by: Marek Behún <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Mon Jun 20 09:52:43 2022 +0200 crypto: lib/blake2s - reduce stack frame usage in self test commit d6c14da474bf260d73953fbf7992c98d9112aec7 upstream. Using 3 blocks here doesn't give us much more than using 2, and it causes a stack frame size warning on certain compiler/config/arch combinations: lib/crypto/blake2s-selftest.c: In function 'blake2s_selftest': >> lib/crypto/blake2s-selftest.c:632:1: warning: the frame size of 1088 bytes is larger than 1024 bytes [-Wframe-larger-than=] 632 | } | ^ So this patch just reduces the block from 3 to 2, which makes the warning go away. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/linux-crypto/[email protected] Fixes: 2d16803c562e ("crypto: blake2s - remove shash module") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Corentin Labbe <[email protected]> Date: Mon May 2 20:19:19 2022 +0000 crypto: sun8i-ss - do not allocate memory when handling hash requests [ Upstream commit 8eec4563f152981a441693fc97c5459843dc5e6e ] Instead of allocate memory on each requests, it is easier to pre-allocate buffers. This made error path easier. Signed-off-by: Corentin Labbe <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed May 18 20:33:44 2022 +0300 crypto: sun8i-ss - fix error codes in allocate_flows() [ Upstream commit d2765e1b9ac4b2d5a5d5bf17f468c9b3566c3770 ] These failure paths should return -ENOMEM. Currently they return success. Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV") Fixes: 8eec4563f152 ("crypto: sun8i-ss - do not allocate memory when handling hash requests") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Corentin Labbe <[email protected]> Tested-by: Corentin Labbe <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Khoroshilov <[email protected]> Date: Fri Jun 10 21:27:15 2022 +0300 crypto: sun8i-ss - fix infinite loop in sun8i_ss_setup_ivs() [ Upstream commit d61a7b3decf7f0cf4121a7204303deefd2c7151b ] There is no i decrement in while (i >= 0) loop. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Khoroshilov <[email protected]> Fixes: 359e893e8af4 ("crypto: sun8i-ss - rework handling of IV") Acked-by: Corentin Labbe <[email protected]> Tested-by: Corentin Labbe <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangyu Hua <[email protected]> Date: Fri Jul 29 19:00:27 2022 +0800 dccp: put dccp_qpolicy_full() and dccp_qpolicy_push() in the same lock [ Upstream commit a41b17ff9dacd22f5f118ee53d82da0f3e52d5e3 ] In the case of sk->dccps_qpolicy == DCCPQ_POLICY_PRIO, dccp_qpolicy_full will drop a skb when qpolicy is full. And the lock in dccp_sendmsg is released before sock_alloc_send_skb and then relocked after sock_alloc_send_skb. The following conditions may lead dccp_qpolicy_push to add skb to an already full sk_write_queue: thread1--->lock thread1--->dccp_qpolicy_full: queue is full. drop a skb thread1--->unlock thread2--->lock thread2--->dccp_qpolicy_full: queue is not full. no need to drop. thread2--->unlock thread1--->lock thread1--->dccp_qpolicy_push: add a skb. queue is full. thread1--->unlock thread2--->lock thread2--->dccp_qpolicy_push: add a skb! thread2--->unlock Fix this by moving dccp_qpolicy_full. Fixes: b1308dc015eb ("[DCCP]: Set TX Queue Length Bounds via Sysctl") Signed-off-by: Hangyu Hua <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Sun Jul 24 14:33:52 2022 -0400 dm raid: fix address sanitizer warning in raid_resume [ Upstream commit 7dad24db59d2d2803576f2e3645728866a056dab ] There is a KASAN warning in raid_resume when running the lvm test lvconvert-raid.sh. The reason for the warning is that mddev->raid_disks is greater than rs->raid_disks, so the loop touches one entry beyond the allocated length. Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Sun Jul 24 14:31:35 2022 -0400 dm raid: fix address sanitizer warning in raid_status [ Upstream commit 1fbeea217d8f297fe0e0956a1516d14ba97d0396 ] There is this warning when using a kernel with the address sanitizer and running this testsuite: https://gitlab.com/cki-project/kernel-tests/-/tree/main/storage/swraid/scsi_raid ================================================================== BUG: KASAN: slab-out-of-bounds in raid_status+0x1747/0x2820 [dm_raid] Read of size 4 at addr ffff888079d2c7e8 by task lvcreate/13319 CPU: 0 PID: 13319 Comm: lvcreate Not tainted 5.18.0-0.rc3.<snip> #1 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x6a/0x9c print_address_description.constprop.0+0x1f/0x1e0 print_report.cold+0x55/0x244 kasan_report+0xc9/0x100 raid_status+0x1747/0x2820 [dm_raid] dm_ima_measure_on_table_load+0x4b8/0xca0 [dm_mod] table_load+0x35c/0x630 [dm_mod] ctl_ioctl+0x411/0x630 [dm_mod] dm_ctl_ioctl+0xa/0x10 [dm_mod] __x64_sys_ioctl+0x12a/0x1a0 do_syscall_64+0x5b/0x80 The warning is caused by reading conf->max_nr_stripes in raid_status. The code in raid_status reads mddev->private, casts it to struct r5conf and reads the entry max_nr_stripes. However, if we have different raid type than 4/5/6, mddev->private doesn't point to struct r5conf; it may point to struct r0conf, struct r1conf, struct r10conf or struct mpconf. If we cast a pointer to one of these structs to struct r5conf, we will be reading invalid memory and KASAN warns about it. Fix this bug by reading struct r5conf only if raid type is 4, 5 or 6. Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luo Meng <[email protected]> Date: Thu Jul 14 19:28:25 2022 +0800 dm thin: fix use-after-free crash in dm_sm_register_threshold_callback [ Upstream commit 3534e5a5ed2997ca1b00f44a0378a075bd05e8a3 ] Fault inject on pool metadata device reports: BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80 Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950 CPU: 7 PID: 950 Comm: dmsetup Tainted: G W 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xeb/0x3f4 kasan_report.cold+0xe6/0x147 dm_pool_register_metadata_threshold+0x40/0x80 pool_ctr+0xa0a/0x1150 dm_table_add_target+0x2c8/0x640 table_load+0x1fd/0x430 ctl_ioctl+0x2c4/0x5a0 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb3/0xd0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 This can be easily reproduced using: echo offline > /sys/block/sda/device/state dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10 dmsetup load pool --table "0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0" If a metadata commit fails, the transaction will be aborted and the metadata space maps will be destroyed. If a DM table reload then happens for this failed thin-pool, a use-after-free will occur in dm_sm_register_threshold_callback (called from dm_pool_register_metadata_threshold). Fix this by in dm_pool_register_metadata_threshold() by returning the -EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr() with a new error message: "Error registering metadata threshold". Fixes: ac8c3f3df65e4 ("dm thin: generate event when metadata threshold passed") Cc: [email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Luo Meng <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jul 11 16:31:52 2022 -0400 dm writecache: count number of blocks discarded, not number of discard bios [ Upstream commit 2ee73ef60db4d79b9f9b8cd501e8188b5179449f ] Change dm-writecache, so that it counts the number of blocks discarded instead of the number of discard bios. Make it consistent with the read and write statistics counters that were changed to count the number of blocks instead of bios. Fixes: e3a35d03407c ("dm writecache: add event counters") Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jul 11 16:30:52 2022 -0400 dm writecache: count number of blocks read, not number of read bios [ Upstream commit 2c6e755b49d273243431f5f1184654e71221fc78 ] Change dm-writecache, so that it counts the number of blocks read instead of the number of read bios. Bios can be split and requeued using the dm_accept_partial_bio function, so counting bios caused inaccurate results. Fixes: e3a35d03407c ("dm writecache: add event counters") Reported-by: Yu Kuai <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jul 11 16:31:26 2022 -0400 dm writecache: count number of blocks written, not number of write bios [ Upstream commit b2676e1482af89714af6988ce5d31a84692e2530 ] Change dm-writecache, so that it counts the number of blocks written instead of the number of write bios. Bios can be split and requeued using the dm_accept_partial_bio function, so counting bios caused inaccurate results. Fixes: e3a35d03407c ("dm writecache: add event counters") Reported-by: Yu Kuai <[email protected]> Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Jul 11 16:30:27 2022 -0400 dm writecache: return void from functions [ Upstream commit 9bc0c92e4b82adb017026dbb2aa816b1ac2bef31 ] The functions writecache_map_remap_origin and writecache_bio_copy_ssd only return a single value, thus they can be made to return void. This helps simplify the following IO accounting changes. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Wed Jul 13 07:09:04 2022 -0400 dm writecache: set a default MAX_WRITEBACK_JOBS [ Upstream commit ca7dc242e358e46d963b32f9d9dd829785a9e957 ] dm-writecache has the capability to limit the number of writeback jobs in progress. However, this feature was off by default. As such there were some out-of-memory crashes observed when lowering the low watermark while the cache is full. This commit enables writeback limit by default. It is set to 256MiB or 1/16 of total system memory, whichever is smaller. Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Snitzer <[email protected]> Date: Fri Jul 22 15:31:23 2022 -0400 dm: return early from dm_pr_call() if DM device is suspended [ Upstream commit e120a5f1e78fab6223544e425015f393d90d6f0d ] Otherwise PR ops may be issued while the broader DM device is being reconfigured, etc. Fixes: 9c72bad1f31a ("dm: call PR reserve/unreserve on each underlying device") Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Tue May 24 10:21:57 2022 -0500 dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics [ Upstream commit c1e33979171da63cf47e56243ccb8ba82363c7d3 ] In accordance with [1, 2] the DW eDMA controller has been created to be part of the DW PCIe Root Port and DW PCIe End-point controllers and to offload the transferring of large blocks of data between application and remote PCIe domains leaving the system CPU free for other tasks. In the first case (eDMA being part of DW PCIe Root Port) the eDMA controller is always accessible via the CPU DBI interface and never over the PCIe wire. The latter case is more complex. Depending on the DW PCIe End-Point IP-core synthesize parameters it's possible to have the eDMA registers accessible not only from the application CPU side, but also via mapping the eDMA CSRs over a dedicated endpoint BAR. So based on the specifics denoted above the eDMA driver is supposed to support two types of the DMA controller setups: 1) eDMA embedded into the DW PCIe Root Port/End-point and accessible over the local CPU from the application side. 2) eDMA embedded into the DW PCIe End-point and accessible via the PCIe wire with MWr/MRd TLPs generated by the CPU PCIe host controller. Since the CPU memory resides different sides in these cases the semantics of the MEM_TO_DEV and DEV_TO_MEM operations is flipped with respect to the Tx and Rx DMA channels. So MEM_TO_DEV/DEV_TO_MEM corresponds to the Tx/Rx channels in setup 1) and to the Rx/Tx channels in case of setup 2). The DW eDMA driver has supported the case 2) since e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") in the framework of the drivers/dma/dw-edma/dw-edma-pcie.c driver. The case 1) support was added later by bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics"). Afterwards the driver was supposed to cover the both possible eDMA setups, but the latter commit turned out to be not fully correct. The problem was that the commit together with the new functionality support also changed the channel direction semantics so the eDMA Read-channel (corresponding to the DMA_DEV_TO_MEM direction for case 1) now uses the sgl/cyclic base addresses as the Source addresses of the DMA transfers and dma_slave_config.dst_addr as the Destination address of the DMA transfers. Similarly the eDMA Write-channel (corresponding to the DMA_MEM_TO_DEV direction for case 1) now uses dma_slave_config.src_addr as a source address of the DMA transfers and sgl/cyclic base address as the Destination address of the DMA transfers. This contradicts the logic of the DMA-interface, which implies that DEV side is supposed to belong to the PCIe device memory and MEM - to the CPU/Application memory. Indeed it seems irrational to have the SG-list defined in the PCIe bus space, while expecting a contiguous buffer allocated in the CPU memory. Moreover the passed SG-list and cyclic DMA buffers are supposed to be mapped in a way so to be seen by the DW eDMA Application (CPU) interface. So in order to have the correct DW eDMA interface we need to invert the eDMA Rd/Wr-channels and DMA-slave directions semantics by selecting the src/dst addresses based on the DMA transfer direction instead of using the channel direction capability. [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v.5.40a, March 2019, p.1092 [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint, v.5.40a, March 2019, p.1189 Co-developed-by: Manivannan Sadhasivam <[email protected]> Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-By: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabio Estevam <[email protected]> Date: Wed Jul 6 08:13:27 2022 -0300 dmaengine: imx-dma: Cast of_device_get_match_data() with (uintptr_t) [ Upstream commit c3266ee185b59e5aab3e0f982e5b7f95d31555a7 ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: drivers/dma/imx-dma.c:1048:20: warning: cast to smaller integer type 'enum imx_dma_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: 0ab785c894e6 ("dmaengine: imx-dma: Remove unused .id_table") Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Viacheslav Mitrofanov <[email protected]> Date: Fri Jul 1 11:29:42 2022 +0300 dmaengine: sf-pdma: Add multithread support for a DMA channel [ Upstream commit b2cc5c465c2cb8ab697c3fd6583c614e3f6cfbcc ] When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 64 > /sys/module/dmatest/parameters/threads_per_chan % echo 10000 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [ 89.480664] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 89.488725] Oops [#1] [ 89.494708] CPU: 2 PID: 1008 Comm: dma0chan0-copy0 Not tainted 5.17.0-rc5 [ 89.509385] epc : vchan_find_desc+0x32/0x46 [ 89.513553] ra : sf_pdma_tx_status+0xca/0xd6 This happens because of data race. Each thread rewrite channels's descriptor as soon as device_prep_dma_memcpy() is called. It leads to the situation when the driver thinks that it uses right descriptor that actually is freed or substituted for other one. With current fixes a descriptor changes its value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. Now it is just possible to queue a descriptor for further processing. Fixes: 6973886ad58e ("dmaengine: sf-pdma: add platform DMA support for HiFive Unleashed A00") Signed-off-by: Viacheslav Mitrofanov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Wensheng <[email protected]> Date: Wed Jun 22 15:43:27 2022 +0800 driver core: fix potential deadlock in __driver_attach [ Upstream commit 70fe758352cafdee72a7b13bf9db065f9613ced8 ] In __driver_attach function, There are also AA deadlock problem, like the commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). stack like commit b232b02bf3c2 ("driver core: fix deadlock in __device_attach"). list below: In __driver_attach function, The lock holding logic is as follows: ... __driver_attach if (driver_allows_async_probing(drv)) device_lock(dev) // get lock dev async_schedule_dev(__driver_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __driver_attach_async_helper will get lock dev as will, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As above show, when it is allowed to do async probes, because of out of memory or work limit, async work is not be allowed, to do sync execute instead. it will lead to A-A deadlock because of __driver_attach_async_helper getting lock dev. Reproduce: and it can be reproduce by make the condition (if (!entry || atomic_read(&entry_count) > MAX_WORK)) untenable, like below: [ 370.785650] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 370.787154] task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00004000 [ 370.788865] Call Trace: [ 370.789374] <TASK> [ 370.789841] __schedule+0x482/0x1050 [ 370.790613] schedule+0x92/0x1a0 [ 370.791290] schedule_preempt_disabled+0x2c/0x50 [ 370.792256] __mutex_lock.isra.0+0x757/0xec0 [ 370.793158] __mutex_lock_slowpath+0x1f/0x30 [ 370.794079] mutex_lock+0x50/0x60 [ 370.794795] __device_driver_lock+0x2f/0x70 [ 370.795677] ? driver_probe_device+0xd0/0xd0 [ 370.796576] __driver_attach_async_helper+0x1d/0xd0 [ 370.797318] ? driver_probe_device+0xd0/0xd0 [ 370.797957] async_schedule_node_domain+0xa5/0xc0 [ 370.798652] async_schedule_node+0x19/0x30 [ 370.799243] __driver_attach+0x246/0x290 [ 370.799828] ? driver_allows_async_probing+0xa0/0xa0 [ 370.800548] bus_for_each_dev+0x9d/0x130 [ 370.801132] driver_attach+0x22/0x30 [ 370.801666] bus_add_driver+0x290/0x340 [ 370.802246] driver_register+0x88/0x140 [ 370.802817] ? virtio_scsi_init+0x116/0x116 [ 370.803425] scsi_register_driver+0x1a/0x30 [ 370.804057] init_sd+0x184/0x226 [ 370.804533] do_one_initcall+0x71/0x3a0 [ 370.805107] kernel_init_freeable+0x39a/0x43a [ 370.805759] ? rest_init+0x150/0x150 [ 370.806283] kernel_init+0x26/0x230 [ 370.806799] ret_from_fork+0x1f/0x30 To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. Fixes: ef0ff68351be ("driver core: Probe devices asynchronously instead of the driver") Signed-off-by: Zhang Wensheng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Len Baker <[email protected]> Date: Sun Aug 15 19:42:04 2021 +0200 drivers/iio: Remove all strcpy() uses [ Upstream commit d722f1e06fbc53eb369b39646945c1fa92068e74 ] strcpy() performs no bounds checking on the destination buffer. This could result in linear overflows beyond the end of the buffer, leading to all kinds of misbehaviors. So, remove all the uses and add devm_kstrdup() or devm_kasprintf() instead. Also, modify the "for" loop conditions to clarify the access to the st->orientation.rotation buffer. This patch is an effort to clean up the proliferation of str*() functions in the kernel and a previous step in the path to remove the strcpy function from the kernel entirely [1]. [1] https://github.com/KSPP/linux/issues/88 Signed-off-by: Len Baker <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anshuman Khandual <[email protected]> Date: Thu Jul 14 11:43:02 2022 +0530 drivers/perf: arm_spe: Fix consistency of SYS_PMSCR_EL1.CX [ Upstream commit 92f2b8bafa3d6e89c750e9d301a8b7ab76aaa8b6 ] The arm_spe_pmu driver will enable SYS_PMSCR_EL1.CX in order to add CONTEXT packets into the traces, if the owner of the perf event runs with required capabilities i.e CAP_PERFMON or CAP_SYS_ADMIN via perfmon_capable() helper. The value of this bit is computed in the arm_spe_event_to_pmscr() function but the check for capabilities happens in the pmu event init callback i.e arm_spe_pmu_event_init(). This suggests that the value of the CX bit should remain consistent for the duration of the perf session. However, the function arm_spe_event_to_pmscr() may be called later during the event start callback i.e arm_spe_pmu_start() when the "current" process is not the owner of the perf session, hence the CX bit setting is currently not consistent. One way to fix this, is by caching the required value of the CX bit during the initialization of the PMU event, so that it remains consistent for the duration of the session. It uses currently unused 'event->hw.flags' element to cache perfmon_capable() value, which can be referred during event start callback to compute SYS_PMSCR_EL1.CX. This ensures consistent availability of context packets in the trace as per event owner capabilities. Drop BIT(SYS_PMSCR_EL1_CX_SHIFT) check in arm_spe_pmu_event_init(), because now CX bit cannot be set in arm_spe_event_to_pmscr() with perfmon_capable() disabled. Cc: Will Deacon <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Alexey Budankov <[email protected]> Cc: [email protected] Cc: [email protected] Fixes: d5d9696b0380 ("drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension") Reported-by: German Gomez <[email protected]> Signed-off-by: Anshuman Khandual <[email protected]> Reviewed-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Li <[email protected]> Date: Tue Jul 12 12:30:29 2022 -0400 drm/amdgpu: Check BO's requested pinning domains against its preferred_domains commit f5ba14043621f4afdf3ad5f92ee2d8dbebbe4340 upstream. When pinning a buffer, we should check to see if there are any additional restrictions imposed by bo->preferred_domains. This will prevent the BO from being moved to an invalid domain when pinning. For example, this can happen if the user requests to create a BO in GTT domain for display scanout. amdgpu_dm will allow pinning to either VRAM or GTT domains, since DCN can scanout from either or. However, in amdgpu_bo_pin_restricted(), pinning to VRAM is preferred if there is adequate carveout. This can lead to pinning to VRAM despite the user requesting GTT placement for the BO. v2: Allow the kernel to override the domain, which can happen when exporting a BO to a V4L camera (for example). Signed-off-by: Leo Li <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alex Deucher <[email protected]> Date: Tue Jul 19 14:56:59 2022 -0400 drm/amdgpu: fix check in fbdev init The new vkms virtual display code is atomic so there is no need to call drm_helper_disable_unused_functions() when it is enabled. Doing so can result in a segfault. When the driver switched from the old virtual display code to the new atomic virtual display code, it was missed that we enable virtual display unconditionally under SR-IOV so the checks here missed that case. Add the missing check for SR-IOV. There is no equivalent of this patch for Linus' tree because the relevant code no longer exists. This patch is only relevant to kernels 5.15 and 5.16. Fixes: 84ec374bd580 ("drm/amdgpu: create amdgpu_vkms (v4)") Cc: [email protected] # 5.15.x Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: xinhui pan <[email protected]> Date: Fri Jul 8 09:22:44 2022 +0800 drm/amdgpu: Remove one duplicated ef removal [ Upstream commit e1aadbab445b06e072013a1365fd0cf2aa25e843 ] That has been done in BO release notify. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2074 Signed-off-by: xinhui pan <[email protected]> Acked-by: Christian König <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maxime Ripard <[email protected]> Date: Fri Sep 10 15:09:39 2021 +0200 drm/bridge: Add a function to abstract away panels [ Upstream commit 87ea95808d53e56b03e620e8f8f3add48899a88d ] Display drivers so far need to have a lot of boilerplate to first retrieve either the panel or bridge that they are connected to using drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc functions or create a drm panel bridge through drm_panel_bridge_add. In order to reduce the boilerplate and hopefully create a path of least resistance towards using the DRM panel bridge layer, let's create the function devm_drm_of_get_bridge() to reduce that boilerplate. Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bjorn Andersson <[email protected]> Date: Wed Jun 1 16:38:18 2022 -0700 drm/bridge: lt9611uxc: Cancel only driver's work [ Upstream commit dfa687bffc8a4a21ed929c7dececf01b8f1f52ee ] During device remove care needs to be taken that no work is pending before it removes the underlying DRM bridge etc, but this can be done on the specific work rather than waiting for the flush of the system-wide workqueue. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Maxime Ripard <[email protected]> Date: Fri Sep 17 20:09:25 2021 +0200 drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c commit d4ae66f10c8b9959dce1766d9a87070e567236eb upstream. By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge() introduces a circular dependency between the modules drm (where devm_drm_of_get_bridge() ends up) and drm_kms_helper (where devm_drm_panel_bridge_add() is). Fix this by moving devm_drm_of_get_bridge() to bridge/panel.c and thus drm_kms_helper. Fixes: 87ea95808d53 ("drm/bridge: Add a function to abstract away panels") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Apr 28 23:31:32 2022 +0200 drm/bridge: tc358767: Fix (e)DP bridge endpoint parsing in dedicated function commit 9030a9e571b3ba250d3d450a98310e3c74ecaff4 upstream. Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP port is optional. In case this port is not described in DT, the bridge driver operates in DPI-to-DP mode. The drm_of_find_panel_or_bridge() call in tc_probe_edp_bridge_endpoint() returns -ENODEV in case port@2 is not present in DT and this specific return value is incorrectly propagated outside of tc_probe_edp_bridge_endpoint() function. All other error values must be propagated and are propagated correctly. Return 0 in case the port@2 is missing instead, that reinstates the original behavior before the commit this patch fixes. Fixes: 8478095a8c4b ("drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function") Signed-off-by: Marek Vasut <[email protected]> Cc: Jonas Karlman <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Lucas Stach <[email protected]> Cc: Marek Vasut <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Robert Foss <[email protected]> Cc: Sam Ravnborg <[email protected]> Reviewed-by: Lucas Stach <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Tue Mar 29 10:50:10 2022 +0200 drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function [ Upstream commit 8478095a8c4bcea3c83b0767d6c9127434160761 ] The TC358767/TC358867/TC9595 are all capable of operating in multiple modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is currently supported. In order to support the rest of the modes without making the tc_probe() overly long, split the bridge endpoint parsing into dedicated function, where the necessary logic to detect the bridge mode based on which endpoints are connected, can be implemented. Reviewed-by: Lucas Stach <[email protected]> Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode. Signed-off-by: Marek Vasut <[email protected]> Cc: Jonas Karlman <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Imre Deak <[email protected]> Date: Tue Jun 14 12:45:37 2022 +0300 drm/dp/mst: Read the extended DPCD capabilities during system resume [ Upstream commit 7a710a8bc909313951eb9252d8419924c771d7c2 ] The WD22TB4 Thunderbolt dock at least will revert its DP_MAX_LINK_RATE from HBR3 to HBR2 after system suspend/resume if the DP_DP13_DPCD_REV registers are not read subsequently also as required. Fix this by reading DP_DP13_DPCD_REV registers as well, matching what is done during connector detection. While at it also fix up the same call in drm_dp_mst_dump_topology(). Cc: Lyude Paul <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5292 Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Cc: <[email protected]> # v5.14+ Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Douglas Anderson <[email protected]> Date: Tue May 10 12:29:41 2022 -0700 drm/dp: Export symbol / kerneldoc fixes for DP AUX bus [ Upstream commit 39c28cdfb719f0e306b447f0827dfd712f81858b ] While working on the DP AUX bus code I found a few small things that should be fixed. Namely the non-devm version of of_dp_aux_populate_ep_devices() was missing an export. There was also an extra blank line in a kerneldoc and a kerneldoc that incorrectly documented a return value. Fix these. Fixes: aeb33699fc2c ("drm: Introduce the DP AUX bus") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20220510122726.v3.1.Ia91f4849adfc5eb9da1eb37ba79aa65fb3c95a0f@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Zhang <[email protected]> Date: Tue Jul 12 13:56:11 2022 +0900 drm/exynos/exynos7_drm_decon: free resources when clk_set_parent() failed. [ Upstream commit 48b927770f8ad3f8cf4a024a552abf272af9f592 ] In exynos7_decon_resume, When it fails, we must use clk_disable_unprepare() to free resource that have been used. Fixes: 6f83d20838c09 ("drm/exynos: use DRM_DEV_ERROR to print out error message") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jian Zhang <[email protected]> Signed-off-by: Inki Dae <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Osipenko <[email protected]> Date: Thu Jun 30 23:04:04 2022 +0300 drm/gem: Properly annotate WW context on drm_gem_lock_reservations() error commit 2939deac1fa220bc82b89235f146df1d9b52e876 upstream. Use ww_acquire_fini() in the error code paths. Otherwise lockdep thinks that lock is held when lock's memory is freed after the drm_gem_lock_reservations() error. The ww_acquire_context needs to be annotated as "released", which fixes the noisy "WARNING: held lock freed!" splat of VirtIO-GPU driver with CONFIG_DEBUG_MUTEXES=y and enabled lockdep. Cc: [email protected] Fixes: 7edc3e3b975b5 ("drm: Add helpers for locking an array of BO reservations.") Reviewed-by: Thomas Hellström <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Wed Jun 22 10:34:13 2022 +0200 drm/hyperv-drm: Include framebuffer and EDID headers commit 009a3a52791f31c57d755a73f6bc66fbdd8bd76c upstream. Fix a number of compile errors by including the correct header files. Examples are shown below. ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_blit_to_vram_rect': ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:25:48: error: invalid use of undefined type 'struct drm_framebuffer' 25 | struct hyperv_drm_device *hv = to_hv(fb->dev); | ^~ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c: In function 'hyperv_connector_get_modes': ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:59:17: error: implicit declaration of function 'drm_add_modes_noedid' [-Werror=implicit-function-declaration] 59 | count = drm_add_modes_noedid(connector, | ^~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/hyperv/hyperv_drm_modeset.c:62:9: error: implicit declaration of function 'drm_set_preferred_mode'; did you mean 'drm_mm_reserve_node'? [-Werror=implicit-function-declaration] 62 | drm_set_preferred_mode(connector, hv->preferred_width, | ^~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Fixes: 720cf96d8fec ("drm: Drop drm_framebuffer.h from drm_crtc.h") Fixes: 255490f9150d ("drm: Drop drm_edid.h from drm_crtc.h") Cc: Deepak Rawat <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v5.14+ Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed May 25 15:54:11 2022 +0400 drm/mcde: Fix refcount leak in mcde_dsi_bind [ Upstream commit 3a149169e4a2f9127022fec6ef5d71b4e804b3b9 ] Every iteration of for_each_available_child_of_node() decrements the reference counter of the previous node. There is no decrement when break out from the loop and results in refcount leak. Add missing of_node_put() to fix this. Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Xinlei Lee <[email protected]> Date: Fri May 20 10:00:07 2022 +0800 drm/mediatek: Add pull-down MIPI operation in mtk_dsi_poweroff function [ Upstream commit fa5d0a0205c34734c5b8daa77e39ac2817f63a10 ] In the dsi_enable function, mtk_dsi_rxtx_control is to pull up the MIPI signal operation. Before dsi_disable, MIPI should also be pulled down by writing a register instead of disabling dsi. If disable dsi without pulling the mipi signal low, the value of the register will still maintain the setting of the mipi signal being pulled high. After resume, even if the mipi signal is not pulled high, it will still be in the high state. Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Signed-off-by: Jitao Shi <[email protected]> Signed-off-by: Xinlei Lee <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Julien STEPHAN <[email protected]> Date: Mon Feb 14 10:27:42 2022 +0100 drm/mediatek: Allow commands to be sent during video mode [ Upstream commit 81cc7e51c4f1686b71e30046437056ece6b2cb4d ] Mipi dsi panel drivers can use mipi_dsi_dcs_{set,get}_display_brightness() to request backlight changes. This can be done during panel initialization (dsi is in command mode) or afterwards (dsi is in Video Mode). When the DSI is in Video Mode, all commands are rejected. Detect current DSI mode in mtk_dsi_host_transfer() and switch modes temporarily to allow commands to be sent. Signed-off-by: Julien STEPHAN <[email protected]> Signed-off-by: Mattijs Korpershoek <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guillaume Ranquet <[email protected]> Date: Fri Jul 1 11:58:44 2022 +0800 drm/mediatek: dpi: Only enable dpi after the bridge is enabled [ Upstream commit aed61ef6beb911cc043af0f2f291167663995065 ] Enabling the dpi too early causes glitches on screen. Move the call to mtk_dpi_enable() at the end of the bridge_enable callback to ensure everything is setup properly before enabling dpi. Fixes: 9e629c17aa8d ("drm/mediatek: Add DPI sub driver") Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bo-Chen Chen <[email protected]> Date: Fri Jul 1 11:58:33 2022 +0800 drm/mediatek: dpi: Remove output format of YUV [ Upstream commit c9ed0713b3c35fc45677707ba47f432cad95da56 ] DPI is not support output format as YUV, but there is the setting of configuring output YUV. Therefore, remove them in this patch. Fixes: 9e629c17aa8d ("drm/mediatek: Add DPI sub driver") Signed-off-by: Bo-Chen Chen <[email protected]> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jitao Shi <[email protected]> Date: Fri May 20 10:00:06 2022 +0800 drm/mediatek: Keep dsi as LP00 before dcs cmds transfer [ Upstream commit 39e8d062b03c3dc257d880d82bd55cdd9e185a3b ] To comply with the panel sequence, hold the mipi signal to LP00 before the dcs cmds transmission, and pull the mipi signal high from LP00 to LP11 until the start of the dcs cmds transmission. The normal panel timing is : (1) pp1800 DC pull up (2) avdd & avee AC pull high (3) lcm_reset pull high -> pull low -> pull high (4) Pull MIPI signal high (LP11) -> initial code -> send video data (HS mode) The power-off sequence is reversed. If dsi is not in cmd mode, then dsi will pull the mipi signal high in the mtk_output_dsi_enable function. The delay in lane_ready func is the reaction time of dsi_rx after pulling up the mipi signal. Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Cc: <[email protected]> # 5.10.x: 7f6335c6a258: drm/mediatek: Modify dsi funcs to atomic operations Cc: <[email protected]> # 5.10.x: cde7e2e35c28: drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs Cc: <[email protected]> # 5.10.x Signed-off-by: Jitao Shi <[email protected]> Signed-off-by: Xinlei Lee <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xinlei Lee <[email protected]> Date: Fri May 20 10:00:04 2022 +0800 drm/mediatek: Modify dsi funcs to atomic operations [ Upstream commit 7f6335c6a258edf4d5ff1b904bc033188dc7b48b ] Because .enable & .disable are deprecated. Use .atomic_enable & .atomic_disable instead. Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Signed-off-by: Jitao Shi <[email protected]> Signed-off-by: Xinlei Lee <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jitao Shi <[email protected]> Date: Fri May 20 10:00:05 2022 +0800 drm/mediatek: Separate poweron/poweroff from enable/disable and define new funcs [ Upstream commit cde7e2e35c2866d22a3a012e72a41052dfcc255d ] In order to match the changes of "Use the drm_panel_bridge API", the poweron/poweroff of dsi is extracted from enable/disable and defined as new funcs (atomic_pre_enable/atomic_post_disable). Since dsi_poweron is moved from dsi_enable to pre_enable function, in order to avoid poweron failure, the operation of dsi register fails to cause bus hang. Therefore, the protection mechanism is added to the dsi_enable function. Fixes: 2dd8075d2185 ("drm/mediatek: mtk_dsi: Use the drm_panel_bridge API") Link: https://patchwork.kernel.org/project/linux-mediatek/patch/[email protected]/ Signed-off-by: Jitao Shi <[email protected]> Signed-off-by: Xinlei Lee <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed Jun 1 07:39:27 2022 +0400 drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_init [ Upstream commit d82a5a4aae9d0203234737caed1bf470aa317568 ] of_graph_get_remote_node() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: e67f6037ae1b ("drm/meson: split out encoder from meson_dw_hdmi") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Neil Armstrong <[email protected]> Date: Wed Oct 20 14:39:45 2021 +0200 drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR [ Upstream commit 0af5e0b41110e2da872030395231ab19c45be931 ] This implements the necessary change to no more use the embedded connector in dw-hdmi and use the dedicated bridge connector driver by passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to the bridge attach call. The necessary connector properties are added to handle the same functionalities as the embedded dw-hdmi connector, i.e. the HDR metadata, the CEC notifier & other flags. The dw-hdmi output_port is set to 1 in order to look for a connector next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working. Signed-off-by: Neil Armstrong <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed May 11 09:40:51 2022 +0400 drm/meson: Fix refcount leak in meson_encoder_hdmi_init commit 7381076809586528e2a812a709e2758916318a99 upstream. of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() in error path to avoid refcount leak. Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yunhao Tian <[email protected]> Date: Tue May 10 11:02:19 2022 +0800 drm/mipi-dbi: align max_chunk to 2 in spi_transfer [ Upstream commit 435c249008cba04ed6a7975e9411f3b934620204 ] In __spi_validate, there's a validation that no partial transfers are accepted (xfer->len % w_size must be zero). When max_chunk is not a multiple of bpw (e.g. max_chunk = 65535, bpw = 16), the transfer will be rejected. This patch aligns max_chunk to 2 bytes (the maximum value of bpw is 16), so that no partial transfer will occur. Fixes: d23d4d4dac01 ("drm/tinydrm: Move tinydrm_spi_transfer()") Signed-off-by: Yunhao Tian <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Clark <[email protected]> Date: Thu Jul 7 14:20:00 2022 -0700 drm/msm/dpu: Fix for non-visible planes [ Upstream commit cb77085b1f0a86ef9dfba86b5f3ed6c3340c2ea3 ] Fixes `kms_cursor_crc --run-subtest cursor-offscreen`.. when the cursor moves offscreen the plane becomes non-visible, so we need to skip over it in crtc atomic test and mixer setup. Signed-off-by: Rob Clark <[email protected]> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/492819/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Clark <[email protected]> Date: Thu Jul 7 09:20:37 2022 -0700 drm/msm/mdp5: Fix global state lock backoff [ Upstream commit 92ef86ab513593c6329d04146e61f9a670e72fc5 ] We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0. Fixes an issue that the new CONFIG_DRM_DEBUG_MODESET_LOCK stuff flagged in CI: WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drm_modeset_lock.c:296 drm_modeset_lock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kms_cursor_lega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock+0xf8/0x154 lr : drm_atomic_get_private_obj_state+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drm_modeset_lock+0xf8/0x154 drm_atomic_get_private_obj_state+0x84/0x170 mdp5_get_global_state+0x54/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x2ec/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drm_modeset_lock attempting to lock a contended lock without backoff: drm_modeset_lock+0x148/0x154 mdp5_get_global_state+0x30/0x6c mdp5_pipe_release+0x2c/0xd4 mdp5_plane_atomic_check+0x290/0x414 drm_atomic_helper_check_planes+0xd8/0x210 drm_atomic_helper_check+0x54/0xb0 drm_atomic_check_only+0x4b0/0x8f4 drm_atomic_commit+0x68/0xe0 Fixes: d59be579fa93 ("drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected") Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/492701/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Clark <[email protected]> Date: Wed Feb 23 11:11:08 2022 -0800 drm/msm: Avoid dirtyfb stalls on video mode displays (v2) [ Upstream commit 9e4dde28e9cd34ee13a6b7247f0857fb49fd3f19 ] Someone on IRC once asked an innocent enough sounding question: Why with xf86-video-modesetting is es2gears limited at 120fps. So I broke out the perfetto tracing mesa MR and took a look. It turns out the problem was drm_atomic_helper_dirtyfb(), which would end up waiting for vblank.. es2gears would rapidly push two frames to Xorg, which would blit them to screen and in idle hook (I assume) call the DIRTYFB ioctl. Which in turn would do an atomic update to flush the dirty rects, which would stall until the next vblank. And then the whole process would repeat. But this is a bit silly, we only need dirtyfb for command mode DSI panels. So track in plane state whether dirtyfb is required, and track in the fb how many attached planes require dirtyfb so that we can skip it when not required. (Note, mdp4 does not actually have cmd mode support.) Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rob Clark <[email protected]> Date: Fri Mar 4 12:21:45 2022 -0800 drm/msm: Fix dirtyfb refcounting commit 9225b337072a10bf9b09df8bf281437488dd8a26 upstream. refcount_t complains about 0->1 transitions, which isn't *quite* what we wanted. So use dirtyfb==1 to mean that the fb is not connected to any output that requires dirtyfb flushing, so that we can keep the underflow and overflow checking. Fixes: 9e4dde28e9cd ("drm/msm: Avoid dirtyfb stalls on video mode displays (v2)") Signed-off-by: Rob Clark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lyude Paul <[email protected]> Date: Thu Jul 14 13:42:33 2022 -0400 drm/nouveau/acpi: Don't print error when we get -EINPROGRESS from pm_runtime commit 53c26181950ddc3c8ace3c0939c89e9c4d8deeb9 upstream. Since this isn't actually a failure. Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: David Airlie <[email protected]> Fixes: 79e765ad665d ("drm/nouveau/drm/nouveau: Prevent handling ACPI HPD events too early") Cc: <[email protected]> # v4.19+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lyude Paul <[email protected]> Date: Thu May 26 16:43:13 2022 -0400 drm/nouveau/kms: Fix failure path for creating DP connectors commit ca0367ca5d9216644b41f86348d6661f8d9e32d8 upstream. It looks like that when we moved nouveau over to using drm_dp_aux_init() and registering it's aux bus during late connector registration, we totally forgot to fix the failure codepath in nouveau_connector_create() - as it still seems to assume that drm_dp_aux_init() can fail (it can't). So, let's fix that and also add a missing check to ensure that we've properly allocated nv_connector->aux.name while we're at it. Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: David Airlie <[email protected]> Fixes: fd43ad9d47e7 ("drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister") Cc: <[email protected]> # v5.14+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lyude Paul <[email protected]> Date: Thu Jul 14 13:42:34 2022 -0400 drm/nouveau: Don't pm_runtime_put_sync(), only pm_runtime_put_autosuspend() commit c96cfaf8fc02d4bb70727dfa7ce7841a3cff9be2 upstream. While trying to fix another issue, it occurred to me that I don't actually think there is any situation where we want pm_runtime_put() in nouveau to be synchronous. In fact, this kind of just seems like it would cause issues where we may unexpectedly block a thread we don't expect to be blocked. So, let's only use pm_runtime_put_autosuspend(). Changes since v1: * Use pm_runtime_put_autosuspend(), not pm_runtime_put() Signed-off-by: Lyude Paul <[email protected]> Reviewed-by: David Airlie <[email protected]> Fixes: 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE") Cc: Hans de Goede <[email protected]> Cc: <[email protected]> # v4.10+ Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Timur Tabi <[email protected]> Date: Wed May 11 11:37:16 2022 -0500 drm/nouveau: fix another off-by-one in nvbios_addr commit c441d28945fb113220d48d6c86ebc0b090a2b677 upstream. This check determines whether a given address is part of image 0 or image 1. Image 1 starts at offset image0_size, so that address should be included. Fixes: 4d4e9907ff572 ("drm/nouveau/bios: guard against out-of-bounds accesses to image") Cc: <[email protected]> # v4.8+ Signed-off-by: Timur Tabi <[email protected]> Reviewed-by: Karol Herbst <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gao Chao <[email protected]> Date: Tue May 24 10:45:51 2022 +0800 drm/panel: Fix build error when CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m [ Upstream commit a67664860f7833015a683ea295f7c79ac2901332 ] If CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20=y && CONFIG_DRM_DISPLAY_HELPER=m, bulding fails: drivers/gpu/drm/panel/panel-samsung-atna33xc20.o: In function `atana33xc20_probe': panel-samsung-atna33xc20.c:(.text+0x744): undefined reference to `drm_panel_dp_aux_backlight' make: *** [vmlinux] Error 1 Let CONFIG_DRM_PANEL_SAMSUNG_ATNA33XC20 select DRM_DISPLAY_DP_HELPER and CONFIG_DRM_DISPLAY_HELPER to fix this error. Fixes: 32ce3b320343 ("drm/panel: atna33xc20: Introduce the Samsung ATNA33XC20 panel") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Gao Chao <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Deucher <[email protected]> Date: Wed Jun 15 12:02:08 2022 -0400 drm/radeon: fix incorrrect SPDX-License-Identifiers [ Upstream commit 1f43b8903f3aae4a26a603c36f6d5dd25d6edb51 ] radeon is MIT. This were incorrectly changed in commit b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") and commit d198b34f3855 (".gitignore: add SPDX License Identifier") and: commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") Fixes: d198b34f3855 (".gitignore: add SPDX License Identifier") Fixes: ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") Fixes: b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to files with no license") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2053 Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Kodanev <[email protected]> Date: Mon Jun 6 16:50:54 2022 +0300 drm/radeon: fix potential buffer overflow in ni_set_mc_special_registers() [ Upstream commit 136f614931a2bb73616b292cf542da3a18daefd5 ] The last case label can write two buffers 'mc_reg_address[j]' and 'mc_data[j]' with 'j' offset equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE since there are no checks for this value in both case labels after the last 'j++'. Instead of changing '>' to '>=' there, add the bounds check at the start of the second 'case' (the first one already has it). Also, remove redundant last checks for 'j' index bigger than array size. The expression is always false. Moreover, before or after the patch 'table->last' can be equal to SMC_NISLANDS_MC_REGISTER_ARRAY_SIZE and it seems it can be a valid value. Detected using the static analysis tool - Svace. Fixes: 69e0b57a91ad ("drm/radeon/kms: add dpm support for cayman (v5)") Signed-off-by: Alexey Kodanev <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sat Jun 18 19:08:05 2022 +0200 drm/rockchip: Fix an error handling path rockchip_dp_probe() [ Upstream commit 5074376822fe99fa4ce344b851c5016d00c0444f ] Should component_add() fail, we should call analogix_dp_remove() in the error handling path, as already done in the remove function. Fixes: 152cce0006ab ("drm/bridge: analogix_dp: Split bind() into probe() and real bind()") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b719d9061bb97eb85145fbd3c5e63f4549f2e13e.1655572071.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Norris <[email protected]> Date: Fri Jun 17 17:26:52 2022 -0700 drm/rockchip: vop: Don't crash for invalid duplicate_state() [ Upstream commit 1449110b0dade8b638d2c17ab7c5b0ff696bfccb ] It's possible for users to try to duplicate the CRTC state even when the state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other users of __drm_atomic_helper_crtc_duplicate_state()) already guard this with a WARN_ON() instead of crashing, so let's do that here too. Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config") Signed-off-by: Brian Norris <[email protected]> Reviewed-by: Sean Paul <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20220617172623.1.I62db228170b1559ada60b8d3e1637e1688424926@changeid Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Osipenko <[email protected]> Date: Thu Jun 30 23:00:57 2022 +0300 drm/shmem-helper: Add missing vunmap on error commit df4aaf015775221dde8a51ee09edb919981f091e upstream. The vmapping of dma-buf may succeed, but DRM SHMEM rejects the IOMEM mapping, and thus, drm_gem_shmem_vmap_locked() should unvmap the IOMEM before erroring out. Cc: [email protected] Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends") Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Mon Nov 8 10:31:48 2021 +0100 drm/shmem-helper: Export dedicated wrappers for GEM object functions [ Upstream commit c7fbcb7149ff9321bbbcc93c9920de534ea8102c ] Wrap GEM SHMEM functions for struct drm_gem_object_funcs and update all callers. This will allow for an update of the public interfaces of the GEM SHMEM helper library. v2: * fix docs for drm_gem_shmem_object_print_info() Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Mon Nov 8 10:31:49 2021 +0100 drm/shmem-helper: Pass GEM shmem object in public interfaces [ Upstream commit a193f3b4e050e35c506a34d0870c838d8e0b0449 ] Change all GEM SHMEM object functions that receive a GEM object of type struct drm_gem_object to expect an object of type struct drm_gem_shmem_object instead. This change reduces the number of upcasts from struct drm_gem_object by moving them into callers. The C compiler can now verify that the GEM SHMEM functions are called with the correct type. For consistency, the patch also renames drm_gem_shmem_free_object to drm_gem_shmem_free. It further updates documentation for a number of functions. v3: * fix docs for drm_gem_shmem_object_free() v2: * mention _object_ callbacks in docs (Daniel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Mon Nov 8 10:31:47 2021 +0100 drm/shmem-helper: Unexport drm_gem_shmem_create_with_handle() [ Upstream commit 5a363c20673308e968b6640deb73d7bf77e8b463 ] Turn drm_gem_shmem_create_with_handle() into an internal helper function. It's not used outside of the compilation unit. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Javier Martinez Canillas <[email protected]> Date: Fri May 20 11:16:02 2022 +0200 drm/st7735r: Fix module autoloading for Okaya RH128128T [ Upstream commit 9ad6f181ad9a19a26bda73a7b199df44ccfcdaba ] The SPI core always reports a "MODALIAS=spi:<foo>", even if the device was registered via OF. This means that the st7735r.ko module won't autoload if a DT has a node with a compatible "okaya,rh128128t" string. In that case, kmod expects a "MODALIAS=of:N*T*Cokaya,rh128128t" uevent but instead will get a "MODALIAS=spi:rh128128t", which is not present in the list of aliases: $ modinfo drivers/gpu/drm/tiny/st7735r.ko | grep alias alias: of:N*T*Cokaya,rh128128tC* alias: of:N*T*Cokaya,rh128128t alias: of:N*T*Cjianda,jd-t18003-t01C* alias: of:N*T*Cjianda,jd-t18003-t01 alias: spi:jd-t18003-t01 To workaround this issue, add in the SPI table an entry for that device. Fixes: d1d511d516f7 ("drm: tiny: st7735r: Add support for Okaya RH128128T") Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Acked-by: David Lechner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tom Rix <[email protected]> Date: Wed Jun 29 16:01:01 2022 -0400 drm/vc4: change vc4_dma_range_matches from a global to static commit 63569d90863ff26c8b10c8971d1271c17a45224b upstream. sparse reports drivers/gpu/drm/vc4/vc4_drv.c:270:27: warning: symbol 'vc4_dma_range_matches' was not declared. Should it be static? vc4_dma_range_matches is only used in vc4_drv.c, so it's storage class specifier should be static. Fixes: da8e393e23ef ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component") Signed-off-by: Tom Rix <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:28 2022 +0200 drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component [ Upstream commit da8e393e23efb60eba8959856c7df88f9859f6eb ] vc4_drv isn't necessarily under the /soc node in DT as it is a virtual device, but it is the one that does the allocations. The DMA addresses are consumed by primarily the HVS or V3D, and those require VideoCore cache alias address mapping, and so will be under /soc. During probe find the a suitable device node for HVS or V3D, and adopt the DMA configuration of that node. Cc: <[email protected]> Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:43 2022 +0200 drm/vc4: dsi: Add correct stop condition to vc4_dsi_encoder_disable iteration [ Upstream commit 7bcb9c8d0bc9f3cab8ac2634b056c2e6b63945ca ] vc4_dsi_encoder_disable is partially an open coded version of drm_bridge_chain_disable, but it missed a termination condition in the loop for ->disable which meant that no post_disable calls were made. Add in the termination clause. Fixes: 033bfe7538a1 ("drm/vc4: dsi: Fix bridge chain handling") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:39 2022 +0200 drm/vc4: dsi: Correct DSI divider calculations [ Upstream commit 3b45eee87da171caa28f61240ddb5c21170cda53 ] The divider calculations tried to find the divider just faster than the clock requested. However if it required a divider of 7 then the for loop aborted without handling the "error" case, and could end up with a clock lower than requested. The integer divider from parent PLL to DSI clock is also capable of going up to /255, not just /7 that the driver was trying. This allows for slower link frequencies on the DSI bus where the resolution permits. Correct the loop so that we always have a clock greater than requested, and covering the whole range of dividers. Fixes: 86c1b9eff3f2 ("drm/vc4: Adjust modes in DSI to work around the integer PLL divider.") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:40 2022 +0200 drm/vc4: dsi: Correct pixel order for DSI0 [ Upstream commit edfe84ae0df16be1251b5a8e840d95f1f3827500 ] For slightly unknown reasons, dsi0 takes a different pixel format to dsi1, and that has to be set in the pixel valve. Amend the setup accordingly. Fixes: a86773d120d7 ("drm/vc4: Add support for feeding DSI encoders from the pixel valve.") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:42 2022 +0200 drm/vc4: dsi: Fix dsi0 interrupt support [ Upstream commit bc5b815e06f90cccdb6461aba1e49fdc2f3c8cd1 ] DSI0 seemingly had very little or no testing as a load of the register mappings were incorrect/missing, so host transfers always timed out due to enabling/checking incorrect bits in the interrupt enable and status registers. Fixes: 4078f5757144 ("drm/vc4: Add DSI driver") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:41 2022 +0200 drm/vc4: dsi: Register dsi0 as the correct vc4 encoder type [ Upstream commit 4d9273c978d4c1af15d7874c10c732ec83d444d0 ] vc4_dsi was registering both dsi0 and dsi1 as VC4_ENCODER_TYPE_DSI1 which seemed to work OK for a single DSI display, but fails if there are two DSI displays connected. Update to register the correct type. Fixes: 4078f5757144 ("drm/vc4: Add DSI driver") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:38 2022 +0200 drm/vc4: dsi: Release workaround buffer and DMA [ Upstream commit 89c4bbe2a01ea401c2b0fabc104720809084b77f ] On Pi0-3 the driver allocates a buffer and requests a DMA channel because the ARM can't write to DSI1's registers directly. However, we never release that buffer or channel. Let's add a device-managed action to release each. Fixes: 4078f5757144 ("drm/vc4: Add DSI driver") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maxime Ripard <[email protected]> Date: Fri Sep 10 15:09:41 2021 +0200 drm/vc4: dsi: Switch to devm_drm_of_get_bridge [ Upstream commit a43dd76bacd0d5441a4c84f60d64bdfaedc95bac ] The new devm_drm_of_get_bridge removes most of the boilerplate we have to deal with. Let's switch to it. Signed-off-by: Maxime Ripard <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dom Cobley <[email protected]> Date: Mon Jun 13 16:47:47 2022 +0200 drm/vc4: hdmi: Avoid full hdmi audio fifo writes [ Upstream commit 1c594eeccf92368177c2e22f1d3ee4933dfb8567 ] We are getting occasional VC4_HD_MAI_CTL_ERRORF in HDMI_MAI_CTL which seem to correspond with audio dropouts. Reduce the threshold where we deassert DREQ to avoid the fifo overfilling Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Dom Cobley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:59 2022 +0200 drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes [ Upstream commit fb10dc451c0f15e3c19798a2f41d357f3f7576f5 ] For interlaced modes the timings were not being correctly programmed into the HDMI block, so correct them. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Phil Elwell <[email protected]> Date: Mon Jun 13 16:47:44 2022 +0200 drm/vc4: hdmi: Disable audio if dmas property is present but empty commit db2b927f8668adf3ac765e0921cd2720f5c04172 upstream. The dmas property is used to hold the dmaengine channel used for audio output. Older device trees were missing that property, so if it's not there we disable the audio output entirely. However, some overlays have set an empty value to that property, mostly to workaround the fact that overlays cannot remove a property. Let's add a test for that case and if it's empty, let's disable it as well. Cc: <[email protected]> Signed-off-by: Phil Elwell <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maxime Ripard <[email protected]> Date: Mon Oct 25 17:28:55 2021 +0200 drm/vc4: hdmi: Fix HPD GPIO detection [ Upstream commit e32e5723256a99c5324824503572f743377dd0fe ] Prior to commit 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod"), in the detect hook, if we had an HPD GPIO we would only rely on it and return whatever state it was in. However, that commit changed that by mistake to only consider the case where we have a GPIO and it returns a logical high, and would fall back to the other methods otherwise. Since we can read the EDIDs when the HPD signal is low on some displays, we changed the detection status from disconnected to connected, and we would ignore an HPD pulse. Fixes: 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod") Signed-off-by: Maxime Ripard <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mateusz Kwiatkowski <[email protected]> Date: Mon Jun 13 16:47:57 2022 +0200 drm/vc4: hdmi: Fix timings for interlaced modes [ Upstream commit 0ee5a40152b15f200ed3a0d51e8aa782ea979c6a ] Increase the number of post-sync blanking lines on odd fields instead of decreasing it on even fields. This makes the total number of lines properly match the modelines. Additionally fix the value of PV_VCONTROL_ODD_DELAY, which did not take pixels_per_clock into account, causing some displays to invert the fields when driven by bcm2711. Fixes: 682e62c45406 ("drm/vc4: Fix support for interlaced modes on HDMI.") Signed-off-by: Mateusz Kwiatkowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:48 2022 +0200 drm/vc4: hdmi: Reset HDMI MISC_CONTROL register [ Upstream commit 35dc00c12a72700a9c4592afee7d136ecb280cbd ] The HDMI block can repeat pixels for double clocked modes, and the firmware is now configuring the block to do this as the PV is doing it incorrectly when at 2pixels/clock. If the kernel doesn't reset it then we end up with strange modes. Reset MISC_CONTROL. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Jun 13 16:47:32 2022 +0200 drm/vc4: plane: Fix margin calculations for the right/bottom edges [ Upstream commit b7c3d6821627861f4ea3e1f2b595d0ed9e80aac8 ] The current plane margin calculation code clips the right and bottom edges of the range based using the left and top margins. This is obviously wrong, so let's fix it. Fixes: 666e73587f90 ("drm/vc4: Take margin setup into account when updating planes") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dom Cobley <[email protected]> Date: Mon Jun 13 16:47:31 2022 +0200 drm/vc4: plane: Remove subpixel positioning check [ Upstream commit 517db1ab1566dba3093dbdb8de4263ba4aa66416 ] There is little harm in ignoring fractional coordinates (they just get truncated). Without this: modetest -M vc4 -F tiles,gradient -s 32:1920x1080-60 -P89@74:1920x1080*.1.1@XR24 is rejected. We have the same issue in Kodi when trying to use zoom options on video. Note: even if all coordinates are fully integer. e.g. src:[0,0,1920,1080] dest:[-10,-10,1940,1100] it will still get rejected as drm_atomic_helper_check_plane_state uses drm_rect_clip_scaled which transforms this to fractional src coords Fixes: 21af94cf1a4c ("drm/vc4: Add support for scaling of display planes.") Signed-off-by: Dom Cobley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Minghao Chi (CGEL ZTE) <[email protected]> Date: Mon Feb 14 02:05:30 2022 +0000 drm/vc4: Use of_device_get_match_data() [ Upstream commit 9cbe89ede58294d23af06ec12c20f2ce6acc1892 ] Use of_device_get_match_data() to simplify the code. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Minghao Chi (CGEL ZTE) <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu Jun 2 14:42:22 2022 +0400 drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init [ Upstream commit c24968734abfed81c8f93dc5f44a7b7a9aecadfa ] Since drm_prime_pages_to_sg() function return error pointers. The drm_gem_shmem_get_sg_table() function returns error pointers too. Using IS_ERR() to check the return value to fix this. Fixes: 2f2aa13724d5 ("drm/virtio: move virtio_gpu_mem_entry initialization to new function") Signed-off-by: Miaoqian Lin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antonio Borneo <[email protected]> Date: Tue Jun 7 23:31:44 2022 +0200 drm: adv7511: override i2c address of cec before accessing it [ Upstream commit 9cc4853e4781bf0dd0f35355dc92d97c9da02f5d ] Commit 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device") allows a device tree node to override the default addresses of the secondary i2c devices. This is useful for solving address conflicts on the i2c bus. In adv7511_init_cec_regmap() the new i2c address of cec device is read from device tree and immediately accessed, well before it is written in the proper register to override the default address. This can cause an i2c error during probe and a consequent probe failure. Once the new i2c address is read from the device tree, override the default address before any attempt to access the cec. Tested with adv7533 and stm32mp157f. Signed-off-by: Antonio Borneo <[email protected]> Fixes: 680532c50bca ("drm: adv7511: Add support for i2c_new_secondary_device") Reviewed-by: Kieran Bingham <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Thu Jun 2 18:34:01 2022 +0800 drm: bridge: adv7511: Add check for mipi_dsi_driver_register [ Upstream commit 831463667b5f4f1e5bce9c3b94e9e794d2bc8923 ] As mipi_dsi_driver_register could return error if fails, it should be better to check the return value and return error if fails. Moreover, if i2c_add_driver fails, mipi_dsi_driver_register should be reverted. Fixes: 1e4d58cd7f88 ("drm/bridge: adv7533: Create a MIPI DSI device") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hangyu Hua <[email protected]> Date: Wed May 18 14:58:56 2022 +0800 drm: bridge: sii8620: fix possible off-by-one [ Upstream commit 21779cc21c732c5eff8ea1624be6590450baa30f ] The next call to sii8620_burst_get_tx_buf will result in off-by-one When ctx->burst.tx_count + size == ARRAY_SIZE(ctx->burst.tx_buf). The same thing happens in sii8620_burst_get_rx_buf. This patch also change tx_count and tx_buf to rx_count and rx_buf in sii8620_burst_get_rx_buf. It is unreasonable to check tx_buf's size and use rx_buf. Fixes: e19e9c692f81 ("drm/bridge/sii8620: add support for burst eMSC transmissions") Signed-off-by: Hangyu Hua <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Puranjay Mohan <[email protected]> Date: Wed Aug 11 13:00:26 2021 +0530 dt-bindings: iio: accel: Add DT binding doc for ADXL355 [ Upstream commit bf43a71a0a7f396434f6460b46e33eb00752f78d ] Add devicetree binding document for ADXL355, a 3-Axis MEMS Accelerometer. Signed-off-by: Puranjay Mohan <[email protected]> Reviewed-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Conor Dooley <[email protected]> Date: Wed Aug 3 19:54:00 2022 +0100 dt-bindings: riscv: fix SiFive l2-cache's cache-sets commit b60cf8e59e61133b6c9514ff8d8c8d7049d040ef upstream. Fix device tree schema validation error messages for the SiFive Unmatched: ' cache-sets:0:0: 1024 was expected'. The existing bindings allow for just 1024 cache-sets but the fu740 on Unmatched the has 2048 cache-sets. The ISA itself permits any arbitrary power of two, however this is not supported by dt-schema. The RTL for the IP, to which the number of cache-sets is a tunable parameter, has been released publicly so speculatively adding a small number of "reasonable" values seems unwise also. Instead, as the binding only supports two distinct controllers: add 2048 and explicitly lock it to the fu740's l2 cache while limiting 1024 to the l2 cache on the fu540. Fixes: af951c3a113b ("dt-bindings: riscv: Update l2 cache DT documentation to add support for SiFive FU740") Reported-by: Atul Khare <[email protected]> Signed-off-by: Conor Dooley <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jul 8 16:46:38 2022 +0300 eeprom: idt_89hpesx: uninitialized data in idt_dbgfs_csr_write() [ Upstream commit 71d46f1ff2212ced4852c7e77c5176382a1bdcec ] The simple_write_to_buffer() function will return positive/success if it is able to write a single byte anywhere within the buffer. However that potentially leaves a lot of the buffer uninitialized. In this code it's better to return 0 if the offset is non-zero. This code is not written to support partial writes. And then return -EFAULT if the buffer is not completely initialized. Fixes: cfad6425382e ("eeprom: Add IDT 89HPESx EEPROM/CSR driver") Reviewed-by: Serge Semin <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/Ysg1Pu/nzSMe3r1q@kili Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Segall <[email protected]> Date: Wed Jun 15 14:24:23 2022 -0700 epoll: autoremove wakers even more aggressively commit a16ceb13961068f7209e34d7984f8e42d2c06159 upstream. If a process is killed or otherwise exits while having active network connections and many threads waiting on epoll_wait, the threads will all be woken immediately, but not removed from ep->wq. Then when network traffic scans ep->wq in wake_up, every wakeup attempt will fail, and will not remove the entries from the list. This means that the cost of the wakeup attempt is far higher than usual, does not decrease, and this also competes with the dying threads trying to actually make progress and remove themselves from the wq. Handle this by removing visited epoll wq entries unconditionally, rather than only when the wakeup succeeds - the structure of ep_poll means that the only potential loss is the timed_out->eavail heuristic, which now can race and result in a redundant ep_send_events attempt. (But only when incoming data and a timeout actually race, not on every timeout) Shakeel added: : We are seeing this issue in production with real workloads and it has : caused hard lockups. Particularly network heavy workloads with a lot : of threads in epoll_wait() can easily trigger this issue if they get : killed (oom-killed in our case). Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ben Segall <[email protected]> Tested-by: Shakeel Butt <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Eric Dumazet <[email protected]> Cc: Roman Penyaev <[email protected]> Cc: Jason Baron <[email protected]> Cc: Khazhismel Kumykov <[email protected]> Cc: Heiher <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gao Xiang <[email protected]> Date: Fri Jul 8 18:10:01 2022 +0800 erofs: avoid consecutive detection for Highmem memory [ Upstream commit 448b5a1548d87c246c3d0c3df8480d3c6eb6c11a ] Currently, vmap()s are avoided if physical addresses are consecutive for decompressed buffers. I observed that is very common for 4KiB pclusters since the numbers of decompressed pages are almost 2 or 3. However, such detection doesn't work for Highmem pages on 32-bit machines, let's fix it now. Reported-by: Liu Jinbao <[email protected]> Fixes: 7fc45dbc938a ("staging: erofs: introduce generic decompression backend") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Gao Xiang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Jul 26 13:13:50 2022 +0200 ext2: Add more validity checks for inode counts [ Upstream commit fa78f336937240d1bc598db817d638086060e7e9 ] Add checks verifying number of inodes stored in the superblock matches the number computed from number of inodes per group. Also verify we have at least one block worth of inodes per group. This prevents crashes on corrupted filesystems. Reported-by: [email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:55 2022 +0800 ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h [ Upstream commit 179b14152dcb6a24c3415200603aebca70ff13af ] When adding an xattr to an inode, we must ensure that the inode_size is not less than EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. Otherwise, the end position may be greater than the start position, resulting in UAF. Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Jan Kara <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Czerner <[email protected]> Date: Mon Jul 4 16:27:20 2022 +0200 ext4: check if directory block is within i_size [ Upstream commit 65f8ea4cd57dbd46ea13b41dc8bac03176b04233 ] Currently ext4 directory handling code implicitly assumes that the directory blocks are always within the i_size. In fact ext4_append() will attempt to allocate next directory block based solely on i_size and the i_size is then appropriately increased after a successful allocation. However, for this to work it requires i_size to be correct. If, for any reason, the directory inode i_size is corrupted in a way that the directory tree refers to a valid directory block past i_size, we could end up corrupting parts of the directory tree structure by overwriting already used directory blocks when modifying the directory. Fix it by catching the corruption early in __ext4_read_dirblock(). Addresses Red-Hat-Bugzilla: #2070205 CVE: CVE-2022-1184 Signed-off-by: Lukas Czerner <[email protected]> Cc: [email protected] Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:57 2022 +0800 ext4: correct max_inline_xattr_value_size computing [ Upstream commit c9fd167d57133c5b748d16913c4eabc55e531c73 ] If the ext4 inode does not have xattr space, 0 is returned in the get_max_inline_xattr_value_size function. Otherwise, the function returns a negative value when the inode does not contain EXT4_STATE_XATTR. Cc: [email protected] Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:58 2022 +0800 ext4: correct the misjudgment in ext4_iget_extra_inode [ Upstream commit fd7e672ea98b95b9d4c9dae316639f03c16a749d ] Use the EXT4_INODE_HAS_XATTR_SPACE macro to more accurately determine whether the inode have xattr space. Cc: [email protected] Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Whitney <[email protected]> Date: Wed Jun 15 12:05:30 2022 -0400 ext4: fix extent status tree race in writeback error recovery path [ Upstream commit 7f0d8e1d607c1a4fa9a27362a108921d82230874 ] A race can occur in the unlikely event ext4 is unable to allocate a physical cluster for a delayed allocation in a bigalloc file system during writeback. Failure to allocate a cluster forces error recovery that includes a call to mpage_release_unused_pages(). That function removes any corresponding delayed allocated blocks from the extent status tree. If a new delayed write is in progress on the same cluster simultaneously, resulting in the addition of an new extent containing one or more blocks in that cluster to the extent status tree, delayed block accounting can be thrown off if that delayed write then encounters a similar cluster allocation failure during future writeback. Write lock the i_data_sem in mpage_release_unused_pages() to fix this problem. Ext4's block/cluster accounting code for bigalloc relies on i_data_sem for mutual exclusion, as is found in the delayed write path, and the locking in mpage_release_unused_pages() is missing. Cc: [email protected] Reported-by: Ye Bin <[email protected]> Signed-off-by: Eric Whitney <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:24 2022 +0200 ext4: fix race when reusing xattr blocks [ Upstream commit 65f8b80053a1b2fd602daa6814e62d6fa90e5e9b ] When ext4_xattr_block_set() decides to remove xattr block the following race can happen: CPU1 CPU2 ext4_xattr_block_set() ext4_xattr_release_block() new_bh = ext4_xattr_block_cache_find() lock_buffer(bh); ref = le32_to_cpu(BHDR(bh)->h_refcount); if (ref == 1) { ... mb_cache_entry_delete(); unlock_buffer(bh); ext4_free_blocks(); ... ext4_forget(..., bh, ...); jbd2_journal_revoke(..., bh); ext4_journal_get_write_access(..., new_bh, ...) do_get_write_access() jbd2_journal_cancel_revoke(..., new_bh); Later the code in ext4_xattr_block_set() finds out the block got freed and cancels reusal of the block but the revoke stays canceled and so in case of block reuse and journal replay the filesystem can get corrupted. If the race works out slightly differently, we can also hit assertions in the jbd2 code. Fix the problem by making sure that once matching mbcache entry is found, code dropping the last xattr block reference (or trying to modify xattr block in place) waits until the mbcache entry reference is dropped. This way code trying to reuse xattr block is protected from someone trying to drop the last reference to xattr block. Reported-and-tested-by: Ritesh Harjani <[email protected]> CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Thu Jun 16 10:13:56 2022 +0800 ext4: fix use-after-free in ext4_xattr_set_entry [ Upstream commit 67d7d8ad99beccd9fe92d585b87f1760dc9018e3 ] Hulk Robot reported a issue: ================================================================== BUG: KASAN: use-after-free in ext4_xattr_set_entry+0x18ab/0x3500 Write of size 4105 at addr ffff8881675ef5f4 by task syz-executor.0/7092 CPU: 1 PID: 7092 Comm: syz-executor.0 Not tainted 4.19.90-dirty #17 Call Trace: [...] memcpy+0x34/0x50 mm/kasan/kasan.c:303 ext4_xattr_set_entry+0x18ab/0x3500 fs/ext4/xattr.c:1747 ext4_xattr_ibody_inline_set+0x86/0x2a0 fs/ext4/xattr.c:2205 ext4_xattr_set_handle+0x940/0x1300 fs/ext4/xattr.c:2386 ext4_xattr_set+0x1da/0x300 fs/ext4/xattr.c:2498 __vfs_setxattr+0x112/0x170 fs/xattr.c:149 __vfs_setxattr_noperm+0x11b/0x2a0 fs/xattr.c:180 __vfs_setxattr_locked+0x17b/0x250 fs/xattr.c:238 vfs_setxattr+0xed/0x270 fs/xattr.c:255 setxattr+0x235/0x330 fs/xattr.c:520 path_setxattr+0x176/0x190 fs/xattr.c:539 __do_sys_lsetxattr fs/xattr.c:561 [inline] __se_sys_lsetxattr fs/xattr.c:557 [inline] __x64_sys_lsetxattr+0xc2/0x160 fs/xattr.c:557 do_syscall_64+0xdf/0x530 arch/x86/entry/common.c:298 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x459fe9 RSP: 002b:00007fa5e54b4c08 EFLAGS: 00000246 ORIG_RAX: 00000000000000bd RAX: ffffffffffffffda RBX: 000000000051bf60 RCX: 0000000000459fe9 RDX: 00000000200003c0 RSI: 0000000020000180 RDI: 0000000020000140 RBP: 000000000051bf60 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000001009 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc73c93fc0 R14: 000000000051bf60 R15: 00007fa5e54b4d80 [...] ================================================================== Above issue may happen as follows: ------------------------------------- ext4_xattr_set ext4_xattr_set_handle ext4_xattr_ibody_find >> s->end < s->base >> no EXT4_STATE_XATTR >> xattr_check_inode is not executed ext4_xattr_ibody_set ext4_xattr_set_entry >> size_t min_offs = s->end - s->base >> UAF in memcpy we can easily reproduce this problem with the following commands: mkfs.ext4 -F /dev/sda mount -o debug_want_extra_isize=128 /dev/sda /mnt touch /mnt/file setfattr -n user.cat -v `seq -s z 4096|tr -d '[:digit:]'` /mnt/file In ext4_xattr_ibody_find, we have the following assignment logic: header = IHDR(inode, raw_inode) = raw_inode + EXT4_GOOD_OLD_INODE_SIZE + i_extra_isize is->s.base = IFIRST(header) = header + sizeof(struct ext4_xattr_ibody_header) is->s.end = raw_inode + s_inode_size In ext4_xattr_set_entry min_offs = s->end - s->base = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize - sizeof(struct ext4_xattr_ibody_header) last = s->first free = min_offs - ((void *)last - s->base) - sizeof(__u32) = s_inode_size - EXT4_GOOD_OLD_INODE_SIZE - i_extra_isize - sizeof(struct ext4_xattr_ibody_header) - sizeof(__u32) In the calculation formula, all values except s_inode_size and i_extra_size are fixed values. When i_extra_size is the maximum value s_inode_size - EXT4_GOOD_OLD_INODE_SIZE, min_offs is -4 and free is -8. The value overflows. As a result, the preceding issue is triggered when memcpy is executed. Therefore, when finding xattr or setting xattr, check whether there is space for storing xattr in the inode to resolve this issue. Cc: [email protected] Reported-by: Hulk Robot <[email protected]> Signed-off-by: Baokun Li <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ye Bin <[email protected]> Date: Fri Jun 17 09:39:35 2022 +0800 ext4: fix warning in ext4_iomap_begin as race between bmap and write [ Upstream commit 51ae846cff568c8c29921b1b28eb2dfbcd4ac12d ] We got issue as follows: ------------[ cut here ]------------ WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0 RIP: 0010:ext4_iomap_begin+0x182/0x5d0 RSP: 0018:ffff88812460fa08 EFLAGS: 00010293 RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f R10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001 R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee FS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Above issue may happen as follows: bmap write bmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on To solved above issue hold inode lock in ext4_bamp. Signed-off-by: Ye Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Czerner <[email protected]> Date: Mon Jul 4 16:27:21 2022 +0200 ext4: make sure ext4_append() always allocates new block [ Upstream commit b8a04fe77ef1360fbf73c80fddbdfeaa9407ed1b ] ext4_append() must always allocate a new block, otherwise we run the risk of overwriting existing directory block corrupting the directory tree in the process resulting in all manner of problems later on. Add a sanity check to see if the logical block is already allocated and error out if it is. Cc: [email protected] Signed-off-by: Lukas Czerner <[email protected]> Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Lingfeng <[email protected]> Date: Fri Jun 17 14:25:15 2022 +0800 ext4: recover csum seed of tmp_inode after migrating to extents [ Upstream commit 07ea7a617d6b278fb7acedb5cbe1a81ce2de7d0c ] When migrating to extents, the checksum seed of temporary inode need to be replaced by inode's, otherwise the inode checksums will be incorrect when swapping the inodes data. However, the temporary inode can not match it's checksum to itself since it has lost it's own checksum seed. mkfs.ext4 -F /dev/sdc mount /dev/sdc /mnt/sdc xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/sdc/testfile chattr -e /mnt/sdc/testfile chattr +e /mnt/sdc/testfile umount /dev/sdc fsck -fn /dev/sdc ======== ... Pass 1: Checking inodes, blocks, and sizes Inode 13 passes checks, but checksum does not match inode. Fix? no ... ======== The fix is simple, save the checksum seed of temporary inode, and recover it after migrating to extents. Fixes: e81c9302a6c3 ("ext4: set csum seed in tmp inode while migrating to extents") Signed-off-by: Li Lingfeng <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:22 2022 +0200 ext4: remove EA inode entry from mbcache on inode eviction [ Upstream commit 6bc0d63dad7f9f54d381925ee855b402f652fa39 ] Currently we remove EA inode from mbcache as soon as its xattr refcount drops to zero. However there can be pending attempts to reuse the inode and thus refcount handling code has to handle the situation when refcount increases from zero anyway. So save some work and just keep EA inode in mbcache until it is getting evicted. At that moment we are sure following iget() of EA inode will fail anyway (or wait for eviction to finish and load things from the disk again) and so removing mbcache entry at that moment is fine and simplifies the code a bit. CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:23 2022 +0200 ext4: unindent codeblock in ext4_xattr_block_set() [ Upstream commit fd48e9acdf26d0cbd80051de07d4a735d05d29b2 ] Remove unnecessary else (and thus indentation level) from a code block in ext4_xattr_block_set(). It will also make following code changes easier. No functional changes. CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Theodore Ts'o <[email protected]> Date: Wed Jun 29 00:00:25 2022 -0400 ext4: update s_overhead_clusters in the superblock during an on-line resize [ Upstream commit de394a86658ffe4e89e5328fd4993abfe41b7435 ] When doing an online resize, the on-disk superblock on-disk wasn't updated. This means that when the file system is unmounted and remounted, and the on-disk overhead value is non-zero, this would result in the results of statfs(2) to be incorrect. This was partially fixed by Commits 10b01ee92df5 ("ext4: fix overhead calculation to account for the reserved gdt blocks"), 85d825dbf489 ("ext4: force overhead calculation if the s_overhead_cluster makes no sense"), and eb7054212eac ("ext4: update the cached overhead value in the superblock"). However, since it was too expensive to forcibly recalculate the overhead for bigalloc file systems at every mount, this didn't fix the problem for bigalloc file systems. This commit should address the problem when resizing file systems with the bigalloc feature enabled. Signed-off-by: Theodore Ts'o <[email protected]> Cc: [email protected] Reviewed-by: Andreas Dilger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuqi Zhang <[email protected]> Date: Wed May 25 11:01:20 2022 +0800 ext4: use kmemdup() to replace kmalloc + memcpy [ Upstream commit 4efd9f0d120c55b08852ee5605dbb02a77089a5d ] Replace kmalloc + memcpy with kmemdup() Signed-off-by: Shuqi Zhang <[email protected]> Reviewed-by: Ritesh Harjani <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sungjong Seo <[email protected]> Date: Tue May 24 10:29:11 2022 +0900 f2fs: allow compression for mmap files in compress_mode=user [ Upstream commit 66d34fcbbe63ebd8584b792e0d741f6648100894 ] Since commit e3c548323d32 ("f2fs: let's allow compression for mmap files"), it has been allowed to compress mmap files. However, in compress_mode=user, it is not allowed yet. To keep the same concept in both compress_modes, f2fs_ioc_(de)compress_file() should also allow it. Let's remove checking mmap files in f2fs_ioc_(de)compress_file() so that the compression for mmap files is also allowed in compress_mode=user. Signed-off-by: Sungjong Seo <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jaewook Kim <[email protected]> Date: Wed Aug 3 17:53:58 2022 +0900 f2fs: do not allow to decompress files have FI_COMPRESS_RELEASED [ Upstream commit 90be48bd9d29ece3965e5e8b21499b6db166e57b ] If a file has FI_COMPRESS_RELEASED, all writes for it should not be allowed. However, as of now, in case of compress_mode=user, writes triggered by IOCTLs like F2FS_IOC_DE/COMPRESS_FILE are allowed unexpectly, which could crash that file. To fix it, let's do not allow F2FS_IOC_DE/COMPRESS_IOCTL if a file already has FI_COMPRESS_RELEASED flag. This is the reproduction process: 1. $ touch ./file 2. $ chattr +c ./file 3. $ dd if=/dev/random of=./file bs=4096 count=30 conv=notrunc 4. $ dd if=/dev/zero of=./file bs=4096 count=34 seek=30 conv=notrunc 5. $ sync 6. $ do_compress ./file ; call F2FS_IOC_COMPRESS_FILE 7. $ get_compr_blocks ./file ; call F2FS_IOC_GET_COMPRESS_BLOCKS 8. $ release ./file ; call F2FS_IOC_RELEASE_COMPRESS_BLOCKS 9. $ do_compress ./file ; call F2FS_IOC_COMPRESS_FILE again 10. $ get_compr_blocks ./file ; call F2FS_IOC_GET_COMPRESS_BLOCKS again This reproduction process is tested in 128kb cluster size. You can find compr_blocks has a negative value. Fixes: 5fdb322ff2c2b ("f2fs: add F2FS_IOC_DECOMPRESS_FILE and F2FS_IOC_COMPRESS_FILE") Signed-off-by: Junbeom Yeom <[email protected]> Signed-off-by: Sungjong Seo <[email protected]> Signed-off-by: Youngjin Gil <[email protected]> Signed-off-by: Jaewook Kim <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chao Liu <[email protected]> Date: Mon Jul 25 18:16:33 2022 +0800 f2fs: fix to remove F2FS_COMPR_FL and tag F2FS_NOCOMP_FL at the same time [ Upstream commit 8ee236dcaa690d09ca612622e8bc8d09c302021d ] If the inode has the compress flag, it will fail to use 'chattr -c +m' to remove its compress flag and tag no compress flag. However, the same command will be successful when executed again, as shown below: $ touch foo.txt $ chattr +c foo.txt $ chattr -c +m foo.txt chattr: Invalid argument while setting flags on foo.txt $ chattr -c +m foo.txt $ f2fs_io getflags foo.txt get a flag on foo.txt ret=0, flags=nocompression,inline_data Fix this by removing some checks in f2fs_setflags_common() that do not affect the original logic. I go through all the possible scenarios, and the results are as follows. Bold is the only thing that has changed. +---------------+-----------+-----------+----------+ | | file flags | + command +-----------+-----------+----------+ | | no flag | compr | nocompr | +---------------+-----------+-----------+----------+ | chattr +c | compr | compr | -EINVAL | | chattr -c | no flag | no flag | nocompr | | chattr +m | nocompr | -EINVAL | nocompr | | chattr -m | no flag | compr | no flag | | chattr +c +m | -EINVAL | -EINVAL | -EINVAL | | chattr +c -m | compr | compr | compr | | chattr -c +m | nocompr | *nocompr* | nocompr | | chattr -c -m | no flag | no flag | no flag | +---------------+-----------+-----------+----------+ Link: https://lore.kernel.org/linux-f2fs-devel/[email protected]/ Fixes: 4c8ff7095bef ("f2fs: support data compression") Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Chao Liu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Helge Deller <[email protected]> Date: Thu Jun 2 22:08:38 2022 +0200 fbcon: Fix accelerated fbdev scrolling while logo is still shown commit 3866cba87dcd0162fb41e9b3b653d0af68fad5ec upstream. There is no need to directly skip over to the SCROLL_REDRAW case while the logo is still shown. When using DRM, this change has no effect because the code will reach the SCROLL_REDRAW case immediately anyway. But if you run an accelerated fbdev driver and have FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION enabled, console scrolling is slowed down by factors so that it feels as if you use a 9600 baud terminal. So, drop those unnecessary checks and speed up fbdev console acceleration during bootup. Cc: [email protected] # v5.10+ Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/YpkYxk7wsBPx3po+@p100 Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Thu Jun 2 22:06:28 2022 +0200 fbcon: Fix boundary checks for fbcon=vc:n1-n2 parameters commit cad564ca557f8d3bb3b1fa965d9a2b3f6490ec69 upstream. The user may use the fbcon=vc:<n1>-<n2> option to tell fbcon to take over the given range (n1...n2) of consoles. The value for n1 and n2 needs to be a positive number and up to (MAX_NR_CONSOLES - 1). The given values were not fully checked against those boundaries yet. To fix the issue, convert first_fb_vc and last_fb_vc to unsigned integers and check them against the upper boundary, and make sure that first_fb_vc is smaller than last_fb_vc. Cc: [email protected] # v4.19+ Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/YpkYRMojilrtZIgM@p100 Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sudeep Holla <[email protected]> Date: Fri Jul 1 17:03:10 2022 +0100 firmware: arm_scpi: Ensure scpi_info is not assigned if the probe fails [ Upstream commit 689640efc0a2c4e07e6f88affe6d42cd40cc3f85 ] When scpi probe fails, at any point, we need to ensure that the scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated via devm_kzalloc() but freed when the probe fails. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] # 4.19+ Reported-by: huhai <[email protected]> Reviewed-by: Jackie Liu <[email protected]> Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lv Ruyi <[email protected]> Date: Tue Apr 19 01:36:48 2022 +0000 firmware: tegra: Fix error check return value of debugfs_create_file() [ Upstream commit afcdb8e55c91c6ff0700ab272fd0f74e899ab884 ] If an error occurs, debugfs_create_file() will return ERR_PTR(-ERROR), so use IS_ERR() to check it. Reported-by: Zeal Robot <[email protected]> Signed-off-by: Lv Ruyi <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Al Viro <[email protected]> Date: Sun Jun 12 19:50:29 2022 -0400 fix short copy handling in copy_mc_pipe_to_iter() commit c3497fd009ef2c59eea60d21c3ac22de3585ed7d upstream. Unlike other copying operations on ITER_PIPE, copy_mc_to_iter() can result in a short copy. In that case we need to trim the unused buffers, as well as the length of partially filled one - it's not enough to set ->head, ->iov_offset and ->count to reflect how much had we copied. Not hard to fix, fortunately... I'd put a helper (pipe_discard_from(pipe, head)) into pipe_fs_i.h, rather than iov_iter.c - it has nothing to do with iov_iter and having it will allow us to avoid an ugly kludge in fs/splice.c. We could put it into lib/iov_iter.c for now and move it later, but I don't see the point going that way... Cc: [email protected] # 4.19+ Fixes: ca146f6f091e "lib/iov_iter: Fix pipe handling in _copy_to_iter_mcsafe()" Reviewed-by: Jeff Layton <[email protected]> Reviewed-by: Christian Brauner (Microsoft) <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marco Pagani <[email protected]> Date: Thu Jun 9 16:05:19 2022 +0200 fpga: altera-pr-ip: fix unsigned comparison with less than zero [ Upstream commit 2df84a757d87fd62869fc401119d429735377ec5 ] Fix the "comparison with less than zero" warning reported by cppcheck for the unsigned (size_t) parameter count of the alt_pr_fpga_write() function. Fixes: d201cc17a8a3 ("fpga pr ip: Core driver support for Altera Partial Reconfiguration IP") Reviewed-by: Tom Rix <[email protected]> Acked-by: Xu Yilun <[email protected]> Signed-off-by: Marco Pagani <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xu Yilun <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Xu <[email protected]> Date: Thu Jul 14 14:11:26 2022 +0800 fs: Add missing umask strip in vfs_tmpfile commit ac6800e279a22b28f4fc21439843025a0d5bf03e upstream. All creation paths except for O_TMPFILE handle umask in the vfs directly if the filesystem doesn't support or enable POSIX ACLs. If the filesystem does then umask handling is deferred until posix_acl_create(). Because, O_TMPFILE misses umask handling in the vfs it will not honor umask settings. Fix this by adding the missing umask handling. Link: https://lore.kernel.org/r/[email protected] Fixes: 60545d0d4610 ("[O_TMPFILE] it's still short a few helpers, but infrastructure should be OK now...") Cc: <[email protected]> # 4.19+ Reported-by: Christian Brauner (Microsoft) <[email protected]> Reviewed-by: Darrick J. Wong <[email protected]> Reviewed-and-Tested-by: Jeff Layton <[email protected]> Acked-by: Christian Brauner (Microsoft) <[email protected]> Signed-off-by: Yang Xu <[email protected]> Signed-off-by: Christian Brauner (Microsoft) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Wed Jun 29 15:06:58 2022 +0200 fs: check FMODE_LSEEK to control internal pipe splicing [ Upstream commit 97ef77c52b789ec1411d360ed99dca1efe4b2c81 ] The original direct splicing mechanism from Jens required the input to be a regular file because it was avoiding the special socket case. It also recognized blkdevs as being close enough to a regular file. But it forgot about chardevs, which behave the same way and work fine here. This is an okayish heuristic, but it doesn't totally work. For example, a few chardevs should be spliceable here. And a few regular files shouldn't. This patch fixes this by instead checking whether FMODE_LSEEK is set, which represents decently enough what we need rewinding for when splicing to internal pipes. Fixes: b92ce5589374 ("[PATCH] splice: add direct fd <-> fd splicing support") Cc: Jens Axboe <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Tue Jul 26 10:18:51 2022 -0400 ftrace/x86: Add back ftrace_expected assignment commit ac6c1b2ca77e722a1e5d651f12f437f2f237e658 upstream. When a ftrace_bug happens (where ftrace fails to modify a location) it is helpful to have what was at that location as well as what was expected to be there. But with the conversion to text_poke() the variable that assigns the expected for debugging was dropped. Unfortunately, I noticed this when I needed it. Add it back. Link: https://lkml.kernel.org/r/[email protected] Cc: "[email protected]" <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Andrew Morton <[email protected]> Cc: [email protected] Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miklos Szeredi <[email protected]> Date: Thu Jul 21 16:06:18 2022 +0200 fuse: ioctl: translate ENOSYS commit 02c0cab8e7345b06f1c0838df444e2902e4138d3 upstream. Overlayfs may fail to complete updates when a filesystem lacks fileattr/xattr syscall support and responds with an ENOSYS error code, resulting in an unexpected "Function not implemented" error. This bug may occur with FUSE filesystems, such as davfs2. Steps to reproduce: # install davfs2, e.g., apk add davfs2 mkdir /test mkdir /test/lower /test/upper /test/work /test/mnt yes '' | mount -t davfs -o ro http://some-web-dav-server/path \ /test/lower mount -t overlay -o upperdir=/test/upper,lowerdir=/test/lower \ -o workdir=/test/work overlay /test/mnt # when "some-file" exists in the lowerdir, this fails with "Function # not implemented", with dmesg showing "overlayfs: failed to retrieve # lower fileattr (/some-file, err=-38)" touch /test/mnt/some-file The underlying cause of this regresion is actually in FUSE, which fails to translate the ENOSYS error code returned by userspace filesystem (which means that the ioctl operation is not supported) to ENOTTY. Reported-by: Christian Kohlschütter <[email protected]> Fixes: 72db82115d2b ("ovl: copy up sync/noatime fileattr flags") Fixes: 59efec7b9039 ("fuse: implement ioctl support") Cc: <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miklos Szeredi <[email protected]> Date: Thu Jul 21 16:06:18 2022 +0200 fuse: limit nsec commit 47912eaa061a6a81e4aa790591a1874c650733c0 upstream. Limit nanoseconds to 0..999999999. Fixes: d8a5ba45457e ("[PATCH] FUSE - core") Cc: <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xie Yongji <[email protected]> Date: Mon Jul 18 16:50:12 2022 +0800 fuse: Remove the control interface for virtio-fs [ Upstream commit c64797809a64c73497082aa05e401a062ec1af34 ] The commit 15c8e72e88e0 ("fuse: allow skipping control interface and forced unmount") tries to remove the control interface for virtio-fs since it does not support aborting requests which are being processed. But it doesn't work now. This patch fixes it by skipping creating the control interface if fuse_conn->no_control is set. Fixes: 15c8e72e88e0 ("fuse: allow skipping control interface and forced unmount") Signed-off-by: Xie Yongji <[email protected]> Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Tue Aug 2 15:13:22 2022 -0300 genelf: Use HAVE_LIBCRYPTO_SUPPORT, not the never defined HAVE_LIBCRYPTO [ Upstream commit 91cea6be90e436c55cde8770a15e4dac9d3032d0 ] When genelf was introduced it tested for HAVE_LIBCRYPTO not HAVE_LIBCRYPTO_SUPPORT, which is the define the feature test for openssl defines, fix it. This also adds disables the deprecation warning, someone has to fix this to build with openssl 3.0 before the warning becomes a hard error. Fixes: 9b07e27f88b9cd78 ("perf inject: Add jitdump mmap injection support") Reported-by: è°æ¢“ç…Š <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Daniel Borkmann <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: John Fastabend <[email protected]> Cc: KP Singh <[email protected]> Cc: Martin KaFai Lau <[email protected]> Cc: Nick Terrell <[email protected]> Cc: Song Liu <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antonio Borneo <[email protected]> Date: Thu May 12 18:05:44 2022 +0200 genirq: Don't return error on missing optional irq_request_resources() [ Upstream commit 95001b756467ecc9f5973eb5e74e97699d9bbdf1 ] Function irq_chip::irq_request_resources() is reported as optional in the declaration of struct irq_chip. If the parent irq_chip does not implement it, we should ignore it and return. Don't return error if the functions is missing. Signed-off-by: Antonio Borneo <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Samuel Holland <[email protected]> Date: Fri Jul 1 15:00:50 2022 -0500 genirq: GENERIC_IRQ_IPI depends on SMP [ Upstream commit 0f5209fee90b4544c58b4278d944425292789967 ] The generic IPI code depends on the IRQ affinity mask being allocated and initialized. This will not be the case if SMP is disabled. Fix up the remaining driver that selected GENERIC_IRQ_IPI in a non-SMP config. Reported-by: kernel test robot <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Mon Jul 11 20:52:38 2022 +0800 gpio: gpiolib-of: Fix refcount bugs in of_mm_gpiochip_add_data() [ Upstream commit 5d07a692f9562f9c06e62cce369e9dd108173a0f ] We should use of_node_get() when a new reference of device_node is created. It is noted that the old reference stored in 'mm_gc->gc.of_node' should also be decreased. This patch is based on the fact that there is a call site in function 'qe_add_gpiochips()' of src file 'drivers\soc\fsl\qe\gpio.c'. In this function, of_mm_gpiochip_add_data() is contained in an iteration of for_each_compatible_node() which will automatically increase and decrease the refcount. So we need additional of_node_get() for the reference escape in of_mm_gpiochip_add_data(). Fixes: a19e3da5bc5f ("of/gpio: Kill of_gpio_chip and add members directly to gpio_chip") Signed-off-by: Liang He <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Artem Borisov <[email protected]> Date: Tue Jul 19 17:53:24 2022 +0300 HID: alps: Declare U1_UNICORN_LEGACY support [ Upstream commit 1117d182c5d72abd7eb8b7d5e7b8c3373181c3ab ] U1_UNICORN_LEGACY id was added to the driver, but was not declared in the device id table, making it impossible to use. Fixes: 640e403 ("HID: alps: Add AUI1657 device ID") Signed-off-by: Artem Borisov <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Basavaraj Natikar <[email protected]> Date: Tue Jul 12 23:48:26 2022 +0530 HID: amd_sfh: Add NULL check for hid device [ Upstream commit 06aa2a43c307cf4096f422dcb575e5d2913e528f ] On removal of hid device during SFH set report may cause NULL pointer exception. Hence add NULL check for hid device before accessing. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Basavaraj Natikar <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu May 12 13:18:48 2022 -0500 HID: amd_sfh: Don't show client init failed as error when discovery fails [ Upstream commit e51d8d3ea3d773334d2c047c8d1623dba66f592a ] When sensor discovery fails, this means that the system doesn't have any sensors connected and a user should only be notified at most one time. A message is already displayed at WARN level of "failed to discover, sensors not enabled". It's pointless to show that the client init failed at ERR level for the same condition. Check the return code and don't display this message in those conditions. Fixes: b5d7f43e97da ("HID: amd_sfh: Add support for sensor discovery") Reported-by: David Chang <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Acked-by: Basavaraj Natikar <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Basavaraj Natikar <[email protected]> Date: Sat Jul 23 11:40:33 2022 +0530 HID: amd_sfh: Handle condition of "no sensors" [ Upstream commit 5d4d0f15657535f6a122ab26d47230b5c2b944af ] Add a check for num_hid_devices to handle special case the situation of "no sensors". Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Signed-off-by: Basavaraj Natikar <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Harshit Mogalapalli <[email protected]> Date: Wed Jun 8 05:26:09 2022 -0700 HID: cp2112: prevent a buffer overflow in cp2112_xfer() [ Upstream commit 381583845d19cb4bd21c8193449385f3fefa9caf ] Smatch warnings: drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'data->block[1]' too small (33 vs 255) drivers/hid/hid-cp2112.c:793 cp2112_xfer() error: __memcpy() 'buf' too small (64 vs 255) The 'read_length' variable is provided by 'data->block[0]' which comes from user and it(read_length) can take a value between 0-255. Add an upper bound to 'read_length' variable to prevent a buffer overflow in memcpy(). Fixes: 542134c0375b ("HID: cp2112: Fix I2C_BLOCK_DATA transactions") Signed-off-by: Harshit Mogalapalli <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maximilian Luz <[email protected]> Date: Thu May 26 01:08:27 2022 +0200 HID: hid-input: add Surface Go battery quirk commit db925d809011c37b246434fdce71209fc2e6c0c2 upstream. Similar to the Surface Go (1), the (Elantech) touchscreen/digitizer in the Surface Go 2 mistakenly reports the battery of the stylus. Instead of over the touchscreen device, battery information is provided via bluetooth and the touchscreen device reports an empty battery. Apply the HID_BATTERY_QUIRK_IGNORE quirk to ignore this battery and prevent the erroneous low battery warnings. Cc: [email protected] Signed-off-by: Maximilian Luz <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Harshit Mogalapalli <[email protected]> Date: Mon Jun 20 09:28:24 2022 -0700 HID: mcp2221: prevent a buffer overflow in mcp_smbus_write() [ Upstream commit 62ac2473553a00229e67bdf3cb023b62cf7f5a9a ] Smatch Warning: drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() '&mcp->txbuf[5]' too small (59 vs 255) drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf' too small (34 vs 255) The 'len' variable can take a value between 0-255 as it can come from data->block[0] and it is user data. So add an bound check to prevent a buffer overflow in memcpy(). Fixes: 67a95c21463d ("HID: mcp2221: add usb to i2c-smbus host bridge") Signed-off-by: Harshit Mogalapalli <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ping Cheng <[email protected]> Date: Fri May 13 14:52:37 2022 -0700 HID: wacom: Don't register pad_input for touch switch commit d6b675687a4ab4dba684716d97c8c6f81bf10905 upstream. Touch switch state is received through WACOM_PAD_FIELD. However, it is reported by touch_input. Don't register pad_input if no other pad events require the interface. Cc: [email protected] Signed-off-by: Ping Cheng <[email protected]> Reviewed-by: Jason Gerecke <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ping Cheng <[email protected]> Date: Fri May 13 14:51:56 2022 -0700 HID: wacom: Only report rotation for art pen commit 7ccced33a0ba39b0103ae1dfbf7f1dffdc0a1bc2 upstream. The generic routine, wacom_wac_pen_event, turns rotation value 90 degree anti-clockwise before posting the events. This non-zero event trggers a non-zero ABS_Z event for non art pen tools. However, HID_DG_TWIST is only supported by art pen. [[email protected]: fix build: add missing brace] Cc: [email protected] Signed-off-by: Ping Cheng <[email protected]> Reviewed-by: Jason Gerecke <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sun Jun 26 18:27:45 2022 +0200 hinic: Use the bitmap API when applicable [ Upstream commit 7c2c57263af41cfd8b5022274e6801542831bb69 ] 'vlan_bitmap' is a bitmap and is used as such. So allocate it with devm_bitmap_zalloc() and its explicit bit size (i.e. VLAN_N_VID). This avoids the need of the VLAN_BITMAP_SIZE macro which: - needlessly has a 'nic_dev' parameter - should be "long" (and not byte) aligned, so that the bitmap semantic is respected This is in fact not an issue because VLAN_N_VID is 4096 at the time being, but devm_bitmap_zalloc() is less verbose and easier to understand. Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/6ff7b7d21414240794a77dc2456914412718a145.1656260842.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Armin Wolf <[email protected]> Date: Sun Jun 12 06:18:06 2022 +0200 hwmon: (dell-smm) Add Dell XPS 13 7390 to fan control whitelist [ Upstream commit 385e5f57053ff293282fea84c1c27186d53f66e1 ] A user reported that the program dell-bios-fan-control worked on his Dell XPS 13 7390 to switch off automatic fan control. Since it uses the same mechanism as the dell_smm_hwmon module, add this model to the fan control whitelist. Compile-tested only. Signed-off-by: Armin Wolf <[email protected]> Acked-by: Pali Rohár <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linus Walleij <[email protected]> Date: Tue Jul 12 23:46:24 2022 +0200 hwmon: (drivetemp) Add module alias [ Upstream commit 5918036cfa8ded7aa8094db70295011ce2275447 ] Adding a MODULE_ALIAS() to drivetemp will make the driver easier for modprobe to autoprobe. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 5b46903d8bf3 ("hwmon: Driver for disk and solid state drives with temperature sensors") Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 25 21:43:44 2022 +0200 hwmon: (sht15) Fix wrong assumptions in device remove callback [ Upstream commit 7d4edccc9bbfe1dcdff641343f7b0c6763fbe774 ] Taking a lock at the beginning of .remove() doesn't prevent new readers. With the existing approach it can happen, that a read occurs just when the lock was taken blocking the reader until the lock is released at the end of the remove callback which then accessed *data that is already freed then. To actually fix this problem the hwmon core needs some adaption. Until this is implemented take the optimistic approach of assuming that all readers are gone after hwmon_device_unregister() and sysfs_remove_group() as most other drivers do. (And once the core implements that, taking the lock would deadlock.) So drop the lock, move the reset to after device unregistration to keep the device in a workable state until it's deregistered. Also add a error message in case the reset fails and return 0 anyhow. (Returning an error code, doesn't stop the platform device unregistration and only results in a little helpful error message before the devm cleanup handlers are called.) Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lars-Peter Clausen <[email protected]> Date: Sun Jul 17 16:52:44 2022 +0200 i2c: cadence: Support PEC for SMBus block read [ Upstream commit 9fdf6d97f03035ad5298e2d1635036c74c2090ed ] SMBus packet error checking (PEC) is implemented by appending one additional byte of checksum data at the end of the message. This provides additional protection and allows to detect data corruption on the I2C bus. SMBus block reads support variable length reads. The first byte in the read message is the number of available data bytes. The combination of PEC and block read is currently not supported by the Cadence I2C driver. * When PEC is enabled the maximum transfer length for block reads increases from 33 to 34 bytes. * The I2C core smbus emulation layer relies on the driver updating the `i2c_msg` `len` field with the number of received bytes. The updated length is used when checking the PEC. Add support to the Cadence I2C driver for handling SMBus block reads with PEC. To determine the maximum transfer length uses the initial `len` value of the `i2c_msg`. When PEC is enabled this will be 2, when it is disabled it will be 1. Once a read transfer is done also increment the `len` field by the amount of received data bytes. This change has been tested with a UCM90320 PMBus power monitor, which requires block reads to access certain data fields, but also has PEC enabled by default. Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: Lars-Peter Clausen <[email protected]> Tested-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Wang <[email protected]> Date: Fri Dec 27 09:34:32 2019 +0000 i2c: Fix a potential use after free [ Upstream commit e4c72c06c367758a14f227c847f9d623f1994ecf ] Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. Fixes: 611e12ea0f12 ("i2c: core: manage i2c bus device refcount in i2c_[get|put]_adapter") Signed-off-by: Xu Wang <[email protected]> [wsa: added comment to the code, added Fixes tag] Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Fri Jul 22 09:24:01 2022 +0800 i2c: mux-gpmux: Add of_node_put() when breaking out of loop [ Upstream commit 6435319c34704994e19b0767f6a4e6f37439867b ] In i2c_mux_probe(), we should call of_node_put() when breaking out of for_each_child_of_node() which will automatically increase and decrease the refcount. Fixes: ac8498f0ce53 ("i2c: i2c-mux-gpmux: new driver") Signed-off-by: Liang He <[email protected]> Acked-by: Peter Rosin <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabio Estevam <[email protected]> Date: Wed May 25 22:09:14 2022 -0300 i2c: mxs: Silence a clang warning [ Upstream commit 3d43273d7d1e1a5374d531e901d3c537b4c97bbf ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: drivers/i2c/busses/i2c-mxs.c:802:18: warning: cast to smaller integer type 'enum mxs_i2c_devtype' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: c32abd8b5691 ("i2c: mxs: Remove unneeded platform_device_id") Signed-off-by: Fabio Estevam <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tali Perry <[email protected]> Date: Wed May 25 11:23:39 2022 +0800 i2c: npcm: Correct slave role behavior [ Upstream commit d7aa1b149b8fc04d802879cf4662010aa4a42deb ] Correct the slave transaction logic to be compatible with the generic slave backend driver. Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") Signed-off-by: Tali Perry <[email protected]> Signed-off-by: Tyrone Ting <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tali Perry <[email protected]> Date: Wed May 25 11:23:38 2022 +0800 i2c: npcm: Remove own slave addresses 2:10 [ Upstream commit 47d506d1a28fd10a9fb1f33df5622d88fae72095 ] NPCM can support up to 10 own slave addresses. In practice, only one address is actually being used. In order to access addresses 2 and above, need to switch register banks. The switch needs spinlock. To avoid using spinlock for this useless feature removed support of SA >= 2. Also fix returned slave event enum. Remove some comment since the bank selection is not required. The bank selection is not required since the supported slave addresses are reduced. Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") Signed-off-by: Tali Perry <[email protected]> Signed-off-by: Tyrone Ting <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Fri Jun 24 14:13:05 2022 +0200 ia64, processor: fix -Wincompatible-pointer-types in ia64_get_irr() commit e5a16a5c4602c119262f350274021f90465f479d upstream. test_bit(), as any other bitmap op, takes `unsigned long *` as a second argument (pointer to the actual bitmap), as any bitmap itself is an array of unsigned longs. However, the ia64_get_irr() code passes a ref to `u64` as a second argument. This works with the ia64 bitops implementation due to that they have `void *` as the second argument and then cast it later on. This works with the bitmap API itself due to that `unsigned long` has the same size on ia64 as `u64` (`unsigned long long`), but from the compiler PoV those two are different. Define @irr as `unsigned long` to fix that. That implies no functional changes. Has been hidden for 16 years! Fixes: a58786917ce2 ("[IA64] avoid broken SAL_CACHE_FLUSH implementations") Cc: [email protected] # 2.6.16+ Reported-by: kernel test robot <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Yury Norov <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Przemyslaw Patynowski <[email protected]> Date: Wed Jun 15 15:36:29 2022 +0200 iavf: Fix 'tc qdisc show' listing too many queues [ Upstream commit 93cb804edab1b9a5bb7bb7b6824012dbb20abf22 ] Fix tc qdisc show dev <ethX> root displaying too many fq_codel qdiscs. tc_modify_qdisc, which is caller of ndo_setup_tc, expects driver to call netif_set_real_num_tx_queues, which prepares qdiscs. Without this patch, fq_codel qdiscs would not be adjusted to number of queues on VF. e.g.: tc qdisc show dev <ethX> qdisc mq 0: root qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 tc qdisc add dev <ethX> root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 queues 1@0 1@1 hw 1 mode channel shaper bw_rlimit max_rate 5000Mbit 150Mbit tc qdisc show dev <ethX> qdisc mqprio 8003: root tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues:(0:0) (1:1) mode:channel shaper:bw_rlimit max_rate:5Gbit 150Mbit qdisc fq_codel 0: parent 8003:4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent 8003:3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent 8003:2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent 8003:1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 While after fix: tc qdisc add dev <ethX> root mqprio num_tc 2 map 1 0 0 0 0 0 0 0 queues 1@0 1@1 hw 1 mode channel shaper bw_rlimit max_rate 5000Mbit 150Mbit tc qdisc show dev <ethX> #should show 2, shows 4 qdisc mqprio 8004: root tc 2 map 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 queues:(0:0) (1:1) mode:channel shaper:bw_rlimit max_rate:5Gbit 150Mbit qdisc fq_codel 0: parent 8004:2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 qdisc fq_codel 0: parent 8004:1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf") Signed-off-by: Przemyslaw Patynowski <[email protected]> Co-developed-by: Grzegorz Szczurek <[email protected]> Signed-off-by: Grzegorz Szczurek <[email protected]> Co-developed-by: Kiran Patil <[email protected]> Signed-off-by: Kiran Patil <[email protected]> Signed-off-by: Jedrzej Jagielski <[email protected]> Tested-by: Bharathi Sreenivas <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Przemyslaw Patynowski <[email protected]> Date: Mon Jun 13 18:41:23 2022 -0400 iavf: Fix max_rate limiting [ Upstream commit ec60d54cb9a3d43a02c5612a03093c18233e6601 ] Fix max_rate option in TC, check for proper quanta boundaries. Check for minimum value provided and if it fits expected 50Mbps quanta. Without this patch, iavf could send settings for max_rate limiting that would be accepted from by PF even the max_rate option is less than expected 50Mbps quanta. It results in no rate limiting on traffic as rate limiting will be floored to 0. Example: tc qdisc add dev $vf root mqprio num_tc 3 map 0 2 1 queues \ 2@0 2@2 2@4 hw 1 mode channel shaper bw_rlimit \ max_rate 50Mbps 500Mbps 500Mbps Should limit TC0 to circa 50 Mbps tc qdisc add dev $vf root mqprio num_tc 3 map 0 2 1 queues \ 2@0 2@2 2@4 hw 1 mode channel shaper bw_rlimit \ max_rate 0Mbps 100Kbit 500Mbps Should return error Fixes: d5b33d024496 ("i40evf: add ndo_setup_tc callback to i40evf") Signed-off-by: Przemyslaw Patynowski <[email protected]> Signed-off-by: Jun Zhang <[email protected]> Tested-by: Bharathi Sreenivas <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mordechay Goodstein <[email protected]> Date: Mon Feb 14 17:29:52 2022 +0100 ieee80211: add EHT 1K aggregation definitions [ Upstream commit 2a2c86f15e17c5013b9897b67d895e64a25ae3cb ] We add the fields for parsing extended ADDBA request/respond, and new max 1K aggregation for limit ADDBA request/respond. Adjust drivers to use the proper macro, IEEE80211_MAX_AMPDU_BUF -> IEEE80211_MAX_AMPDU_BUF_HE. Signed-off-by: Mordechay Goodstein <[email protected]> Link: https://lore.kernel.org/r/20220214173004.b8b447ce95b7.I0ee2554c94e89abc7a752b0f7cc7fd79c273efea@changeid Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jagath Jog J <[email protected]> Date: Thu May 5 19:00:12 2022 +0530 iio: accel: bma400: Fix the scale min and max macro values [ Upstream commit 747c7cf1592e226d40543231b26502b332d0ea2f ] Changing the scale macro values to match the bma400 sensitivity for 1 LSB of all the available ranges. Fixes: 465c811f1f20 ("iio: accel: Add driver for the BMA400") Signed-off-by: Jagath Jog J <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jagath Jog J <[email protected]> Date: Thu May 5 19:00:13 2022 +0530 iio: accel: bma400: Reordering of header files [ Upstream commit 1bd2dc6ea863690aee5c45ebf09c9194c7a42c0d ] Reordering of header files and removing the iio/sysfs.h since custom attributes are not being used in the driver. Signed-off-by: Jagath Jog J <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gwendal Grignou <[email protected]> Date: Mon Jul 11 07:47:16 2022 -0700 iio: cros: Register FIFO callback after sensor is registered [ Upstream commit 0b4ae3f6d1210c11f9baf159009c7227eacf90f2 ] Instead of registering callback to process sensor events right at initialization time, wait for the sensor to be register in the iio subsystem. Events can come at probe time (in case the kernel rebooted abruptly without switching the sensor off for instance), and be sent to IIO core before the sensor is fully registered. Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Reported-by: Douglas Anderson <[email protected]> Signed-off-by: Gwendal Grignou <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fawzi Khaber <[email protected]> Date: Mon Jul 18 15:07:06 2022 +0200 iio: fix iio_format_avail_range() printing for none IIO_VAL_INT commit 5e1f91850365de55ca74945866c002fda8f00331 upstream. iio_format_avail_range() should print range as follow [min, step, max], so the function was previously calling iio_format_list() with length = 3, length variable refers to the array size of values not the number of elements. In case of non IIO_VAL_INT values each element has integer part and decimal part. With length = 3 this would cause premature end of loop and result in printing only one element. Signed-off-by: Fawzi Khaber <[email protected]> Signed-off-by: Jean-Baptiste Maneyrol <[email protected]> Fixes: eda20ba1e25e ("iio: core: Consolidate iio_format_avail_{list,range}()") Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Sun Jul 17 08:42:41 2022 +0800 iio: light: isl29028: Fix the warning in isl29028_remove() commit 06674fc7c003b9d0aa1d37fef7ab2c24802cc6ad upstream. The driver use the non-managed form of the register function in isl29028_remove(). To keep the release order as mirroring the ordering in probe, the driver should use non-managed form in probe, too. The following log reveals it: [ 32.374955] isl29028 0-0010: remove [ 32.376861] general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI [ 32.377676] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.379432] RIP: 0010:kernfs_find_and_get_ns+0x28/0xe0 [ 32.385461] Call Trace: [ 32.385807] sysfs_unmerge_group+0x59/0x110 [ 32.386110] dpm_sysfs_remove+0x58/0xc0 [ 32.386391] device_del+0x296/0xe50 [ 32.386959] cdev_device_del+0x1d/0xd0 [ 32.387231] devm_iio_device_unreg+0x27/0xb0 [ 32.387542] devres_release_group+0x319/0x3d0 [ 32.388162] i2c_device_remove+0x93/0x1f0 Fixes: 2db5054ac28d ("staging: iio: isl29028: add runtime power management support") Signed-off-by: Zheyu Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Thu May 12 09:56:01 2022 -0700 inet: add READ_ONCE(sk->sk_bound_dev_if) in INET_MATCH() [ Upstream commit 4915d50e300e96929d2462041d6f6c6f061167fd ] INET_MATCH() runs without holding a lock on the socket. We probably need to annotate most reads. This patch makes INET_MATCH() an inline function to ease our changes. v2: We remove the 32bit version of it, as modern compilers should generate the same code really, no need to try to be smarter. Also make 'struct net *net' the first argument. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xie Shaowen <[email protected]> Date: Tue Aug 2 15:20:33 2022 +0800 Input: gscps2 - check return value of ioremap() in gscps2_probe() commit e61b3125a4f036b3c6b87ffd656fc1ab00440ae9 upstream. The function ioremap() in gscps2_probe() can fail, so its return value should be checked. Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache") Cc: <[email protected]> # v5.6+ Reported-by: Hacash Robot <[email protected]> Signed-off-by: Xie Shaowen <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Tue Jul 5 11:26:32 2022 +0300 intel_th: Fix a resource leak in an error handling path [ Upstream commit 086c28ab7c5699256aced0049aae9c42f1410313 ] If an error occurs after calling 'pci_alloc_irq_vectors()', 'pci_free_irq_vectors()' must be called as already done in the remove function. Fixes: 7b7036d47c35 ("intel_th: pci: Use MSI interrupt signalling") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Tue Jul 5 11:26:33 2022 +0300 intel_th: msu-sink: Potential dereference of null pointer [ Upstream commit 82f76a4a720791d889de775b5f7541d601efc8bd ] The return value of dma_alloc_coherent() needs to be checked. To avoid use of null pointer in sg_set_buf() in case of the failure of alloc. Fixes: f220df66f676 ("intel_th: msu-sink: An example msu buffer "sink"") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Jiasheng Jiang <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:34 2022 +0300 intel_th: msu: Fix vmalloced buffers [ Upstream commit ac12ad3ccf6d386e64a9d6a890595a2509d24edd ] After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's a chance of DMA buffer getting allocated via vmalloc(), which messes up the mmapping code: > RIP: msc_mmap_fault [intel_th_msu] > Call Trace: > <TASK> > __do_fault > do_fault ... Fix this by accounting for vmalloc possibility. Fixes: ba39bd830605 ("intel_th: msu: Switch over to scatterlist") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:35 2022 +0300 intel_th: pci: Add Meteor Lake-P support [ Upstream commit 802a9a0b1d91274ef10d9fe429b4cc1e8c200aef ] Add support for the Trace Hub in Meteor Lake-P. Reviewed-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:37 2022 +0300 intel_th: pci: Add Raptor Lake-S CPU support [ Upstream commit ff46a601afc5a66a81c3945b83d0a2caeb88e8bc ] Add support for the Trace Hub in Raptor Lake-S CPU. Reviewed-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Shishkin <[email protected]> Date: Tue Jul 5 11:26:36 2022 +0300 intel_th: pci: Add Raptor Lake-S PCH support [ Upstream commit 23e2de5826e2fc4dd43e08bab3a2ea1a5338b063 ] Add support for the Trace Hub in Raptor Lake-S PCH. Reviewed-by: Andy Shevchenko <[email protected]> Cc: stable <[email protected]> Signed-off-by: Alexander Shishkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Sun Jul 3 17:11:26 2022 +0800 interconnect: imx: fix max_node_id [ Upstream commit bd734481e172b4827af09c9ab06c51d2ab7201e6 ] max_node_id not equal to the ARRAY_SIZE of node array, need increase 1, otherwise xlate will fail for the last entry. And rename max_node_id to num_nodes to reflect the reality. Fixes: f0d8048525d7d ("interconnect: Add imx core driver") Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Thu Aug 4 15:13:46 2022 +0100 io_uring: mem-account pbuf buckets commit cc18cc5e82033d406f54144ad6f8092206004684 upstream. Potentially, someone may create as many pbuf bucket as there are indexes in an xarray without any other restrictions bounding our memory usage, put memory needed for the buckets under memory accounting. Cc: <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/d34c452e45793e978d26e2606211ec9070d329ea.1659622312.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liang He <[email protected]> Date: Tue Jul 19 20:49:55 2022 +0800 iommu/arm-smmu: qcom_iommu: Add of_node_put() when breaking out of loop [ Upstream commit a91eb6803c1c715738682fece095145cbd68fe0b ] In qcom_iommu_has_secure_context(), we should call of_node_put() for the reference 'child' when breaking out of for_each_child_of_node() which will automatically increase and decrease the refcount. Fixes: d051f28c8807 ("iommu/qcom: Initialize secure page table") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sam Protsenko <[email protected]> Date: Thu Jul 14 19:55:46 2022 +0300 iommu/exynos: Handle failed IOMMU device registration properly [ Upstream commit fce398d2d02c0a9a2bedf7c7201b123e153e8963 ] If iommu_device_register() fails in exynos_sysmmu_probe(), the previous calls have to be cleaned up. In this case, the iommu_device_sysfs_add() should be cleaned up, by calling its remove counterpart call. Fixes: d2c302b6e8b1 ("iommu/exynos: Make use of iommu_device_register interface") Signed-off-by: Sam Protsenko <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Acked-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Tue Jul 12 17:38:36 2022 +0200 iommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE) [ Upstream commit b0b0b77ea611e3088e9523e60860f4f41b62b235 ] KASAN reports: [ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) [ 4.676149][ T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0 [ 4.683454][ T0] [ 4.685638][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1 [ 4.694331][ T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016 [ 4.703196][ T0] Call Trace: [ 4.706334][ T0] <TASK> [ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497) after converting the type of the first argument (@nr, bit number) of arch_test_bit() from `long` to `unsigned long`[0]. Under certain conditions (for example, when ACPI NUMA is disabled via command line), pxm_to_node() can return %NUMA_NO_NODE (-1). It is valid 'magic' number of NUMA node, but not valid bit number to use in bitops. node_online() eventually descends to test_bit() without checking for the input, assuming it's on caller side (which might be good for perf-critical tasks). There, -1 becomes %ULONG_MAX which leads to an insane array index when calculating bit position in memory. For now, add an explicit check for @node being not %NUMA_NO_NODE before calling test_bit(). The actual logics didn't change here at all. [0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d Fixes: ee34b32d8c29 ("dmar: support for parsing Remapping Hardware Static Affinity structure") Cc: [email protected] # 2.6.33+ Reported-by: kernel test robot <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Lu Baolu <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri May 13 11:55:49 2022 -0700 ipv6: add READ_ONCE(sk->sk_bound_dev_if) in INET6_MATCH() [ Upstream commit 5d368f03280d3678433a7f119efe15dfbbb87bc8 ] INET6_MATCH() runs without holding a lock on the socket. We probably need to annotate most reads. This patch makes INET6_MATCH() an inline function to ease our changes. v2: inline function only defined if IS_ENABLED(CONFIG_IPV6) Change the name to inet6_match(), this is no longer a macro. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: William Dean <[email protected]> Date: Sat Jul 23 18:01:28 2022 +0800 irqchip/mips-gic: Check the return value of ioremap() in gic_of_init() [ Upstream commit 71349cc85e5930dce78ed87084dee098eba24b59 ] The function ioremap() in gic_of_init() can fail, so its return value should be checked. Reported-by: Hacash Robot <[email protected]> Signed-off-by: William Dean <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Samuel Holland <[email protected]> Date: Fri Jul 1 15:00:49 2022 -0500 irqchip/mips-gic: Only register IPI domain when SMP is enabled [ Upstream commit 8190cc572981f2f13b6ffc26c7cfa7899e5d3ccc ] The MIPS GIC irqchip driver may be selected in a uniprocessor configuration, but it unconditionally registers an IPI domain. Limit the part of the driver dealing with IPIs to only be compiled when GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration. Reported-by: kernel test robot <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Qiang <[email protected]> Date: Tue Jul 19 06:36:40 2022 +0000 irqdomain: Report irq number for NOMAP domains [ Upstream commit 6f194c99f466147148cc08452718b46664112548 ] When using a NOMAP domain, __irq_resolve_mapping() doesn't store the Linux IRQ number at the address optionally provided by the caller. While this isn't a huge deal (the returned value is guaranteed to the hwirq that was passed as a parameter), let's honour the letter of the API by writing the expected value. Fixes: d22558dd0a6c (“irqdomain: Introduce irq_resolve_mapping()â€) Signed-off-by: Xu Qiang <[email protected]> [maz: commit message] Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Zhihao Cheng <[email protected]> Date: Fri Jul 15 20:51:52 2022 +0800 jbd2: fix assertion 'jh->b_frozen_data == NULL' failure when journal aborted [ Upstream commit 4a734f0869f970b8a9b65062ea40b09a5da9dba8 ] Following process will fail assertion 'jh->b_frozen_data == NULL' in jbd2_journal_dirty_metadata(): jbd2_journal_commit_transaction unlink(dir/a) jh->b_transaction = trans1 jh->b_jlist = BJ_Metadata journal->j_running_transaction = NULL trans1->t_state = T_COMMIT unlink(dir/b) handle->h_trans = trans2 do_get_write_access jh->b_modified = 0 jh->b_frozen_data = frozen_buffer jh->b_next_transaction = trans2 jbd2_journal_dirty_metadata is_handle_aborted is_journal_aborted // return false --> jbd2 abort <-- while (commit_transaction->t_buffers) if (is_journal_aborted) jbd2_journal_refile_buffer __jbd2_journal_refile_buffer WRITE_ONCE(jh->b_transaction, jh->b_next_transaction) WRITE_ONCE(jh->b_next_transaction, NULL) __jbd2_journal_file_buffer(jh, BJ_Reserved) J_ASSERT_JH(jh, jh->b_frozen_data == NULL) // assertion failure ! The reproducer (See detail in [Link]) reports: ------------[ cut here ]------------ kernel BUG at fs/jbd2/transaction.c:1629! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 584 Comm: unlink Tainted: G W 5.19.0-rc6-00115-g4a57a8400075-dirty #697 RIP: 0010:jbd2_journal_dirty_metadata+0x3c5/0x470 RSP: 0018:ffffc90000be7ce0 EFLAGS: 00010202 Call Trace: <TASK> __ext4_handle_dirty_metadata+0xa0/0x290 ext4_handle_dirty_dirblock+0x10c/0x1d0 ext4_delete_entry+0x104/0x200 __ext4_unlink+0x22b/0x360 ext4_unlink+0x275/0x390 vfs_unlink+0x20b/0x4c0 do_unlinkat+0x42f/0x4c0 __x64_sys_unlink+0x37/0x50 do_syscall_64+0x35/0x80 After journal aborting, __jbd2_journal_refile_buffer() is executed with holding @jh->b_state_lock, we can fix it by moving 'is_handle_aborted()' into the area protected by @jh->b_state_lock. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216251 Fixes: 470decc613ab20 ("[PATCH] jbd2: initial copy of files from jbd") Signed-off-by: Zhihao Cheng <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhang Yi <[email protected]> Date: Sat Jun 11 21:04:26 2022 +0800 jbd2: fix outstanding credits assert in jbd2_journal_commit_transaction() [ Upstream commit a89573ce4ad32f19f43ec669771726817e185be0 ] We catch an assert problem in jbd2_journal_commit_transaction() when doing fsstress and request falut injection tests. The problem is happened in a race condition between jbd2_journal_commit_transaction() and ext4_end_io_end(). Firstly, ext4_writepages() writeback dirty pages and start reserved handle, and then the journal was aborted due to some previous metadata IO error, jbd2_journal_abort() start to commit current running transaction, the committing procedure could be raced by ext4_end_io_end() and lead to subtract j_reserved_credits twice from commit_transaction->t_outstanding_credits, finally the t_outstanding_credits is mistakenly smaller than t_nr_buffers and trigger assert. kjournald2 kworker jbd2_journal_commit_transaction() write_unlock(&journal->j_state_lock); atomic_sub(j_reserved_credits, t_outstanding_credits); //sub once jbd2_journal_start_reserved() start_this_handle() //detect aborted journal jbd2_journal_free_reserved() //get running transaction read_lock(&journal->j_state_lock) __jbd2_journal_unreserve_handle() atomic_sub(j_reserved_credits, t_outstanding_credits); //sub again read_unlock(&journal->j_state_lock); journal->j_running_transaction = NULL; J_ASSERT(t_nr_buffers <= t_outstanding_credits) //bomb!!! Fix this issue by using journal->j_state_lock to protect the subtraction in jbd2_journal_commit_transaction(). Fixes: 96f1e0974575 ("jbd2: avoid long hold times of j_state_lock while committing a transaction") Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Wed Jun 8 14:40:24 2022 -0700 kasan: test: Silence GCC 12 warnings [ Upstream commit aaf50b1969d7933a51ea421b11432a7fb90974e3 ] GCC 12 continues to get smarter about array accesses. The KASAN tests are expecting to explicitly test out-of-bounds conditions at run-time, so hide the variable from GCC, to avoid warnings like: ../lib/test_kasan.c: In function 'ksize_uaf': ../lib/test_kasan.c:790:61: warning: array subscript 120 is outside array bounds of 'void[120]' [-Warray-bounds] 790 | KUNIT_EXPECT_KASAN_FAIL(test, ((volatile char *)ptr)[size]); | ~~~~~~~~~~~~~~~~~~~~~~^~~~~~ ../lib/test_kasan.c:97:9: note: in definition of macro 'KUNIT_EXPECT_KASAN_FAIL' 97 | expression; \ | ^~~~~~~~~~ Cc: Andrey Ryabinin <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Michal Suchanek <[email protected]> Date: Thu Jul 14 21:40:27 2022 +0800 kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification [ Upstream commit 0828c4a39be57768b8788e8cbd0d84683ea757e5 ] commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype") adds support for KEXEC_SIG verification with keys from platform keyring but the built-in keys and secondary keyring are not used. Add support for the built-in keys and secondary keyring as x86 does. Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype") Cc: [email protected] Cc: Philipp Rudo <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Michal Suchanek <[email protected]> Reviewed-by: "Lee, Chun-Yi" <[email protected]> Acked-by: Baoquan He <[email protected]> Signed-off-by: Coiby Xu <[email protected]> Acked-by: Heiko Carstens <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tianjia Zhang <[email protected]> Date: Tue Jun 28 11:37:20 2022 +0800 KEYS: asymmetric: enforce SM2 signature use pkey algo [ Upstream commit 0815291a8fd66cdcf7db1445d4d99b0d16065829 ] The signature verification of SM2 needs to add the Za value and recalculate sig->digest, which requires the detection of the pkey_algo in public_key_verify_signature(). As Eric Biggers said, the pkey_algo field in sig is attacker-controlled and should be use pkey->pkey_algo instead of sig->pkey_algo, and secondly, if sig->pkey_algo is NULL, it will also cause signature verification failure. The software_key_determine_akcipher() already forces the algorithms are matched, so the SM3 algorithm is enforced in the SM2 signature, although this has been checked, we still avoid using any algorithm information in the signature as input. Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Reported-by: Eric Biggers <[email protected]> Cc: [email protected] # v5.10+ Signed-off-by: Tianjia Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jun 24 08:30:04 2022 +0300 kfifo: fix kfifo_to_user() return type [ Upstream commit 045ed31e23aea840648c290dbde04797064960db ] The kfifo_to_user() macro is supposed to return zero for success or negative error codes. Unfortunately, there is a signedness bug so it returns unsigned int. This only affects callers which try to save the result in ssize_t and as far as I can see the only place which does that is line6_hwdep_read(). TL;DR: s/_uint/_int/. Link: https://lkml.kernel.org/r/YrVL3OJVLlNhIMFs@kili Fixes: 144ecf310eb5 ("kfifo: fix kfifo_alloc() to return a signed int value") Signed-off-by: Dan Carpenter <[email protected]> Cc: Stefani Seibold <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Zhongjin <[email protected]> Date: Mon Aug 1 11:37:19 2022 +0800 kprobes: Forbid probing on trampoline and BPF code areas [ Upstream commit 28f6c37a2910f565b4f5960df52b2eccae28c891 ] kernel_text_address() treats ftrace_trampoline, kprobe_insn_slot and bpf_text_address as valid kprobe addresses - which is not ideal. These text areas are removable and changeable without any notification to kprobes, and probing on them can trigger unexpected behavior: https://lkml.org/lkml/2022/7/26/1148 Considering that jump_label and static_call text are already forbiden to probe, kernel_text_address() should be replaced with core_kernel_text() and is_module_text_address() to check other text areas which are unsafe to kprobe. [ mingo: Rewrote the changelog. ] Fixes: 5b485629ba0d ("kprobes, extable: Identify kprobes trampolines as kernel text area") Fixes: 74451e66d516 ("bpf: make jited programs visible in traces") Signed-off-by: Chen Zhongjin <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Masami Hiramatsu (Google) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Thu Jul 28 21:56:19 2022 +0900 ksmbd: fix memory leak in smb2_handle_negotiate commit aa7253c2393f6dcd6a1468b0792f6da76edad917 upstream. The allocated memory didn't free under an error path in smb2_handle_negotiate(). Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] Reported-by: [email protected] # ZDI-CAN-17815 Signed-off-by: Namjae Jeon <[email protected]> Reviewed-by: Hyunchul Lee <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Thu Jul 28 21:57:08 2022 +0900 ksmbd: fix use-after-free bug in smb2_tree_disconect commit cf6531d98190fa2cf92a6d8bbc8af0a4740a223c upstream. smb2_tree_disconnect() freed the struct ksmbd_tree_connect, but it left the dangling pointer. It can be accessed again under compound requests. This bug can lead an oops looking something link: [ 1685.468014 ] BUG: KASAN: use-after-free in ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd] [ 1685.468068 ] Read of size 4 at addr ffff888102172180 by task kworker/1:2/4807 ... [ 1685.468130 ] Call Trace: [ 1685.468132 ] <TASK> [ 1685.468135 ] dump_stack_lvl+0x49/0x5f [ 1685.468141 ] print_report.cold+0x5e/0x5cf [ 1685.468145 ] ? ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd] [ 1685.468157 ] kasan_report+0xaa/0x120 [ 1685.468194 ] ? ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd] [ 1685.468206 ] __asan_report_load4_noabort+0x14/0x20 [ 1685.468210 ] ksmbd_tree_conn_disconnect+0x131/0x160 [ksmbd] [ 1685.468222 ] smb2_tree_disconnect+0x175/0x250 [ksmbd] [ 1685.468235 ] handle_ksmbd_work+0x30e/0x1020 [ksmbd] [ 1685.468247 ] process_one_work+0x778/0x11c0 [ 1685.468251 ] ? _raw_spin_lock_irq+0x8e/0xe0 [ 1685.468289 ] worker_thread+0x544/0x1180 [ 1685.468293 ] ? __cpuidle_text_end+0x4/0x4 [ 1685.468297 ] kthread+0x282/0x320 [ 1685.468301 ] ? process_one_work+0x11c0/0x11c0 [ 1685.468305 ] ? kthread_complete_and_exit+0x30/0x30 [ 1685.468309 ] ret_from_fork+0x1f/0x30 Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] Reported-by: [email protected] # ZDI-CAN-17816 Signed-off-by: Namjae Jeon <[email protected]> Reviewed-by: Hyunchul Lee <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hyunchul Lee <[email protected]> Date: Thu Jul 28 21:58:53 2022 +0900 ksmbd: prevent out of bound read for SMB2_TREE_CONNNECT commit 824d4f64c20093275f72fc8101394d75ff6a249e upstream. if Status is not 0 and PathLength is long, smb_strndup_from_utf16 could make out of bound read in smb2_tree_connnect. This bug can lead an oops looking something like: [ 1553.882047] BUG: KASAN: slab-out-of-bounds in smb_strndup_from_utf16+0x469/0x4c0 [ksmbd] [ 1553.882064] Read of size 2 at addr ffff88802c4eda04 by task kworker/0:2/42805 ... [ 1553.882095] Call Trace: [ 1553.882098] <TASK> [ 1553.882101] dump_stack_lvl+0x49/0x5f [ 1553.882107] print_report.cold+0x5e/0x5cf [ 1553.882112] ? smb_strndup_from_utf16+0x469/0x4c0 [ksmbd] [ 1553.882122] kasan_report+0xaa/0x120 [ 1553.882128] ? smb_strndup_from_utf16+0x469/0x4c0 [ksmbd] [ 1553.882139] __asan_report_load_n_noabort+0xf/0x20 [ 1553.882143] smb_strndup_from_utf16+0x469/0x4c0 [ksmbd] [ 1553.882155] ? smb_strtoUTF16+0x3b0/0x3b0 [ksmbd] [ 1553.882166] ? __kmalloc_node+0x185/0x430 [ 1553.882171] smb2_tree_connect+0x140/0xab0 [ksmbd] [ 1553.882185] handle_ksmbd_work+0x30e/0x1020 [ksmbd] [ 1553.882197] process_one_work+0x778/0x11c0 [ 1553.882201] ? _raw_spin_lock_irq+0x8e/0xe0 [ 1553.882206] worker_thread+0x544/0x1180 [ 1553.882209] ? __cpuidle_text_end+0x4/0x4 [ 1553.882214] kthread+0x282/0x320 [ 1553.882218] ? process_one_work+0x11c0/0x11c0 [ 1553.882221] ? kthread_complete_and_exit+0x30/0x30 [ 1553.882225] ret_from_fork+0x1f/0x30 [ 1553.882231] </TASK> There is no need to check error request validation in server. This check allow invalid requests not to validate message. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: [email protected] Reported-by: [email protected] # ZDI-CAN-17818 Signed-off-by: Hyunchul Lee <[email protected]> Acked-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quentin Perret <[email protected]> Date: Tue Jul 5 14:23:10 2022 +0000 KVM: arm64: Don't return from void function [ Upstream commit 1c3ace2b8b3995d3213c5e2d2aca01a0577a3b0f ] Although harmless, the return statement in kvm_unexpected_el2_exception is rather confusing as the function itself has a void return type. The C standard is also pretty clear that "A return statement with an expression shall not appear in a function whose return type is void". Given that this return statement does not seem to add any actual value, let's not pointlessly violate the standard. Build-tested with GCC 10 and CLANG 13 for good measure, the disassembled code is identical with or without the return statement. Fixes: e9ee186bb735 ("KVM: arm64: Add kvm_extable for vaxorcism code") Signed-off-by: Quentin Perret <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Apr 29 01:04:09 2022 +0000 KVM: Don't set Accessed/Dirty bits for ZERO_PAGE [ Upstream commit a1040b0d42acf69bb4f6dbdc54c2dcd78eea1de5 ] Don't set Accessed/Dirty bits for a struct page with PG_reserved set, i.e. don't set A/D bits for the ZERO_PAGE. The ZERO_PAGE (or pages depending on the architecture) should obviously never be written, and similarly there's no point in marking it accessed as the page will never be swapped out or reclaimed. The comment in page-flags.h is quite clear that PG_reserved pages should be managed only by their owner, and strictly following that mandate also simplifies KVM's logic. Fixes: 7df003c85218 ("KVM: fix overflow of zero page refcount with ksm running") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 7 21:35:51 2022 +0000 KVM: nVMX: Account for KVM reserved CR4 bits in consistency checks commit ca58f3aa53d165afe4ab74c755bc2f6d168617ac upstream. Check that the guest (L2) and host (L1) CR4 values that would be loaded by nested VM-Enter and VM-Exit respectively are valid with respect to KVM's (L0 host) allowed CR4 bits. Failure to check KVM reserved bits would allow L1 to load an illegal CR4 (or trigger hardware VM-Fail or failed VM-Entry) by massaging guest CPUID to allow features that are not supported by KVM. Amusingly, KVM itself is an accomplice in its doom, as KVM adjusts L1's MSR_IA32_VMX_CR4_FIXED1 to allow L1 to enable bits for L2 based on L1's CPUID model. Note, although nested_{guest,host}_cr4_valid() are _currently_ used if and only if the vCPU is post-VMXON (nested.vmxon == true), that may not be true in the future, e.g. emulating VMXON has a bug where it doesn't check the allowed/required CR0/CR4 bits. Cc: [email protected] Fixes: 3899152ccbf4 ("KVM: nVMX: fix checks on CR{0,4} during virtual VMX operation") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vitaly Kuznetsov <[email protected]> Date: Tue Jul 12 15:50:09 2022 +0200 KVM: nVMX: Always enable TSC scaling for L2 when it was enabled for L1 commit 156b9d76e8822f2956c15029acf2d4b171502f3a upstream. Windows 10/11 guests with Hyper-V role (WSL2) enabled are observed to hang upon boot or shortly after when a non-default TSC frequency was set for L1. The issue is observed on a host where TSC scaling is supported. The problem appears to be that Windows doesn't use TSC scaling for its guests, even when the feature is advertised, and KVM filters SECONDARY_EXEC_TSC_SCALING out when creating L2 controls from L1's VMCS. This leads to L2 running with the default frequency (matching host's) while L1 is running with an altered one. Keep SECONDARY_EXEC_TSC_SCALING in secondary exec controls for L2 when it was set for L1. TSC_MULTIPLIER is already correctly computed and written by prepare_vmcs02(). Signed-off-by: Vitaly Kuznetsov <[email protected]> Fixes: d041b5ea93352b ("KVM: nVMX: Enable nested TSC scaling") Cc: [email protected] Reviewed-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Jul 22 22:44:08 2022 +0000 KVM: nVMX: Attempt to load PERF_GLOBAL_CTRL on nVMX xfer iff it exists [ Upstream commit 4496a6f9b45e8cd83343ad86a3984d614e22cf54 ] Attempt to load PERF_GLOBAL_CTRL during nested VM-Enter/VM-Exit if and only if the MSR exists (according to the guest vCPU model). KVM has very misguided handling of VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL and attempts to force the nVMX MSR settings to match the vPMU model, i.e. to hide/expose the control based on whether or not the MSR exists from the guest's perspective. KVM's modifications fail to handle the scenario where the vPMU is hidden from the guest _after_ being exposed to the guest, e.g. by userspace doing multiple KVM_SET_CPUID2 calls, which is allowed if done before any KVM_RUN. nested_vmx_pmu_refresh() is called if and only if there's a recognized vPMU, i.e. KVM will leave the bits in the allow state and then ultimately reject the MSR load and WARN. KVM should not force the VMX MSRs in the first place. KVM taking control of the MSRs was a misguided attempt at mimicking what commit 5f76f6f5ff96 ("KVM: nVMX: Do not expose MPX VMX controls when guest MPX disabled", 2018-10-01) did for MPX. However, the MPX commit was a workaround for another KVM bug and not something that should be imitated (and it should never been done in the first place). In other words, KVM's ABI _should_ be that userspace has full control over the MSRs, at which point triggering the WARN that loading the MSR must not fail is trivial. The intent of the WARN is still valid; KVM has consistency checks to ensure that vmcs12->{guest,host}_ia32_perf_global_ctrl is valid. The problem is that '0' must be considered a valid value at all times, and so the simple/obvious solution is to just not actually load the MSR when it does not exist. It is userspace's responsibility to provide a sane vCPU model, i.e. KVM is well within its ABI and Intel's VMX architecture to skip the loads if the MSR does not exist. Fixes: 03a8871add95 ("KVM: nVMX: Expose load IA32_PERF_GLOBAL_CTRL VM-{Entry,Exit} control") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 7 21:35:52 2022 +0000 KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4 commit c7d855c2aff2d511fd60ee2e356134c4fb394799 upstream. Inject a #UD if L1 attempts VMXON with a CR0 or CR4 that is disallowed per the associated nested VMX MSRs' fixed0/1 settings. KVM cannot rely on hardware to perform the checks, even for the few checks that have higher priority than VM-Exit, as (a) KVM may have forced CR0/CR4 bits in hardware while running the guest, (b) there may incompatible CR0/CR4 bits that have lower priority than VM-Exit, e.g. CR0.NE, and (c) userspace may have further restricted the allowed CR0/CR4 values by manipulating the guest's nested VMX MSRs. Note, despite a very strong desire to throw shade at Jim, commit 70f3aac964ae ("kvm: nVMX: Remove superfluous VMX instruction fault checks") is not to blame for the buggy behavior (though the comment...). That commit only removed the CR0.PE, EFLAGS.VM, and COMPATIBILITY mode checks (though it did erroneously drop the CPL check, but that has already been remedied). KVM may force CR0.PE=1, but will do so only when also forcing EFLAGS.VM=1 to emulate Real Mode, i.e. hardware will still #UD. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216033 Fixes: ec378aeef9df ("KVM: nVMX: Implement VMXON and VMXOFF") Reported-by: Eric Li <[email protected]> Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 7 21:35:54 2022 +0000 KVM: nVMX: Let userspace set nVMX MSR to any _host_ supported value commit f8ae08f9789ad59d318ea75b570caa454aceda81 upstream. Restrict the nVMX MSRs based on KVM's config, not based on the guest's current config. Using the guest's config to audit the new config prevents userspace from restoring the original config (KVM's config) if at any point in the past the guest's config was restricted in any way. Fixes: 62cc6b9dc61e ("KVM: nVMX: support restore of VMX capability MSRs") Cc: [email protected] Cc: David Matlack <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 7 21:36:00 2022 +0000 KVM: nVMX: Set UMIP bit CR4_FIXED1 MSR when emulating UMIP [ Upstream commit a910b5ab6b250a88fff1866bf708642d83317466 ] Make UMIP an "allowed-1" bit CR4_FIXED1 MSR when KVM is emulating UMIP. KVM emulates UMIP for both L1 and L2, and so should enumerate that L2 is allowed to have CR4.UMIP=1. Not setting the bit doesn't immediately break nVMX, as KVM does set/clear the bit in CR4_FIXED1 in response to a guest CPUID update, i.e. KVM will correctly (dis)allow nested VM-Entry based on whether or not UMIP is exposed to L1. That said, KVM should enumerate the bit as being allowed from time zero, e.g. userspace will see the wrong value if the MSR is read before CPUID is written. Fixes: 0367f205a3b7 ("KVM: vmx: add support for emulating UMIP") Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 14 21:58:27 2022 +0000 KVM: nVMX: Snapshot pre-VM-Enter BNDCFGS for !nested_run_pending case commit fa578398a0ba2c079fa1170da21fa5baae0cedb2 upstream. If a nested run isn't pending, snapshot vmcs01.GUEST_BNDCFGS irrespective of whether or not VM_ENTRY_LOAD_BNDCFGS is set in vmcs12. When restoring nested state, e.g. after migration, without a nested run pending, prepare_vmcs02() will propagate nested.vmcs01_guest_bndcfgs to vmcs02, i.e. will load garbage/zeros into vmcs02.GUEST_BNDCFGS. If userspace restores nested state before MSRs, then loading garbage is a non-issue as loading BNDCFGS will also update vmcs02. But if usersepace restores MSRs first, then KVM is responsible for propagating L2's value, which is actually thrown into vmcs01, into vmcs02. Restoring L2 MSRs into vmcs01, i.e. loading all MSRs before nested state is all kinds of bizarre and ideally would not be supported. Sadly, some VMMs do exactly that and rely on KVM to make things work. Note, there's still a lurking SMM bug, as propagating vmcs01.GUEST_BNDFGS to vmcs02 across RSM may corrupt L2's BNDCFGS. But KVM's entire VMX+SMM emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor. Link: https://lore.kernel.org/all/[email protected] Fixes: 62cf9bd8118c ("KVM: nVMX: Fix emulation of VM_ENTRY_LOAD_BNDCFGS") Cc: [email protected] Cc: Lei Wang <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 14 21:58:28 2022 +0000 KVM: nVMX: Snapshot pre-VM-Enter DEBUGCTL for !nested_run_pending case commit 764643a6be07445308e492a528197044c801b3ba upstream. If a nested run isn't pending, snapshot vmcs01.GUEST_IA32_DEBUGCTL irrespective of whether or not VM_ENTRY_LOAD_DEBUG_CONTROLS is set in vmcs12. When restoring nested state, e.g. after migration, without a nested run pending, prepare_vmcs02() will propagate nested.vmcs01_debugctl to vmcs02, i.e. will load garbage/zeros into vmcs02.GUEST_IA32_DEBUGCTL. If userspace restores nested state before MSRs, then loading garbage is a non-issue as loading DEBUGCTL will also update vmcs02. But if usersepace restores MSRs first, then KVM is responsible for propagating L2's value, which is actually thrown into vmcs01, into vmcs02. Restoring L2 MSRs into vmcs01, i.e. loading all MSRs before nested state is all kinds of bizarre and ideally would not be supported. Sadly, some VMMs do exactly that and rely on KVM to make things work. Note, there's still a lurking SMM bug, as propagating vmcs01's DEBUGCTL to vmcs02 across RSM may corrupt L2's DEBUGCTL. But KVM's entire VMX+SMM emulation is flawed as SMI+RSM should not toouch _any_ VMCS when use the "default treatment of SMIs", i.e. when not using an SMI Transfer Monitor. Link: https://lore.kernel.org/all/[email protected] Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nico Boehr <[email protected]> Date: Mon Jul 18 15:04:34 2022 +0200 KVM: s390: pv: don't present the ecall interrupt twice commit c3f0e5fd2d33d80c5a5a8b5e5d2bab2841709cc8 upstream. When the SIGP interpretation facility is present and a VCPU sends an ecall to another VCPU in enabled wait, the sending VCPU receives a 56 intercept (partial execution), so KVM can wake up the receiving CPU. Note that the SIGP interpretation facility will take care of the interrupt delivery and KVM's only job is to wake the receiving VCPU. For PV, the sending VCPU will receive a 108 intercept (pv notify) and should continue like in the non-PV case, i.e. wake the receiving VCPU. For PV and non-PV guests the interrupt delivery will occur through the SIGP interpretation facility on SIE entry when SIE finds the X bit in the status field set. However, in handle_pv_notification(), there was no special handling for SIGP, which leads to interrupt injection being requested by KVM for the next SIE entry. This results in the interrupt being delivered twice: once by the SIGP interpretation facility and once by KVM through the IICTL. Add the necessary special handling in handle_pv_notification(), similar to handle_partial_execution(), which simply wakes the receiving VCPU and leave interrupt delivery to the SIGP interpretation facility. In contrast to external calls, emergency calls are not interpreted but also cause a 108 intercept, which is why we still need to call handle_instruction() for SIGP orders other than ecall. Since kvm_s390_handle_sigp_pei() is now called for all SIGP orders which cause a 108 intercept - even if they are actually handled by handle_instruction() - move the tracepoint in kvm_s390_handle_sigp_pei() to avoid possibly confusing trace messages. Signed-off-by: Nico Boehr <[email protected]> Cc: <[email protected]> # 5.7 Fixes: da24a0cc58ed ("KVM: s390: protvirt: Instruction emulation") Reviewed-by: Claudio Imbrenda <[email protected]> Reviewed-by: Janosch Frank <[email protected]> Reviewed-by: Christian Borntraeger <[email protected]> Link: https://lore.kernel.org/r/[email protected] Message-Id: <[email protected]> Signed-off-by: Claudio Imbrenda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudio Imbrenda <[email protected]> Date: Tue Jun 28 15:56:02 2022 +0200 KVM: s390: pv: leak the topmost page table when destroy fails [ Upstream commit faa2f72cb3569256480c5540d242c84e99965160 ] Each secure guest must have a unique ASCE (address space control element); we must avoid that new guests use the same page for their ASCE, to avoid errors. Since the ASCE mostly consists of the address of the topmost page table (plus some flags), we must not return that memory to the pool unless the ASCE is no longer in use. Only a successful Destroy Secure Configuration UVC will make the ASCE reusable again. If the Destroy Configuration UVC fails, the ASCE cannot be reused for a secure guest (either for the ASCE or for other memory areas). To avoid a collision, it must not be used again. This is a permanent error and the page becomes in practice unusable, so we set it aside and leak it. On failure we already leak other memory that belongs to the ultravisor (i.e. the variable and base storage for a guest) and not leaking the topmost page table was an oversight. This error (and thus the leakage) should not happen unless the hardware is broken or KVM has some unknown serious bug. Signed-off-by: Claudio Imbrenda <[email protected]> Fixes: 29b40f105ec8d55 ("KVM: s390: protvirt: Add initial vm and cpu lifecycle handling") Reviewed-by: Janosch Frank <[email protected]> Link: https://lore.kernel.org/r/[email protected] Message-Id: <[email protected]> Signed-off-by: Janosch Frank <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lev Kujawski <[email protected]> Date: Sat May 21 08:15:11 2022 +0000 KVM: set_msr_mce: Permit guests to ignore single-bit ECC errors [ Upstream commit 0471a7bd1bca2a47a5f378f2222c5cf39ce94152 ] Certain guest operating systems (e.g., UNIXWARE) clear bit 0 of MC1_CTL to ignore single-bit ECC data errors. Single-bit ECC data errors are always correctable and thus are safe to ignore because they are informational in nature rather than signaling a loss of data integrity. Prior to this patch, these guests would crash upon writing MC1_CTL, with resultant error messages like the following: error: kvm run failed Operation not permitted EAX=fffffffe EBX=fffffffe ECX=00000404 EDX=ffffffff ESI=ffffffff EDI=00000001 EBP=fffdaba4 ESP=fffdab20 EIP=c01333a5 EFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0108 00000000 ffffffff 00c09300 DPL=0 DS [-WA] CS =0100 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA] SS =0108 00000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0108 00000000 ffffffff 00c09300 DPL=0 DS [-WA] FS =0000 00000000 ffffffff 00c00000 GS =0000 00000000 ffffffff 00c00000 LDT=0118 c1026390 00000047 00008200 DPL=0 LDT TR =0110 ffff5af0 00000067 00008b00 DPL=0 TSS32-busy GDT= ffff5020 000002cf IDT= ffff52f0 000007ff CR0=8001003b CR2=00000000 CR3=0100a000 CR4=00000230 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 EFER=0000000000000000 Code=08 89 01 89 51 04 c3 8b 4c 24 08 8b 01 8b 51 04 8b 4c 24 04 <0f> 30 c3 f7 05 a4 6d ff ff 10 00 00 00 74 03 0f 31 c3 33 c0 33 d2 c3 8d 74 26 00 0f 31 c3 Signed-off-by: Lev Kujawski <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej S. Szmigiero <[email protected]> Date: Mon May 2 00:07:26 2022 +0200 KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0 commit f17c31c48e5cde9895a491d91c424eeeada3e134 upstream. Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVM_SET_VCPU_EVENTS (even if having at least a WARN there would be correct for KVM internally generated injections). kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smm_test Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svm_inject_irq+0xab/0xb0 [kvm_amd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> inject_pending_event+0x2f7/0x4c0 [kvm] kvm_arch_vcpu_ioctl_run+0x791/0x17a0 [kvm] kvm_vcpu_ioctl+0x26d/0x650 [kvm] __x64_sys_ioctl+0x82/0xb0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> Fixes: 219b65dcf6c0 ("KVM: SVM: Improve nested interrupt injection") Cc: [email protected] Co-developed-by: Sean Christopherson <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Maciej S. Szmigiero <[email protected]> Message-Id: <35426af6e123cbe91ec7ce5132ce72521f02b1b5.1651440202.git.maciej.szmigiero@oracle.com> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon May 2 00:07:28 2022 +0200 KVM: SVM: Stuff next_rip on emulated INT3 injection if NRIPS is supported [ Upstream commit 3741aec4c38fa4123ab08ae552f05366d4fd05d8 ] If NRIPS is supported in hardware but disabled in KVM, set next_rip to the next RIP when advancing RIP as part of emulating INT3 injection. There is no flag to tell the CPU that KVM isn't using next_rip, and so leaving next_rip is left as is will result in the CPU pushing garbage onto the stack when vectoring the injected event. Reviewed-by: Maxim Levitsky <[email protected]> Fixes: 66b7138f9136 ("KVM: SVM: Emulate nRIP feature when reinjecting INT3") Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Maciej S. Szmigiero <[email protected]> Message-Id: <cd328309a3b88604daa2359ad56f36cb565ce2d4.1651440202.git.maciej.szmigiero@oracle.com> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon May 2 00:07:27 2022 +0200 KVM: SVM: Unwind "speculative" RIP advancement if INTn injection "fails" [ Upstream commit cd9e6da8048c5b40315ee2d929b6230ce1252c3c ] Unwind the RIP advancement done by svm_queue_exception() when injecting an INT3 ultimately "fails" due to the CPU encountering a VM-Exit while vectoring the injected event, even if the exception reported by the CPU isn't the same event that was injected. If vectoring INT3 encounters an exception, e.g. #NP, and vectoring the #NP encounters an intercepted exception, e.g. #PF when KVM is using shadow paging, then the #NP will be reported as the event that was in-progress. Note, this is still imperfect, as it will get a false positive if the INT3 is cleanly injected, no VM-Exit occurs before the IRET from the INT3 handler in the guest, the instruction following the INT3 generates an exception (directly or indirectly), _and_ vectoring that exception encounters an exception that is intercepted by KVM. The false positives could theoretically be solved by further analyzing the vectoring event, e.g. by comparing the error code against the expected error code were an exception to occur when vectoring the original injected exception, but SVM without NRIPS is a complete disaster, trying to make it 100% correct is a waste of time. Reviewed-by: Maxim Levitsky <[email protected]> Fixes: 66b7138f9136 ("KVM: SVM: Emulate nRIP feature when reinjecting INT3") Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Maciej S. Szmigiero <[email protected]> Message-Id: <450133cf0a026cb9825a2ff55d02cb136a1cb111.1651440202.git.maciej.szmigiero@oracle.com> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Jul 22 22:44:07 2022 +0000 KVM: VMX: Add helper to check if the guest PMU has PERF_GLOBAL_CTRL [ Upstream commit b663f0b5f3d665c261256d1f76e98f077c6e56af ] Add a helper to check of the guest PMU has PERF_GLOBAL_CTRL, which is unintuitive _and_ diverges from Intel's architecturally defined behavior. Even worse, KVM currently implements the check using two different (but equivalent) checks, _and_ there has been at least one attempt to add a _third_ flavor. Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Jul 22 22:44:06 2022 +0000 KVM: VMX: Mark all PERF_GLOBAL_(OVF)_CTRL bits reserved if there's no vPMU [ Upstream commit 93255bf92939d948bc86d81c6bb70bb0fecc5db1 ] Mark all MSR_CORE_PERF_GLOBAL_CTRL and MSR_CORE_PERF_GLOBAL_OVF_CTRL bits as reserved if there is no guest vPMU. The nVMX VM-Entry consistency checks do not check for a valid vPMU prior to consuming the masks via kvm_valid_perf_global_ctrl(), i.e. may incorrectly allow a non-zero mask to be loaded via VM-Enter or VM-Exit (well, attempted to be loaded, the actual MSR load will be rejected by intel_is_valid_msr()). Fixes: f5132b01386b ("KVM: Expose a version 2 architectural PMU to a guests") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Like Xu <[email protected]> Date: Mon May 9 18:22:02 2022 +0800 KVM: x86/pmu: Ignore pmu->global_ctrl check if vPMU doesn't support global_ctrl [ Upstream commit 98defd2e17803263f49548fea930cfc974d505aa ] MSR_CORE_PERF_GLOBAL_CTRL is introduced as part of Architecture PMU V2, as indicated by Intel SDM 19.2.2 and the intel_is_valid_msr() function. So in the absence of global_ctrl support, all PMCs are enabled as AMD does. Signed-off-by: Like Xu <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Like Xu <[email protected]> Date: Mon Apr 11 18:19:34 2022 +0800 KVM: x86/pmu: Introduce the ctrl_mask value for fixed counter [ Upstream commit 2c985527dd8d283e786ad7a67e532ef7f6f00fac ] The mask value of fixed counter control register should be dynamic adjusted with the number of fixed counters. This patch introduces a variable that includes the reserved bits of fixed counter control registers. This is a generic code refactoring. Co-developed-by: Luwei Kang <[email protected]> Signed-off-by: Luwei Kang <[email protected]> Signed-off-by: Like Xu <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paolo Bonzini <[email protected]> Date: Thu Aug 4 15:28:32 2022 +0200 KVM: x86: do not report preemption if the steal time cache is stale commit c3c28d24d910a746b02f496d190e0e8c6560224b upstream. Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status", 2021-11-11) open coded the previous call to kvm_map_gfn, but in doing so it dropped the comparison between the cached guest physical address and the one in the MSR. This cause an incorrect cache hit if the guest modifies the steal time address while the memslots remain the same. This can happen with kexec, in which case the preempted bit is written at the address used by the old kernel instead of the old one. Cc: David Woodhouse <[email protected]> Cc: [email protected] Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status") Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon Jul 11 23:27:48 2022 +0000 KVM: x86: Mark TSS busy during LTR emulation _after_ all fault checks commit ec6e4d863258d4bfb36d48d5e3ef68140234d688 upstream. Wait to mark the TSS as busy during LTR emulation until after all fault checks for the LTR have passed. Specifically, don't mark the TSS busy if the new TSS base is non-canonical. Opportunistically drop the one-off !seg_desc.PRESENT check for TR as the only reason for the early check was to avoid marking a !PRESENT TSS as busy, i.e. the common !PRESENT is now done before setting the busy bit. Fixes: e37a75a13cda ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR") Reported-by: [email protected] Cc: [email protected] Cc: Tetsuo Handa <[email protected]> Cc: Hou Wenlong <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Reviewed-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Paolo Bonzini <[email protected]> Date: Thu Aug 4 15:28:32 2022 +0200 KVM: x86: revalidate steal time cache if MSR value changes commit 901d3765fa804ce42812f1d5b1f3de2dfbb26723 upstream. Commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status", 2021-11-11) open coded the previous call to kvm_map_gfn, but in doing so it dropped the comparison between the cached guest physical address and the one in the MSR. This cause an incorrect cache hit if the guest modifies the steal time address while the memslots remain the same. This can happen with kexec, in which case the steal time data is written at the address used by the old kernel instead of the old one. While at it, rename the variable from gfn to gpa since it is a plain physical address and not a right-shifted one. Reported-by: Dave Young <[email protected]> Reported-by: Xiaoying Yan <[email protected]> Analyzed-by: Dr. David Alan Gilbert <[email protected]> Cc: David Woodhouse <[email protected]> Cc: [email protected] Fixes: 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time / preempted status") Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Mon Jul 11 23:27:49 2022 +0000 KVM: x86: Set error code to segment selector on LLDT/LTR non-canonical #GP commit 2626206963ace9e8bf92b6eea5ff78dd674c555c upstream. When injecting a #GP on LLDT/LTR due to a non-canonical LDT/TSS base, set the error code to the selector. Intel SDM's says nothing about the #GP, but AMD's APM explicitly states that both LLDT and LTR set the error code to the selector, not zero. Note, a non-canonical memory operand on LLDT/LTR does generate a #GP(0), but the KVM code in question is specific to the base from the descriptor. Fixes: e37a75a13cda ("KVM: x86: Emulator ignores LDTR/TR extended base on LLDT/LTR") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Reviewed-by: Maxim Levitsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Thu May 12 22:27:14 2022 +0000 KVM: x86: Signal #GP, not -EPERM, on bad WRMSR(MCi_CTL/STATUS) [ Upstream commit 2368048bf5c2ec4b604ac3431564071e89a0bc71 ] Return '1', not '-1', when handling an illegal WRMSR to a MCi_CTL or MCi_STATUS MSR. The behavior of "all zeros' or "all ones" for CTL MSRs is architectural, as is the "only zeros" behavior for STATUS MSRs. I.e. the intent is to inject a #GP, not exit to userspace due to an unhandled emulation case. Returning '-1' gets interpreted as -EPERM up the stack and effecitvely kills the guest. Fixes: 890ca9aefa78 ("KVM: Add MCE support") Fixes: 9ffd986c6e4e ("KVM: X86: #GP when guest attempts to write MCi_STATUS register w/o 0") Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Reviewed-by: Jim Mattson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jun 7 21:35:50 2022 +0000 KVM: x86: Split kvm_is_valid_cr4() and export only the non-vendor bits commit c33f6f2228fe8517e38941a508e9f905f99ecba9 upstream. Split the common x86 parts of kvm_is_valid_cr4(), i.e. the reserved bits checks, into a separate helper, __kvm_is_valid_cr4(), and export only the inner helper to vendor code in order to prevent nested VMX from calling back into vmx_is_valid_cr4() via kvm_is_valid_cr4(). On SVM, this is a nop as SVM doesn't place any additional restrictions on CR4. On VMX, this is also currently a nop, but only because nested VMX is missing checks on reserved CR4 bits for nested VM-Enter. That bug will be fixed in a future patch, and could simply use kvm_is_valid_cr4() as-is, but nVMX has _another_ bug where VMXON emulation doesn't enforce VMX's restrictions on CR0/CR4. The cleanest and most intuitive way to fix the VMXON bug is to use nested_host_cr{0,4}_valid(). If the CR4 variant routes through kvm_is_valid_cr4(), using nested_host_cr4_valid() won't do the right thing for the VMXON case as vmx_is_valid_cr4() enforces VMX's restrictions if and only if the vCPU is post-VMXON. Cc: [email protected] Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Wed Aug 3 22:49:55 2022 +0000 KVM: x86: Tag kvm_mmu_x86_module_init() with __init commit 982bae43f11c37b51d2f1961bb25ef7cac3746fa upstream. Mark kvm_mmu_x86_module_init() with __init, the entire reason it exists is to initialize variables when kvm.ko is loaded, i.e. it must never be called after module initialization. Fixes: 1d0e84806047 ("KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded") Cc: [email protected] Reviewed-by: Kai Huang <[email protected]> Tested-by: Michael Roth <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Wed Jun 22 14:46:31 2022 +0900 lib/smp_processor_id: fix imbalanced instrumentation_end() call [ Upstream commit bd27acaac24e4b252ee28dddcabaee80456d0faf ] Currently instrumentation_end() won't be called if printk_ratelimit() returned false. Link: https://lkml.kernel.org/r/[email protected] Fixes: 126f21f0e8d46e2c ("lib/smp_processor_id: Move it into noinstr section") Signed-off-by: Tetsuo Handa <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Alexandre Chartre <[email protected]> Cc: Peter Zijlstra <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaohe Lin <[email protected]> Date: Thu Jun 9 21:08:35 2022 +0800 lib/test_hmm: avoid accessing uninitialized pages [ Upstream commit ed913b055a74b723976f8e885a3395162a0371e6 ] If make_device_exclusive_range() fails or returns pages marked for exclusive access less than required, remaining fields of pages will left uninitialized. So dmirror_atomic_map() will access those yet uninitialized fields of pages. To fix it, do dmirror_atomic_map() iff all pages are marked for exclusive access (we will break if mapped is less than required anyway) so we won't access those uninitialized fields of pages. Link: https://lkml.kernel.org/r/[email protected] Fixes: b659baea7546 ("mm: selftests for exclusive device memory") Signed-off-by: Miaohe Lin <[email protected]> Cc: Jerome Glisse <[email protected]> Cc: Alistair Popple <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Ralph Campbell <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 19 12:51:28 2022 +0300 libbpf: fix an snprintf() overflow check [ Upstream commit b77ffb30cfc5f58e957571d8541c6a7e3da19221 ] The snprintf() function returns the number of bytes it *would* have copied if there were enough space. So it can return > the sizeof(gen->attach_target). Fixes: 67234743736a ("libbpf: Generate loader program out of BPF ELF file.") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/YtZ+oAySqIhFl6/J@kili Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Anquan Wu <[email protected]> Date: Tue Jul 12 11:15:40 2022 +0800 libbpf: Fix the name of a reused map [ Upstream commit bf3f00378524adae16628cbadbd11ba7211863bb ] BPF map name is limited to BPF_OBJ_NAME_LEN. A map name is defined as being longer than BPF_OBJ_NAME_LEN, it will be truncated to BPF_OBJ_NAME_LEN when a userspace program calls libbpf to create the map. A pinned map also generates a path in the /sys. If the previous program wanted to reuse the map， it can not get bpf_map by name, because the name of the map is only partially the same as the name which get from pinned path. The syscall information below show that map name "process_pinned_map" is truncated to "process_pinned_". bpf(BPF_OBJ_GET, {pathname="/sys/fs/bpf/process_pinned_map", bpf_fd=0, file_flags=0}, 144) = -1 ENOENT (No such file or directory) bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4,max_entries=1024, map_flags=0, inner_map_fd=0, map_name="process_pinned_",map_ifindex=0, btf_fd=3, btf_key_type_id=6, btf_value_type_id=10,btf_vmlinux_value_type_id=0}, 72) = 4 This patch check that if the name of pinned map are the same as the actual name for the first (BPF_OBJ_NAME_LEN - 1), bpf map still uses the name which is included in bpf object. Fixes: 26736eb9a483 ("tools: libbpf: allow map reuse") Signed-off-by: Anquan Wu <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/OSZP286MB1725CEA1C95C5CB8E7CCC53FB8869@OSZP286MB1725.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Wed Aug 17 14:24:32 2022 +0200 Linux 5.15.61 Link: https://lore.kernel.org/r/[email protected] Tested-by: Shuah Khan <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Link: https://lore.kernel.org/r/[email protected] Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Guenter Roeck <[email protected]> Tested-by: Ron Economos <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeff Layton <[email protected]> Date: Mon Aug 1 15:57:26 2022 -0400 lockd: detect and reject lock arguments that overflow commit 6930bcbfb6ceda63e298c6af6d733ecdf6bd4cde upstream. lockd doesn't currently vet the start and length in nlm4 requests like it should, and can end up generating lock requests with arguments that overflow when passed to the filesystem. The NLM4 protocol uses unsigned 64-bit arguments for both start and length, whereas struct file_lock tracks the start and end as loff_t values. By the time we get around to calling nlm4svc_retrieve_args, we've lost the information that would allow us to determine if there was an overflow. Start tracking the actual start and len for NLM4 requests in the nlm_lock. In nlm4svc_retrieve_args, vet these values to ensure they won't cause an overflow, and return NLM4_FBIG if they do. Link: https://bugzilla.linux-nfs.org/show_bug.cgi?id=392 Reported-by: Jan Kasiak <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Cc: <[email protected]> # 5.14+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chen Zhongjin <[email protected]> Date: Tue May 10 17:46:39 2022 +0800 locking/csd_lock: Change csdlock_debug from early_param to __setup [ Upstream commit 9c9b26b0df270d4f9246e483a44686fca951a29c ] The csdlock_debug kernel-boot parameter is parsed by the early_param() function csdlock_debug(). If set, csdlock_debug() invokes static_branch_enable() to enable csd_lock_wait feature, which triggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y and CONFIG_SPARSEMEM_VMEMMAP=n. With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called in static_key_enable() and returns NULL, resulting in a NULL dereference because mem_section is initialized only later in sparse_init(). This is also a problem for powerpc because early_param() functions are invoked earlier than jump_label_init(), also resulting in static_key_enable() failures. These failures cause the warning "static key 'xxx' used before call to jump_label_init()". Thus, early_param is too early for csd_lock_wait to run static_branch_enable(), so changes it to __setup to fix these. Fixes: 8d0968cc6b8f ("locking/csd_lock: Add boot parameter for controlling CSD lock debugging") Cc: [email protected] Reported-by: Chen jingwen <[email protected]> Signed-off-by: Chen Zhongjin <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Fri Jun 17 15:26:06 2022 +0200 locking/lockdep: Fix lockdep_init_map_*() confusion [ Upstream commit eae6d58d67d9739be5f7ae2dbead1d0ef6528243 ] Commit dfd5e3f5fe27 ("locking/lockdep: Mark local_lock_t") added yet another lockdep_init_map_*() variant, but forgot to update all the existing users of the most complicated version. This could lead to a loss of lock_type and hence an incorrect report. Given the relative rarity of both local_lock and these annotations, this is unlikely to happen in practise, still, best fix things. Fixes: dfd5e3f5fe27 ("locking/lockdep: Mark local_lock_t") Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ahmed Zaki <[email protected]> Date: Sat Oct 2 08:53:29 2021 -0600 mac80211: fix a memory leak where sta_info is not freed commit 8f9dcc29566626f683843ccac6113a12208315ca upstream. The following is from a system that went OOM due to a memory leak: wlan0: Allocated STA 74:83:c2:64:0b:87 wlan0: Allocated STA 74:83:c2:64:0b:87 wlan0: IBSS finish 74:83:c2:64:0b:87 (---from ieee80211_ibss_add_sta) wlan0: Adding new IBSS station 74:83:c2:64:0b:87 wlan0: moving STA 74:83:c2:64:0b:87 to state 2 wlan0: moving STA 74:83:c2:64:0b:87 to state 3 wlan0: Inserted STA 74:83:c2:64:0b:87 wlan0: IBSS finish 74:83:c2:64:0b:87 (---from ieee80211_ibss_work) wlan0: Adding new IBSS station 74:83:c2:64:0b:87 wlan0: moving STA 74:83:c2:64:0b:87 to state 2 wlan0: moving STA 74:83:c2:64:0b:87 to state 3 . . wlan0: expiring inactive not authorized STA 74:83:c2:64:0b:87 wlan0: moving STA 74:83:c2:64:0b:87 to state 2 wlan0: moving STA 74:83:c2:64:0b:87 to state 1 wlan0: Removed STA 74:83:c2:64:0b:87 wlan0: Destroyed STA 74:83:c2:64:0b:87 The ieee80211_ibss_finish_sta() is called twice on the same STA from 2 different locations. On the second attempt, the allocated STA is not destroyed creating a kernel memory leak. This is happening because sta_info_insert_finish() does not call sta_info_free() the second time when the STA already exists (returns -EEXIST). Note that the caller sta_info_insert_rcu() assumes STA is destroyed upon errors. Same fix is applied to -ENOMEM. Signed-off-by: Ahmed Zaki <[email protected]> Link: https://lore.kernel.org/r/[email protected] [change the error path label to use the existing code] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Viacheslav Sablin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nick Desaulniers <[email protected]> Date: Wed Aug 10 15:24:40 2022 -0700 Makefile: link with -z noexecstack --no-warn-rwx-segments commit 0d362be5b14200b77ecc2127936a5ff82fbffe41 upstream. Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form: ld: warning: vmlinux: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: vmlinux has a LOAD segment with RWX permissions Generally, we would like to avoid the stack being executable. Because there could be a need for the stack to be executable, assembler sources have to opt-in to this security feature via explicit creation of the .note.GNU-stack feature (which compilers create by default) or command line flag --noexecstack. Or we can simply tell the linker the production of such sections is irrelevant and to link the stack as --noexecstack. LLVM's LLD linker defaults to -z noexecstack, so this flag isn't strictly necessary when linking with LLD, only BFD, but it doesn't hurt to be explicit here for all linkers IMO. --no-warn-rwx-segments is currently BFD specific and only available in the current latest release, so it's wrapped in an ld-option check. While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments. Link: https://lore.kernel.org/linux-block/[email protected]/ Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Link: https://github.com/llvm/llvm-project/issues/57009 Reported-and-tested-by: Jens Axboe <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:21 2022 +0200 mbcache: add functions to delete entry if unused commit 3dc96bba65f53daa217f0a8f43edad145286a8f5 upstream. Add function mb_cache_entry_delete_or_get() to delete mbcache entry if it is unused and also add a function to wait for entry to become unused - mb_cache_entry_wait_unused(). We do not share code between the two deleting function as one of them will go away soon. CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Kara <[email protected]> Date: Tue Jul 12 12:54:20 2022 +0200 mbcache: don't reclaim used entries commit 58318914186c157477b978b1739dfe2f1b9dc0fe upstream. Do not reclaim entries that are currently used by somebody from a shrinker. Firstly, these entries are likely useful. Secondly, we will need to keep such entries to protect pending increment of xattr block refcount. CC: [email protected] Fixes: 82939d7999df ("ext4: convert to mbcache2") Signed-off-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Tue Jul 26 04:33:12 2022 -0400 md-raid10: fix KASAN warning commit d17f744e883b2f8d13cca252d71cfe8ace346f7d upstream. There's a KASAN warning in raid10_remove_disk when running the lvm test lvconvert-raid-reshape.sh. We fix this warning by verifying that the value "number" is valid. BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10] Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682 CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? raid10_remove_disk+0x61/0x2a0 [raid10] kasan_report+0xa8/0xe0 ? raid10_remove_disk+0x61/0x2a0 [raid10] raid10_remove_disk+0x61/0x2a0 [raid10] Buffer I/O error on dev dm-76, logical block 15344, async page read ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0 remove_and_add_spares+0x367/0x8a0 [md_mod] ? super_written+0x1c0/0x1c0 [md_mod] ? mutex_trylock+0xac/0x120 ? _raw_spin_lock+0x72/0xc0 ? _raw_spin_lock_bh+0xc0/0xc0 md_check_recovery+0x848/0x960 [md_mod] raid10d+0xcf/0x3360 [raid10] ? sched_clock_cpu+0x185/0x1a0 ? rb_erase+0x4d4/0x620 ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid10_sync_request+0x36c0/0x36c0 [raid10] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? _raw_spin_unlock_irq+0x11/0x24 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 124495: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 setup_conf+0x140/0x5c0 [raid10] raid10_run+0x4cd/0x740 [raid10] md_run+0x6f9/0x1300 [md_mod] raid_ctr+0x2531/0x4ac0 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 L __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Second to last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x9e/0xc0 kvfree_call_rcu+0x84/0x480 timerfd_release+0x82/0x140 __fput+0xfa/0x400 task_work_run+0x80/0xc0 exit_to_user_mode_prepare+0x155/0x160 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x42/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The buggy address belongs to the object at ffff889108f3d200 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte region [ffff889108f3d200, ffff889108f3d300) The buggy address belongs to the physical page: page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=2) raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff889108f3d280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff889108f3d300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff889108f3d380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff889108f3d400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Sun Jul 24 14:26:12 2022 -0400 md-raid: destroy the bitmap after destroying the thread commit e151db8ecfb019b7da31d076130a794574c89f6f upstream. When we ran the lvm test "shell/integrity-blocksize-3.sh" on a kernel with kasan, we got failure in write_page. The reason for the failure is that md_bitmap_destroy is called before destroying the thread and the thread may be waiting in the function write_page for the bio to complete. When the thread finishes waiting, it executes "if (test_bit(BITMAP_WRITE_ERROR, &bitmap->flags))", which triggers the kasan warning. Note that the commit 48df498daf62 that caused this bug claims that it is neede for md-cluster, you should check md-cluster and possibly find another bugfix for it. BUG: KASAN: use-after-free in write_page+0x18d/0x680 [md_mod] Read of size 8 at addr ffff889162030c78 by task mdX_raid1/5539 CPU: 10 PID: 5539 Comm: mdX_raid1 Not tainted 5.19.0-rc2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x45/0x57a ? __lock_text_start+0x18/0x18 ? write_page+0x18d/0x680 [md_mod] kasan_report+0xa8/0xe0 ? write_page+0x18d/0x680 [md_mod] kasan_check_range+0x13f/0x180 write_page+0x18d/0x680 [md_mod] ? super_sync+0x4d5/0x560 [dm_raid] ? md_bitmap_file_kick+0xa0/0xa0 [md_mod] ? rs_set_dev_and_array_sectors+0x2e0/0x2e0 [dm_raid] ? mutex_trylock+0x120/0x120 ? preempt_count_add+0x6b/0xc0 ? preempt_count_sub+0xf/0xc0 md_update_sb+0x707/0xe40 [md_mod] md_reap_sync_thread+0x1b2/0x4a0 [md_mod] md_check_recovery+0x533/0x960 [md_mod] raid1d+0xc8/0x2a20 [raid1] ? var_wake_function+0xe0/0xe0 ? psi_group_change+0x411/0x500 ? preempt_count_sub+0xf/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? raid1_end_read_request+0x2a0/0x2a0 [raid1] ? preempt_count_sub+0xf/0xc0 ? _raw_spin_unlock_irqrestore+0x19/0x40 ? del_timer_sync+0xa9/0x100 ? try_to_del_timer_sync+0xc0/0xc0 ? _raw_spin_lock_irqsave+0x78/0xc0 ? __lock_text_start+0x18/0x18 ? __list_del_entry_valid+0x68/0xa0 ? finish_wait+0xa3/0x100 md_thread+0x161/0x260 [md_mod] ? unregister_md_personality+0xa0/0xa0 [md_mod] ? _raw_spin_lock_irqsave+0x78/0xc0 ? prepare_to_wait_event+0x2c0/0x2c0 ? unregister_md_personality+0xa0/0xa0 [md_mod] kthread+0x148/0x180 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 5522: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x80/0xa0 md_bitmap_create+0xa8/0xe80 [md_mod] md_run+0x777/0x1300 [md_mod] raid_ctr+0x249c/0x4a30 [dm_raid] dm_table_add_target+0x2b0/0x620 [dm_mod] table_load+0x1c8/0x400 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Freed by task 5680: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x40 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0xf7/0x140 kfree+0x80/0x240 md_bitmap_free+0x1c3/0x280 [md_mod] __md_stop+0x21/0x120 [md_mod] md_stop+0x9/0x40 [md_mod] raid_dtr+0x1b/0x40 [dm_raid] dm_table_destroy+0x98/0x1e0 [dm_mod] __dm_destroy+0x199/0x360 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x29e/0x560 [dm_mod] dm_compat_ctl_ioctl+0x7/0x20 [dm_mod] __do_compat_sys_ioctl+0xfa/0x160 do_syscall_64+0x90/0xc0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Signed-off-by: Mikulas Patocka <[email protected]> Cc: [email protected] Fixes: 48df498daf62 ("md: move bitmap_destroy to the beginning of __md_stop") Signed-off-by: Song Liu <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiaomeng Tong <[email protected]> Date: Thu Apr 14 05:14:15 2022 +0100 media: [PATCH] pci: atomisp_cmd: fix three missing checks on list iterator commit 09b204eb9de9fdf07d028c41c4331b5cfeb70dd7 upstream. The three bugs are here: __func__, s3a_buf->s3a_data->exp_id); __func__, md_buf->metadata->exp_id); __func__, dis_buf->dis_data->exp_id); The list iterator 's3a_buf/md_buf/dis_buf' will point to a bogus position containing HEAD if the list is empty or no element is found. This case must be checked before any use of the iterator, otherwise it will lead to a invalid memory access. To fix this bug, add an check. Use a new variable '*_iter' as the list iterator, while use the old variable '*_buf' as a dedicated pointer to point to the found element. Link: https://lore.kernel.org/linux-media/[email protected] Cc: [email protected] Fixes: ad85094b293e4 ("Revert "media: staging: atomisp: Remove driver"") Signed-off-by: Xiaomeng Tong <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eugen Hristev <[email protected]> Date: Tue May 3 12:12:16 2022 +0100 media: atmel: atmel-sama7g5-isc: fix warning in configs without OF [ Upstream commit b2bae4b8e637dd751d27918a6b27bd5abcd08859 ] All warnings (new ones prefixed by >>): >> drivers/media/platform/atmel/atmel-sama7g5-isc.c:610:34: warning: unused variable 'microchip_xisc_of_match' [-Wunused-const-variable] static const struct of_device_id microchip_xisc_of_match[] = { ^ 13 warnings generated. vim +/microchip_xisc_of_match +610 drivers/media/platform/atmel/atmel-sama7g5-isc.c 609 > 610 static const struct of_device_id microchip_xisc_of_match[] = { 611 { .compatible = "microchip,sama7g5-isc" }, 612 { } 613 }; 614 MODULE_DEVICE_TABLE(of, microchip_xisc_of_match); 615 Fixed warning by guarding the atmel_isc_of_match by CONFIG_OF. Reported-by: kernel test robot <[email protected]> Fixes: c9aa973884a1 ("media: atmel: atmel-isc: add microchip-xisc driver") Signed-off-by: Eugen Hristev <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jernej Skrabec <[email protected]> Date: Mon Jun 20 18:55:11 2022 +0100 media: cedrus: h265: Fix flag name [ Upstream commit 104a70e1d0bcef28db13c4192b8729086089651c ] Bit 21 in register 0x24 (slice header info 1) actually represents negated version of low delay flag. This can be seen in vendor Cedar library source code. While this flag is not part of the standard, it can be found in reference HEVC implementation. Fix macro name and change it to flag. Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support") Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jernej Skrabec <[email protected]> Date: Mon Jul 18 18:56:49 2022 +0200 media: cedrus: hevc: Add check for invalid timestamp [ Upstream commit 143201a6435bf65f0115435e9dc6d95c66b908e9 ] Not all DPB entries will be used most of the time. Unused entries will thus have invalid timestamps. They will produce negative buffer index which is not specifically handled. This works just by chance in current code. It will even produce bogus pointer, but since it's not used, it won't do any harm. Let's fix that brittle design by skipping writing DPB entry altogether if timestamp is invalid. Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support") Signed-off-by: Jernej Skrabec <[email protected]> Reviewed-by: Ezequiel Garcia <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Zhang <[email protected]> Date: Mon Jun 20 09:34:23 2022 +0100 media: driver/nxp/imx-jpeg: fix a unexpected return value problem [ Upstream commit 5b304046a81eda221b5d06a9c62f7b5e45530fa5 ] In function mxc_jpeg_probe(), when devm_clk_get() fail, the return value will be unexpected, and it should be the devm_clk_get's error code. Fixes: 4c2e5156d9fa6 ("media: imx-jpeg: Add pm-runtime support for imx-jpeg") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jian Zhang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ezequiel Garcia <[email protected]> Date: Tue Nov 16 14:38:31 2021 +0000 media: hantro: postproc: Fix motion vector space size [ Upstream commit 9393761aec4c56b7f2f19d21f806d316731401c1 ] When the post-processor hardware block is enabled, the driver allocates an internal queue of buffers for the decoder enginer, and uses the vb2 queue for the post-processor engine. For instance, on a G1 core, the decoder engine produces NV12 buffers and the post-processor engine can produce YUY2 buffers. The decoder engine expects motion vectors to be appended to the NV12 buffers, but this is only required for CODECs that need motion vectors, such as H.264. Fix the post-processor logic accordingly. Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Andrzej Pietrasiewicz <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ezequiel Garcia <[email protected]> Date: Tue Nov 16 14:38:33 2021 +0000 media: hantro: Simplify postprocessor [ Upstream commit 53a3e71095c572333ceea30762565dbedec951ca ] Add a 'postprocessed' boolean property to struct hantro_fmt to signal that a format is produced by the post-processor. This will allow to introduce the G2 post-processor in a simple way. Signed-off-by: Ezequiel Garcia <[email protected]> Signed-off-by: Andrzej Pietrasiewicz <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Niels Dossche <[email protected]> Date: Tue Jun 14 18:50:02 2022 +0100 media: hdpvr: fix error value returns in hdpvr_read [ Upstream commit 359c27c6ddbde404f44a9c0d3ec88ccd1e2042f2 ] Error return values are supposed to be negative in hdpvr_read. Most error returns are currently handled via an unsigned integer "ret". When setting a negative error value to "ret", the value actually becomes a large positive value, because "ret" is unsigned. Later on, the "ret" value is returned. But as ssize_t is a 64-bit signed number, the error return value stays a large positive integer instead of a negative integer. This can cause an error value to be interpreted as the read size, which can cause a buffer overread for applications relying on the returned size. Fixes: 9aba42efe85b ("V4L/DVB (11096): V4L2 Driver for the Hauppauge HD PVR usb capture device") Signed-off-by: Niels Dossche <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Fri Jan 7 16:54:55 2022 +0100 media: hevc: Embedded indexes in RPS [ Upstream commit d95a63daca85f4bca3b70e622c75586b5bf0ea5c ] Reference Picture Set lists provide indices of short and long term reference in DBP array. Fix Hantro to not do a look up in DBP entries. Make documentation more clear about it. [hverkuil: fix typo in commit log] Signed-off-by: Benjamin Gaignard <[email protected]> Reviewed-by: Ezequiel Garcia <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mirela Rabulea <[email protected]> Date: Thu Oct 7 17:30:38 2021 +0100 media: imx-jpeg: Add pm-runtime support for imx-jpeg [ Upstream commit 4c2e5156d9fa63a3f41c2bf56b694ad42df825d7 ] Save some power by disabling/enabling the jpeg clocks with every stream stop/start. Do not use DL_FLAG_RPM_ACTIVE in mxc_jpeg_attach_pm_domains, to ensure power domains are off after probe. Signed-off-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Mon May 30 08:49:19 2022 +0100 media: imx-jpeg: Align upwards buffer size [ Upstream commit 9e7aa76cdb02923ee23a0ddd48f38bdc3512f92b ] The hardware can support any image size WxH, with arbitrary W (image width) and H (image height) dimensions. Align upwards buffer size for both encoder and decoder. and leave the picture resolution unchanged. For decoder, the risk of memory out of bounds can be avoided. For both encoder and decoder, the driver will lift the limitation of resolution alignment. For example, the decoder can support jpeg whose resolution is 227x149 the encoder can support nv12 1080P, won't change it to 1920x1072. Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Mon May 30 08:47:31 2022 +0100 media: imx-jpeg: Correct some definition according specification [ Upstream commit 5a601f89e846c1b6005ab274d039e5036fc22015 ] the register CAST_NOMFRSIZE_LO should be equal to CAST_STATUS16 the register CAST_NOMFRSIZE_HI should be equal to CAST_STATUS17 the register CAST_OFBSIZE_LO should be equal to CAST_STATUS18 the register CAST_OFBSIZE_HI should be equal to CAST_STATUS19 Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Fri Jun 10 03:00:57 2022 +0100 media: imx-jpeg: Disable slot interrupt when frame done [ Upstream commit 22a2bc88c139dc9757bdb1d0a3665ac27edc79a5 ] The interrupt STMBUF_HALF may be triggered after frame done. It may led to system hang if driver try to access the register after power off. Disable the slot interrupt when frame done. Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Tested-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed Mar 23 10:05:57 2022 +0100 media: imx-jpeg: Handle source change in a function [ Upstream commit 831f87424dd3973612782983ef7352789795b4df ] Refine code to support dynamic resolution change Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed Mar 23 10:05:55 2022 +0100 media: imx-jpeg: Identify and handle precision correctly [ Upstream commit bec0a3a67389ede106d0661a007edf832878d8b2 ] The decoder will save the precision that was detected from jpeg header and use it later, when choosing the pixel format and also calculate bytesperline according to precision. The 12bit jpeg is not supported yet, but driver shouldn't led to serious problem if user enqueue a 12 bit jpeg. And the 12bit jpeg is supported by hardware, driver may support it later. [hverkuil: document the new precision field] Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Mon May 30 08:50:02 2022 +0100 media: imx-jpeg: Implement drain using v4l2-mem2mem helpers [ Upstream commit 4911c5acf9351c4caf692895c7cf6a4fa46c26b0 ] v4l2 m2m has supplied some helper function to handle drain, so the driver can use the helper function directly. Fixes: d8ebe298d008c ("media: imx-jpeg: Set V4L2_BUF_FLAG_LAST at eos") Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Mon May 30 08:48:37 2022 +0100 media: imx-jpeg: Leave a blank space before the configuration data [ Upstream commit 6285cdea19daf764bf00f662a59fc83ef67345cf ] There is a hardware bug that it will load the first 128 bytes of configuration data twice, it will led to some configure error. so shift the configuration data 128 bytes, and make the first 128 bytes all zero, then hardware will load the 128 zero twice, and ignore them as garbage. then the configuration data can be loaded correctly Fixes: 2db16c6ed72ce ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Reviewed-by: Tommaso Merciai <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed Mar 23 10:05:54 2022 +0100 media: imx-jpeg: Refactor function mxc_jpeg_parse [ Upstream commit 8dd504a3a0a5f73b4c137ce3afc35936a4ecd871 ] Refine code to support dynamic resolution change Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Tue Feb 22 16:41:16 2022 +0800 media: imx-jpeg: Set V4L2_BUF_FLAG_LAST at eos [ Upstream commit d8ebe298d008ccbae3011cbeb139707f01a730c8 ] The V4L2_EVENT_EOS event is a deprecated behavior, the V4L2_BUF_FLAG_LAST buffer flag should be used instead. Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed Mar 23 10:05:58 2022 +0100 media: imx-jpeg: Support dynamic resolution change [ Upstream commit b4e1fb8643daabba850e97df532191acffc23e6a ] To support dynamic resolution change, driver should meet the following conditions: 1. the previous pictures are all decoded before source change event. 2. prevent decoding new resolution pictures with incorrect capture buffer, until user handle source change event and setup capture. 3. report correct fmt and resolution during source change. Signed-off-by: Ming Qian <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Fri Dec 24 04:02:41 2021 +0100 media: imx-jpeg: use NV12M to represent non contiguous NV12 [ Upstream commit 784a1883cff07e7510a81ad3041d6ec443d51944 ] V4L2_PIX_FMT_NV12 requires num_planes equals to 1, V4L2_PIX_FMT_NV12M requires num_planes equals to 2. and mxc-jpeg supports 2 planes for nv12, so we should use 4L2_PIX_FMT_NV12M instead of V4L2_PIX_FMT_NV12, otherwise it will confuses gstreamer and prevent encoding and decoding. Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Shijie Qin <[email protected]> Signed-off-by: Zhou Peng <[email protected]> Reviewed-by: Mirela Rabulea <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Thu Jun 23 14:55:46 2022 +0100 media: platform: mtk-mdp: Fix mdp_ipi_comm structure alignment [ Upstream commit ab14c99c035da7156a3b66fa171171295bc4b89a ] The mdp_ipi_comm structure defines a command that is either PROCESS (start processing) or DEINIT (destroy instance); we are using this one to send PROCESS or DEINIT commands from Linux to an MDP instance through a VPU write but, while the first wants us to stay 4-bytes aligned, the VPU instead requires an 8-bytes data alignment. Keeping in mind that these commands are executed immediately after sending them (hence not chained with others before the VPU/MDP "actually" start executing), it is fine to simply add a padding of 4 bytes to this structure: this keeps the same performance as before, as we're still stack-allocating it, while avoiding hackery inside of mtk-vpu to ensure alignment bringing a definitely bigger performance impact. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Houlong Wei <[email protected]> Reviewed-by: Irui Wang <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sebastian Fricke <[email protected]> Date: Sat Mar 26 19:36:03 2022 +0100 media: staging: media: hantro: Fix typos [ Upstream commit d8f6f1c56d5469e22eeb7cc1f3580b29e2f0fef5 ] Fix typos in comments within the Hantro driver. Signed-off-by: Sebastian Fricke <[email protected]> Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Tue Jun 21 06:30:30 2022 +0100 media: tw686x: Fix memory leak in tw686x_video_init [ Upstream commit e0b212ec9d8177d6f7c404315293f6a085d6ee42 ] video_device_alloc() allocates memory for vdev, when video_register_device() fails, it doesn't release the memory and leads to memory leak, call video_device_release() to fix this. Fixes: 704a84ccdbf1 ("[media] media: Support Intersil/Techwell TW686x-based video capture cards") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Sat May 21 07:24:01 2022 +0100 media: tw686x: Register the irq at the end of probe [ Upstream commit fb730334e0f759d00f72168fbc555e5a95e35210 ] We got the following warning when booting the kernel: [ 3.243674] INFO: trying to register non-static key. [ 3.243922] The code is fine but needs lockdep annotation, or maybe [ 3.244230] you didn't initialize this object before use? [ 3.245642] Call Trace: [ 3.247836] lock_acquire+0xff/0x2d0 [ 3.248727] tw686x_audio_irq+0x1a5/0xcc0 [tw686x] [ 3.249211] tw686x_irq+0x1f9/0x480 [tw686x] The lock 'vc->qlock' will be initialized in tw686x_video_init(), but the driver registers the irq before calling the tw686x_video_init(), and we got the warning. Fix this by registering the irq at the end of probe Fixes: 704a84ccdbf1 ("[media] media: Support Intersil/Techwell TW686x-based video capture cards") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ming Qian <[email protected]> Date: Wed Jun 15 04:19:20 2022 +0100 media: v4l2-mem2mem: prevent pollerr when last_buffer_dequeued is set [ Upstream commit d4de27a9b1eadd33a2e40de87a646d1bf5fef756 ] If the last buffer was dequeued from the capture queue, signal userspace. DQBUF(CAPTURE) will return -EPIPE. But if output queue is empty and capture queue is empty, v4l2_m2m_poll_for_data will return EPOLLERR, This is very easy to happen in drain. When last_buffer_dequeued is set, we shouldn't return EPOLLERR, but return EPOLLIN | EPOLLRDNORM. Fixes: 1698a7f151126 ("media: v4l2-mem2mem: simplify poll logic") Signed-off-by: Ming Qian <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Mon Jul 4 16:34:21 2022 +0800 mediatek: mt76: eeprom: fix missing of_node_put() in mt76_find_power_limits_node() [ Upstream commit 3bd53ea02d77917c2314ec7be9e2d05be22f87d3 ] We should use of_node_put() for the reference 'np' returned by of_get_child_by_name() which will increase the refcount. Fixes: 22b980badc0f ("mt76: add functions for parsing rate power limits from DT") Signed-off-by: Liang He <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Mon Jul 4 16:34:20 2022 +0800 mediatek: mt76: mac80211: Fix missing of_node_put() in mt76_led_init() [ Upstream commit 0a14c1d0113f121151edf34333cdf212dd209190 ] We should use of_node_put() for the reference 'np' returned by of_get_child_by_name() which will increase the refcount. Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets") Signed-off-by: Liang He <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Thu Oct 28 17:10:17 2021 +0200 memremap: remove support for external pgmap refcounts [ Upstream commit b80892ca022e9eb484771a66eb68e12364695a2a ] No driver is left using the external pgmap refcount, so remove the code to support it. Signed-off-by: Christoph Hellwig <[email protected]> Acked-by: Bjorn Helgaas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dan Williams <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sat Jun 25 14:55:56 2022 +0200 memstick/ms_block: Fix a memory leak [ Upstream commit 54eb7a55be6779c4d0c25eaf5056498a28595049 ] 'erased_blocks_bitmap' is never freed. As it is allocated at the same time as 'used_blocks_bitmap', it is likely that it should be freed also at the same time. Add the corresponding bitmap_free() in msb_data_clear(). Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/b3b78926569445962ea5c3b6e9102418a9effb88.1656155715.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sat Jun 25 14:55:25 2022 +0200 memstick/ms_block: Fix some incorrect memory allocation [ Upstream commit 2e531bc3e0d86362fcd8a577b3278d9ef3cc2ba0 ] Some functions of the bitmap API take advantage of the fact that a bitmap is an array of long. So, to make sure this assertion is correct, allocate bitmaps with bitmap_zalloc() instead of kzalloc()+hand-computed number of bytes. While at it, also use bitmap_free() instead of kfree() to keep the semantic. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/dbf633c48c24ae6d95f852557e8d8b3bbdef65fe.1656155715.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Tue May 24 10:57:29 2022 +0400 meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init [ Upstream commit a2106f38077e78afcb4bf98fdda3e162118cfb3d ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 5e68c0fc8df8 ("soc: amlogic: Add Meson6/Meson8/Meson8b/Meson8m2 SoC Information driver") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed Jun 1 08:32:22 2022 +0400 mfd: max77620: Fix refcount leak in max77620_initialise_fps [ Upstream commit 1520669c8255bd637c6b248b2be910e2688d38dd ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 327156c59360 ("mfd: max77620: Add core driver for MAX77620/MAX20024") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon May 30 21:24:28 2022 +0200 mfd: t7l66xb: Drop platform disable callback [ Upstream commit 128ac294e1b437cb8a7f2ff8ede1cde9082bddbe ] None of the in-tree instantiations of struct t7l66xb_platform_data provides a disable callback. So better don't dereference this function pointer unconditionally. As there is no user, drop it completely instead of calling it conditional. This is a preparation for making platform remove callbacks return void. Fixes: 1f192015ca5b ("mfd: driver for the T7L66XB TMIO SoC") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Lee Jones <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Huacai Chen <[email protected]> Date: Thu Jul 14 16:41:34 2022 +0800 MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK commit e1a534f5d074db45ae5cbac41d8912b98e96a006 upstream. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<98000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<980000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- Cc: [email protected] Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Thu Jul 14 15:25:12 2022 -0700 MIPS: Fixed __debug_virt_addr_valid() [ Upstream commit 8a2b456665d1e797123669581524cbb095fb003b ] It is permissible for kernel code to call virt_to_phys() against virtual addresses that are in KSEG0 or KSEG1 and we need to be dealing with both types. Rewrite the test condition to ensure that the kernel virtual addresses are above PAGE_OFFSET which they must be, and below KSEG2 where the non-linear mapping starts. For EVA, there is not much that we can do given the linear address range that is offered, so just return any virtual address as being valid. Finally, when HIGHMEM is not enabled, all virtual addresses are assumed to be valid as well. Fixes: dfad83cb7193 ("MIPS: Add support for CONFIG_DEBUG_VIRTUAL") Signed-off-by: Florian Fainelli <[email protected]> Reviewed-by: Serge Semin <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Thu Jul 7 13:27:58 2022 -0700 MIPS: vdso: Utilize __pa() for gic_pfn [ Upstream commit 8baa65126e19af5ee9f3c07e7bb53da41c39e4b1 ] The GIC user offset is mapped into every process' virtual address and is therefore part of the hot-path of arch_setup_additional_pages(). Utilize __pa() such that we are more optimal even when CONFIG_DEBUG_VIRTUAL is enabled, and while at it utilize PFN_DOWN() instead of open-coding the right shift by PAGE_SHIFT. Reported-by: Greg Ungerer <[email protected]> Suggested-by: Serge Semin <[email protected]> Fixes: dfad83cb7193 ("MIPS: Add support for CONFIG_DEBUG_VIRTUAL") Signed-off-by: Florian Fainelli <[email protected]> Acked-by: Greg Ungerer <[email protected]> Tested-by: Greg Ungerer <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Wed Jun 15 07:33:44 2022 +0200 misc: rtsx: Fix an error handling path in rtsx_pci_probe() [ Upstream commit 44fd1917314e9d4f53dd95dd65df1c152f503d3a ] If an error occurs after a successful idr_alloc() call, the corresponding resource must be released with idr_remove() as already done in the .remove function. Update the error handling path to add the missing idr_remove() call. Fixes: ada8a8a13b13 ("mfd: Add realtek pcie card reader driver") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/e8dc41716cbf52fb37a12e70d8972848e69df6d6.1655271216.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tianyu Li <[email protected]> Date: Wed Jun 1 17:32:11 2022 +0800 mm/mempolicy: fix get_nodes out of bound access [ Upstream commit 000eca5d044d1ee23b4ca311793cf3fc528da6c6 ] When user specified more nodes than supported, get_nodes will access nmask array out of bounds. Link: https://lkml.kernel.org/r/[email protected] Fixes: e130242dc351 ("mm: simplify compat numa syscalls") Signed-off-by: Tianyu Li <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Mark Rutland <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaohe Lin <[email protected]> Date: Thu Jun 9 20:13:05 2022 +0800 mm/memremap: fix memunmap_pages() race with get_dev_pagemap() [ Upstream commit 1e57ffb6e3fd9583268c6462c4e3853575b21701 ] Think about the below scene: CPU1 CPU2 memunmap_pages percpu_ref_exit __percpu_ref_exit free_percpu(percpu_count); /* percpu_count is freed here! */ get_dev_pagemap xa_load(&pgmap_array, PHYS_PFN(phys)) /* pgmap still in the pgmap_array */ percpu_ref_tryget_live(&pgmap->ref) if __ref_is_percpu /* __PERCPU_REF_ATOMIC_DEAD not set yet */ this_cpu_inc(*percpu_count) /* access freed percpu_count here! */ ref->percpu_count_ptr = __PERCPU_REF_ATOMIC_DEAD; /* too late... */ pageunmap_range To fix the issue, do percpu_ref_exit() after pgmap_array is emptied. So we won't do percpu_ref_tryget_live() against a being freed percpu_ref. Link: https://lkml.kernel.org/r/[email protected] Fixes: b7b3c01b1915 ("mm/memremap_pages: support multiple ranges per invocation") Signed-off-by: Miaohe Lin <[email protected]> Cc: Dan Williams <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaohe Lin <[email protected]> Date: Sat Jun 18 16:20:27 2022 +0800 mm/mmap.c: fix missing call to vm_unacct_memory in mmap_region [ Upstream commit 7f82f922319ede486540e8746769865b9508d2c2 ] Since the beginning, charged is set to 0 to avoid calling vm_unacct_memory twice because vm_unacct_memory will be called by above unmap_region. But since commit 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from the unmap_vmas() interfaces"), unmap_region doesn't call vm_unacct_memory anymore. So charged shouldn't be set to 0 now otherwise the calling to paired vm_unacct_memory will be missed and leads to imbalanced account. Link: https://lkml.kernel.org/r/[email protected] Fixes: 4f74d2c8e827 ("vm: remove 'nr_accounted' calculations from the unmap_vmas() interfaces") Signed-off-by: Miaohe Lin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Loehle <[email protected]> Date: Fri Jul 1 12:43:09 2022 +0000 mmc: block: Add single read for 4k sector cards [ Upstream commit b3fa3e6dccc465969721b8bd2824213bd235efeb ] Cards with 4k native sector size may only be read 4k-aligned, accommodate for this in the single read recovery and use it. Fixes: 81196976ed946 (mmc: block: Add blk-mq support) Signed-off-by: Christian Loehle <[email protected]> Acked-by: Adrian Hunter <[email protected]> Reviewed-by: Avri Altman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Tue Jul 19 17:52:15 2022 +0800 mmc: cavium-octeon: Add of_node_put() when breaking out of loop [ Upstream commit 19bbb49acf8d7a03cb83e05624363741a4c3ec6f ] In octeon_mmc_probe(), we should call of_node_put() when breaking out of for_each_child_of_node() which has increased and decreased the refcount during each iteration. Fixes: 01d95843335c ("mmc: cavium: Add MMC support for Octeon SOCs.") Signed-off-by: Liang He <[email protected]> Acked-by: Robert Richter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Tue Jul 19 17:52:16 2022 +0800 mmc: cavium-thunderx: Add of_node_put() when breaking out of loop [ Upstream commit 7ee480795e41db314f2c445c65ed854a5d6e8e32 ] In thunder_mmc_probe(), we should call of_node_put() when breaking out of for_each_child_of_node() which has increased and decreased the refcount during each iteration. Fixes: 166bac38c3c5 ("mmc: cavium: Add MMC PCI driver for ThunderX SOCs") Signed-off-by: Liang He <[email protected]> Acked-by: Robert Richter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabio Estevam <[email protected]> Date: Wed May 25 22:00:22 2022 -0300 mmc: mxcmmc: Silence a clang warning [ Upstream commit 7dc65e3c0ef4b746a583b7c58f99873fddf5ccfa ] Change the of_device_get_match_data() cast to (uintptr_t) to silence the following clang warning: drivers/mmc/host/mxcmmc.c:1028:18: warning: cast to smaller integer type 'enum mxcmci_type' from 'const void *' [-Wvoid-pointer-to-enum-cast] Reported-by: kernel test robot <[email protected]> Fixes: 8223e885e74b ("mmc: mxc: Convert the driver to DT-only") Signed-off-by: Fabio Estevam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lad Prabhakar <[email protected]> Date: Fri Jun 24 19:14:37 2022 +0100 mmc: renesas_sdhi: Get the reset handle early in the probe [ Upstream commit 0dac1e498f8130fdacfdd5289e3a7ac87ec1b9ad ] In case of devm_reset_control_get_optional_exclusive() failure we returned directly instead of jumping to the error path to roll back initialization. This patch moves devm_reset_control_get_optional_exclusive() early in the probe so that we have the reset handle prior to initialization of the hardware. Fixes: b4d86f37eacb7 ("mmc: renesas_sdhi: do hard reset if possible") Reported-by: Pavel Machek <[email protected]> Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Wolfram Sang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eugen Hristev <[email protected]> Date: Thu Jun 30 12:09:26 2022 +0300 mmc: sdhci-of-at91: fix set_uhs_signaling rewriting of MC1R [ Upstream commit 5987e6ded29d52e42fc7b06aa575c60a25eee38e ] In set_uhs_signaling, the DDR bit is being set by fully writing the MC1R register. This can lead to accidental erase of certain bits in this register. Avoid this by doing a read-modify-write operation. Fixes: d0918764c17b ("mmc: sdhci-of-at91: fix MMC_DDR_52 timing selection") Signed-off-by: Eugen Hristev <[email protected]> Tested-by: Karl Olsen <[email protected]> Acked-by: Adrian Hunter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon May 23 18:42:54 2022 +0400 mmc: sdhci-of-esdhc: Fix refcount leak in esdhc_signal_voltage_switch [ Upstream commit b5899a3e2f783a27b268e38d37f9b24c71bddf45 ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. Fixes: ea35645a3c66 ("mmc: sdhci-of-esdhc: add support for signal voltage switch") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Mon Jun 13 14:03:28 2022 +0200 mt76: mt7615: do not update pm stats in case of error [ Upstream commit 79717c4eeeae9dec894794fbe8af72f08f03ebdd ] Do not update pm stats if mt7615_mcu_fw_pmctrl returns an error. Fixes: abe912ae3cd42 ("mt76: mt7663: add awake and doze time accounting") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenzo Bianconi <[email protected]> Date: Tue May 17 18:37:07 2022 +0200 mt76: mt76x02u: fix possible memory leak in __mt76x02u_mcu_send_msg [ Upstream commit cffd93411575afd987788e2ec3cb8eaff70f0215 ] Free the skb if mt76u_bulk_msg fails in __mt76x02u_mcu_send_msg routine. Fixes: 4c89ff2c74e39 ("mt76: split __mt76u_mcu_send_msg and mt76u_mcu_send_msg routines") Co-developed-by: Gergo Koteles <[email protected]> Signed-off-by: Gergo Koteles <[email protected]> Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Deren Wu <[email protected]> Date: Sat Jun 18 18:56:44 2022 +0800 mt76: mt7921: enlarge maximum VHT MPDU length to 11454 [ Upstream commit 31f3248a75932b111bc90c66b1f6c7d89eedca8e ] Enlarge maximum MPDU length to 11454 that both mt7921/mt7922 can support. After this fixing, we can get better performance. Fixes: 5c14a5f944b9 ("mt76: mt7921: introduce mt7921e support") Tested-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Deren Wu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Deren Wu <[email protected]> Date: Thu Jun 16 23:57:43 2022 +0800 mt76: mt7921: fix aggregation subframes setting to HE max [ Upstream commit d5a50e6bd1972c481f82befa846dce0b9866f025 ] mt7921/mt7922 support HE max aggregation subframes 256 for both tx/rx. Get better throughput then before. Fixes: 94bb18b03d43 ("mt76: mt7921: fix max aggregation subframes setting") Tested-by: Ming Yen Hsieh <[email protected]> Reviewed-by: Sean Wang <[email protected]> Signed-off-by: Deren Wu <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mark Brown <[email protected]> Date: Mon Jun 20 16:23:13 2022 +0100 mtd: dataflash: Add SPI ID table [ Upstream commit ac4f83482afbfd927d0fe118151b747cf175e724 ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon May 23 18:32:55 2022 +0400 mtd: maps: Fix refcount leak in ap_flash_init [ Upstream commit 77087a04c8fd554134bddcb8a9ff87b21f357926 ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: b0afd44bc192 ("mtd: physmap_of: add a hook for Versatile write protection") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon May 23 18:02:05 2022 +0400 mtd: maps: Fix refcount leak in of_flash_probe_versatile [ Upstream commit 33ec82a6d2b119938f26e5c8040ed5d92378eb54 ] of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: b0afd44bc192 ("mtd: physmap_of: add a hook for Versatile write protection") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 11:07:23 2022 +0400 mtd: parsers: ofpart: Fix refcount leak in bcm4908_partitions_fw_offset [ Upstream commit e607879b0da18c451de5e91daf239cc2f2f8ff2d ] of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: bb17230c61a6 ("mtd: parsers: ofpart: support BCM4908 fixed partitions") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu May 26 15:06:49 2022 +0400 mtd: partitions: Fix refcount leak in parse_redboot_of [ Upstream commit 9f7e62815cf3cbbcb1b8cb21649fb4dfdb3aa016 ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 237960880960 ("mtd: partitions: redboot: seek fis-index-block in the right node") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kitaina <[email protected]> Date: Tue Jun 28 21:18:24 2022 +0530 mtd: rawnand: arasan: Fix clock rate in NV-DDR commit e16eceea863b417fd328588b1be1a79de0bc937f upstream. According to the Arasan NAND controller spec, the flash clock rate for SDR must be <= 100 MHz, while for NV-DDR it must be the same as the rate of the CLK line for the mode. The driver previously always set 100 MHz for NV-DDR, which would result in incorrect behavior for NV-DDR modes 0-4. The appropriate clock rate can be calculated from the NV-DDR timing parameters as 1/tCK, or for rates measured in picoseconds, 10^12 / nand_nvddr_timings->tCK_min. Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller") CC: [email protected] # 5.8+ Signed-off-by: Olga Kitaina <[email protected]> Signed-off-by: Amit Kumar Mahapatra <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Amit Kumar Mahapatra <[email protected]> Date: Tue Jun 28 21:18:23 2022 +0530 mtd: rawnand: arasan: Update NAND bus clock instead of system clock commit 7499bfeedb47efc1ee4dc793b92c610d46e6d6a6 upstream. In current implementation the Arasan NAND driver is updating the system clock(i.e., anand->clk) in accordance to the timing modes (i.e., SDR or NVDDR). But as per the Arasan NAND controller spec the flash clock or the NAND bus clock(i.e., nfc->bus_clk), need to be updated instead. This patch keeps the system clock unchanged and updates the NAND bus clock as per the timing modes. Fixes: 197b88fecc50 ("mtd: rawnand: arasan: Add new Arasan NAND controller") CC: [email protected] # 5.8+ Signed-off-by: Amit Kumar Mahapatra <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Fri May 20 18:41:40 2022 +0200 mtd: rawnand: meson: Fix a potential double free issue [ Upstream commit ec0da06337751b18f6dee06b6526e0f0d6e80369 ] When meson_nfc_nand_chip_cleanup() is called, it will call: meson_nfc_free_buffer(&meson_chip->nand); nand_cleanup(&meson_chip->nand); nand_cleanup() in turn will call nand_detach() which calls the .detach_chip() which is here meson_nand_detach_chip(). meson_nand_detach_chip() already calls meson_nfc_free_buffer(), so we could double free some memory. Fix it by removing the unneeded explicit call to meson_nfc_free_buffer(). Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Liang Yang <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/ec15c358b8063f7c50ff4cd628cf0d2e14e43f49.1653064877.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Tue May 24 12:48:41 2022 +0800 mtd: sm_ftl: Fix deadlock caused by cancel_work_sync in sm_release [ Upstream commit a61528d997619a518ee8c51cf0ef0513021afaff ] There is a deadlock between sm_release and sm_cache_flush_work which is a work item. The cancel_work_sync in sm_release will not return until sm_cache_flush_work is finished. If we hold mutex_lock and use cancel_work_sync to wait the work item to finish, the work item also requires mutex_lock. As a result, the sm_release will be blocked forever. The race condition is shown below: (Thread 1) | (Thread 2) sm_release | mutex_lock(&ftl->mutex) | sm_cache_flush_work | mutex_lock(&ftl->mutex) cancel_work_sync | ... This patch moves del_timer_sync and cancel_work_sync out of mutex_lock in order to mitigate deadlock. Fixes: 7d17c02a01a1 ("mtd: Add new SmartMedia/xD FTL") Signed-off-by: Duoming Zhou <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Patrice Chotard <[email protected]> Date: Wed Jun 29 15:30:13 2022 +0200 mtd: spi-nor: fix spi_nor_spimem_setup_op() call in spi_nor_erase_{sector,chip}() [ Upstream commit f8cd9f632f4415b1e8838bdca8ab42cfb37a6584 ] For erase operations, reg_proto must be used as indicated in struct spi_nor description in spi-nor.h. This issue was found when DT property spi-tx-bus-width is set to 4. In this case the spi_mem_op->addr.buswidth is set to 4 for erase command which is not correct. Tested on stm32mp157c-ev1 board with mx66l51235f spi-nor. Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Patrice Chotard <[email protected]> [ta: use nor->reg_proto in spi_nor_controller_ops_erase()] Signed-off-by: Tudor Ambarus <[email protected]> Tested-by: Alexander Sverdlin <[email protected]> Reviewed-by: Pratyush Yadav <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Tue Jun 7 17:24:55 2022 +0200 mtd: st_spi_fsm: Add a clk_disable_unprepare() in .probe()'s error path [ Upstream commit 28607b426c3d050714f250d0faeb99d2e9106e90 ] For all but one error path clk_disable_unprepare() is already there. Add it to the one location where it's missing. Fixes: 481815a6193b ("mtd: st_spi_fsm: Handle clk_prepare_enable/clk_disable_unprepare.") Fixes: 69d5af8d016c ("mtd: st_spi_fsm: Obtain and use EMI clock") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Tue Jun 7 11:26:26 2022 +0800 mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv [ Upstream commit a52ed4866d2b90dd5e4ae9dabd453f3ed8fa3cbc ] There are sleep in atomic context bugs when uploading device dump data in mwifiex. The root cause is that dev_coredumpv could not be used in atomic contexts, because it calls dev_set_name which include operations that may sleep. The call tree shows execution paths that could lead to bugs: (Interrupt context) fw_dump_timer_fn mwifiex_upload_device_dump dev_coredumpv(..., GFP_KERNEL) dev_coredumpm() kzalloc(sizeof(*devcd), gfp); //may sleep dev_set_name kobject_set_name_vargs kvasprintf_const(GFP_KERNEL, ...); //may sleep kstrdup(s, GFP_KERNEL); //may sleep The corresponding fail log is shown below: [ 135.275938] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start [ 135.281029] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265 ... [ 135.293613] Call Trace: [ 135.293613] <IRQ> [ 135.293613] dump_stack_lvl+0x57/0x7d [ 135.293613] __might_resched.cold+0x138/0x173 [ 135.293613] ? dev_coredumpm+0xca/0x2e0 [ 135.293613] kmem_cache_alloc_trace+0x189/0x1f0 [ 135.293613] ? devcd_match_failing+0x30/0x30 [ 135.293613] dev_coredumpm+0xca/0x2e0 [ 135.293613] ? devcd_freev+0x10/0x10 [ 135.293613] dev_coredumpv+0x1c/0x20 [ 135.293613] ? devcd_match_failing+0x30/0x30 [ 135.293613] mwifiex_upload_device_dump+0x65/0xb0 [ 135.293613] ? mwifiex_dnld_fw+0x1b0/0x1b0 [ 135.293613] call_timer_fn+0x122/0x3d0 [ 135.293613] ? msleep_interruptible+0xb0/0xb0 [ 135.293613] ? lock_downgrade+0x3c0/0x3c0 [ 135.293613] ? __next_timer_interrupt+0x13c/0x160 [ 135.293613] ? lockdep_hardirqs_on_prepare+0xe/0x220 [ 135.293613] ? mwifiex_dnld_fw+0x1b0/0x1b0 [ 135.293613] __run_timers.part.0+0x3f8/0x540 [ 135.293613] ? call_timer_fn+0x3d0/0x3d0 [ 135.293613] ? arch_restore_msi_irqs+0x10/0x10 [ 135.293613] ? lapic_next_event+0x31/0x40 [ 135.293613] run_timer_softirq+0x4f/0xb0 [ 135.293613] __do_softirq+0x1c2/0x651 ... [ 135.293613] RIP: 0010:default_idle+0xb/0x10 [ 135.293613] RSP: 0018:ffff888006317e68 EFLAGS: 00000246 [ 135.293613] RAX: ffffffff82ad8d10 RBX: ffff888006301cc0 RCX: ffffffff82ac90e1 [ 135.293613] RDX: ffffed100d9ff1b4 RSI: ffffffff831ad140 RDI: ffffffff82ad8f20 [ 135.293613] RBP: 0000000000000003 R08: 0000000000000000 R09: ffff88806cff8d9b [ 135.293613] R10: ffffed100d9ff1b3 R11: 0000000000000001 R12: ffffffff84593410 [ 135.293613] R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff11000c62fd2 ... [ 135.389205] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end This patch uses delayed work to replace timer and moves the operations that may sleep into a delayed work in order to mitigate bugs, it was tested on Marvell 88W8801 chip whose port is usb and the firmware is usb8801_uapsta.bin. The following is the result after using delayed work to replace timer. [ 134.936453] usb 1-1: == mwifiex dump information to /sys/class/devcoredump start [ 135.043344] usb 1-1: == mwifiex dump information to /sys/class/devcoredump end As we can see, there is no bug now. Fixes: f5ecd02a8b20 ("mwifiex: device dump support for usb interface") Reviewed-by: Brian Norris <[email protected]> Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/b63b77fc84ed3e8a6bef02378e17c7c71a0bc3be.1654569290.git.duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Dreßler <[email protected]> Date: Wed Nov 3 21:58:27 2021 +0100 mwifiex: Ignore BTCOEX events from the 88W8897 firmware [ Upstream commit 84d94e16efa268e4f2887d858cd67ee37b870f25 ] The firmware of the 88W8897 PCIe+USB card sends those events very unreliably, sometimes bluetooth together with 2.4ghz-wifi is used and no COEX event comes in, and sometimes bluetooth is disabled but the coexistance mode doesn't get disabled. This means we sometimes end up capping the rx/tx window size while bluetooth is not enabled anymore, artifically limiting wifi speeds even though bluetooth is not being used. Since we can't fix the firmware, let's just ignore those events on the 88W8897 device. From some Wireshark capture sessions it seems that the Windows driver also doesn't change the rx/tx window sizes when bluetooth gets enabled or disabled, so this is fairly consistent with the Windows driver. Signed-off-by: Jonas Dreßler <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tyler Hicks <[email protected]> Date: Sun Jul 10 09:14:02 2022 -0500 net/9p: Initialize the iounit field during fid creation [ Upstream commit aa7aeee169480e98cf41d83c01290a37e569be6d ] Ensure that the fid's iounit field is set to zero when a new fid is created. Certain 9P operations, such as OPEN and CREATE, allow the server to reply with an iounit size which the client code assigns to the p9_fid struct shortly after the fid is created by p9_fid_create(). On the other hand, an XATTRWALK operation doesn't allow for the server to specify an iounit value. The iounit field of the newly allocated p9_fid struct remained uninitialized in that case. Depending on allocation patterns, the iounit value could have been something reasonable that was carried over from previously freed fids or, in the worst case, could have been arbitrary values from non-fid related usages of the memory location. The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel after the uninitialized iounit field resulted in the typical sequence of two getxattr(2) syscalls, one to get the size of an xattr and another after allocating a sufficiently sized buffer to fit the xattr value, to hit an unexpected ERANGE error in the second call to getxattr(2). An uninitialized iounit field would sometimes force rsize to be smaller than the xattr value size in p9_client_read_once() and the 9P server in WSL refused to chunk up the READ on the attr_fid and, instead, returned ERANGE to the client. The virtfs server in QEMU seems happy to chunk up the READ and this problem goes undetected there. Link: https://lkml.kernel.org/r/[email protected] Fixes: ebf46264a004 ("fs/9p: Add support user. xattr") Cc: [email protected] Signed-off-by: Tyler Hicks <[email protected]> Reviewed-by: Christian Schoenebeck <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maher Sanalla <[email protected]> Date: Sun Jul 24 11:28:21 2022 +0300 net/mlx5: Adjust log_max_qp to be 18 at most [ Upstream commit a6e9085d791f8306084fd5bc44dd3fdd4e1ac27b ] The cited commit limited log_max_qp to be 17 due to FW capabilities. Recently, it turned out that there are old FW versions that supported more than 17, so the cited commit caused a degradation. Thus, set the maximum log_max_qp back to 18 as it was before the cited commit. Fixes: 7f839965b2d7 ("net/mlx5: Update log_max_qp value to be 17 at most") Signed-off-by: Maher Sanalla <[email protected]> Reviewed-by: Maor Gottlieb <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maxim Mikityanskiy <[email protected]> Date: Thu May 26 16:48:47 2022 +0300 net/mlx5e: Fix the value of MLX5E_MAX_RQ_NUM_MTTS [ Upstream commit 562696c3c62c7c23dd896e9447252ce9268cb812 ] MLX5E_MAX_RQ_NUM_MTTS should be the maximum value, so that MLX5_MTT_OCTW(MLX5E_MAX_RQ_NUM_MTTS) fits into u16. The current value of 1 << 17 results in MLX5_MTT_OCTW(1 << 17) = 1 << 16, which doesn't fit into u16. This commit replaces it with the maximum value that still fits u16. Fixes: 73281b78a37a ("net/mlx5e: Derive Striding RQ size from MTU") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gal Pressman <[email protected]> Date: Wed Jul 13 13:57:03 2022 +0300 net/mlx5e: Remove WARN_ON when trying to offload an unsupported TLS cipher/version [ Upstream commit 115d9f95ea7ab780ef315dc356bebba2e07cb731 ] The driver reports whether TX/RX TLS device offloads are supported, but not which ciphers/versions, these should be handled by returning -EOPNOTSUPP when .tls_dev_add() is called. Remove the WARN_ON kernel trace when the driver gets a request to offload a cipher/version that is not supported as it is expected. Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support") Signed-off-by: Gal Pressman <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Reviewed-by: Maxim Mikityanskiy <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangyu Hua <[email protected]> Date: Wed Jul 13 09:55:11 2022 +0900 net: 9p: fix refcount leak in p9_read_work() error handling [ Upstream commit 4ac7573e1f9333073fa8d303acc941c9b7ab7f61 ] p9_req_put need to be called when m->rreq->rc.sdata is NULL to avoid temporary refcount leak. Link: https://lkml.kernel.org/r/[email protected] Fixes: 728356dedeff ("9p: Add refcount to p9_req_t") Signed-off-by: Hangyu Hua <[email protected]> [Dominique: commit wording adjustments, p9_req_put argument fixes for rebase] Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Manning <[email protected]> Date: Mon Jul 25 19:14:42 2022 +0100 net: allow unbound socket for packets in VRF when tcp_l3mdev_accept set [ Upstream commit 944fd1aeacb627fa617f85f8e5a34f7ae8ea4d8e ] The commit 3c82a21f4320 ("net: allow binding socket in a VRF when there's an unbound socket") changed the inet socket lookup to avoid packets in a VRF from matching an unbound socket. This is to ensure the necessary isolation between the default and other VRFs for routing and forwarding. VRF-unaware processes running in the default VRF cannot access another VRF and have to be run with 'ip vrf exec <vrf>'. This is to be expected with tcp_l3mdev_accept disabled, but could be reallowed when this sysctl option is enabled. So instead of directly checking dif and sdif in inet[6]_match, here call inet_sk_bound_dev_eq(). This allows a match on unbound socket for non-zero sdif i.e. for packets in a VRF, if tcp_l3mdev_accept is enabled. Fixes: 3c82a21f4320 ("net: allow binding socket in a VRF when there's an unbound socket") Signed-off-by: Mike Manning <[email protected]> Link: https://lore.kernel.org/netdev/[email protected]/ Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Jun 8 23:34:10 2022 -0700 net: fix sk_wmem_schedule() and sk_rmem_schedule() errors [ Upstream commit 7c80b038d23e1f4c7fcc311f43f83b8c60e7fb80 ] If sk->sk_forward_alloc is 150000, and we need to schedule 150001 bytes, we want to allocate 1 byte more (rounded up to one page), instead of 150001 :/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qiao Ma <[email protected]> Date: Tue Jul 5 19:22:23 2022 +0800 net: hinic: avoid kernel hung in hinic_get_stats64() [ Upstream commit 98f9fcdee35add80505b6c73f72de5f750d5c03c ] When using hinic device as a bond slave device, and reading device stats of master bond device, the kernel may hung. The kernel panic calltrace as follows: Kernel panic - not syncing: softlockup: hung tasks Call trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180 And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324 When getting device stats from bond, kernel will call bond_get_stats(). It first holds the spinlock bond->stats_lock, and then call hinic_get_stats64() to collect hinic device's stats. However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to protect its critical section, which may schedule current task out. And if system is under high pressure, the task cannot be woken up immediately, which eventually triggers kernel hung panic. Since previous patch has replaced hinic_dev.tx_stats/rx_stats with local variable in hinic_get_stats64(), there is nothing need to be protected by lock, so just removing down()/up() is ok. Fixes: edd384f682cc ("net-next/hinic: Add ethtool and stats") Signed-off-by: Qiao Ma <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Qiao Ma <[email protected]> Date: Tue Jul 5 19:22:22 2022 +0800 net: hinic: fix bug that ethtool get wrong stats [ Upstream commit 67dffd3db98570af8ff54c934f7d14664c0d182a ] Function hinic_get_stats64() will do two operations: 1. reads stats from every hinic_rxq/txq and accumulates them 2. calls hinic_rxq/txq_clean_stats() to clean every rxq/txq's stats For hinic_get_stats64(), it could get right data, because it sums all data to nic_dev->rx_stats/tx_stats. But it is wrong for get_drv_queue_stats(), this function will read hinic_rxq's stats, which have been cleared to zero by hinic_get_stats64(). I have observed hinic's cleanup operation by using such command: > watch -n 1 "cat ethtool -S eth4 | tail -40" Result before: ... rxq7_pkts: 1 rxq7_bytes: 90 rxq7_errors: 0 rxq7_csum_errors: 0 rxq7_other_errors: 0 ... rxq9_pkts: 11 rxq9_bytes: 726 rxq9_errors: 0 rxq9_csum_errors: 0 rxq9_other_errors: 0 ... rxq11_pkts: 0 rxq11_bytes: 0 rxq11_errors: 0 rxq11_csum_errors: 0 rxq11_other_errors: 0 Result after a few seconds: ... rxq7_pkts: 0 rxq7_bytes: 0 rxq7_errors: 0 rxq7_csum_errors: 0 rxq7_other_errors: 0 ... rxq9_pkts: 2 rxq9_bytes: 132 rxq9_errors: 0 rxq9_csum_errors: 0 rxq9_other_errors: 0 ... rxq11_pkts: 1 rxq11_bytes: 170 rxq11_errors: 0 rxq11_csum_errors: 0 rxq11_other_errors: 0 To solve this problem, we just keep every queue's total stats in their own queue (aka hinic_{rxq|txq}), and simply sum all per-queue stats every time calling hinic_get_stats64(). With that solution, there is no need to clean per-queue stats now, and there is no need to maintain global hinic_dev.{tx|rx}_stats, too. Fixes: edd384f682cc ("net-next/hinic: Add ethtool and stats") Signed-off-by: Qiao Ma <[email protected]> Reported-by: kernel test robot <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Shen <[email protected]> Date: Fri Jul 29 18:17:55 2022 +0800 net: ionic: fix error check for vlan flags in ionic_set_nic_features() [ Upstream commit a86e86db5e6d72c82724a63ca1c5293409a21518 ] The prototype of input features of ionic_set_nic_features() is netdev_features_t, but the vlan_flags is using the private definition of ionic drivers. It should use the variable ctx.cmd.lif_setattr.features, rather than features to check the vlan flags. So fixes it. Fixes: beead698b173 ("ionic: Add the basic NDO callbacks for netdev support") Signed-off-by: Jian Shen <[email protected]> Signed-off-by: Guangbin Huang <[email protected]> Acked-by: Shannon Nelson <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Mon Jun 20 13:04:50 2022 +0200 net: phy: smsc: Disable Energy Detect Power-Down in interrupt mode commit 2642cc6c3bbe0900ba15bab078fd15ad8baccbc5 upstream. Simon reports that if two LAN9514 USB adapters are directly connected without an intermediate switch, the link fails to come up and link LEDs remain dark. The issue was introduced by commit 1ce8b37241ed ("usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling"). The PHY suffers from a known erratum wherein link detection becomes unreliable if Energy Detect Power-Down is used. In poll mode, the driver works around the erratum by briefly disabling EDPD for 640 msec to detect a neighbor, then re-enabling it to save power. In interrupt mode, no interrupt is signaled if EDPD is used by both link partners, so it must not be enabled at all. We'll recoup the power savings by enabling SUSPEND1 mode on affected LAN95xx chips in a forthcoming commit. Fixes: 1ce8b37241ed ("usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling") Reported-by: Simon Han <[email protected]> Signed-off-by: Lukas Wunner <[email protected]> Link: https://lore.kernel.org/r/439a3f3168c2f9d44b5fd9bb8d2b551711316be6.1655714438.git.lukas@wunner.de Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Fri Jul 29 09:12:32 2022 +0000 net: rose: fix netdev reference changes [ Upstream commit 931027820e4dafabc78aff82af59f8c1c4bd3128 ] Bernard reported that trying to unload rose module would lead to infamous messages: unregistered_netdevice: waiting for rose0 to become free. Usage count = xx This patch solves the issue, by making sure each socket referring to a netdevice holds a reference count on it, and properly releases it in rose_release(). rose_dev_first() is also fixed to take a device reference before leaving the rcu_read_locked section. Following patch will add ref_tracker annotations to ease future bug hunting. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Bernard Pidoux <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Tested-by: Bernard Pidoux <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej Żenczykowski <[email protected]> Date: Sat Jul 30 16:01:13 2022 -0700 net: usb: make USB_RTL8153_ECM non user configurable [ Upstream commit f56530dcdb0684406661ac9f1accf48319d07600 ] This refixes: commit 7da17624e7948d5d9660b910f8079d26d26ce453 nt: usb: USB_RTL8153_ECM should not default to y In general, device drivers should not be enabled by default. which basically broke the commit it claimed to fix, ie: commit 657bc1d10bfc23ac06d5d687ce45826c760744f9 r8153_ecm: avoid to be prior to r8152 driver Avoid r8153_ecm is compiled as built-in, if r8152 driver is compiled as modules. Otherwise, the r8153_ecm would be used, even though the device is supported by r8152 driver. this commit amounted to: drivers/net/usb/Kconfig: +config USB_RTL8153_ECM + tristate "RTL8153 ECM support" + depends on USB_NET_CDCETHER && (USB_RTL8152 || USB_RTL8152=n) + default y + help + This option supports ECM mode for RTL8153 ethernet adapter, when + CONFIG_USB_RTL8152 is not set, or the RTL8153 device is not + supported by r8152 driver. drivers/net/usb/Makefile: -obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o r8153_ecm.o +obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o +obj-$(CONFIG_USB_RTL8153_ECM) += r8153_ecm.o And as can be seen it pulls a piece of the cdc_ether driver out into a separate config option to be able to make this piece modular in case cdc_ether is builtin, while r8152 is modular. While in general, device drivers should indeed not be enabled by default: this isn't a device driver per say, but rather this is support code for the CDCETHER (ECM) driver, and should thus be enabled if it is enabled. See also email thread at: https://www.spinics.net/lists/netdev/msg767649.html In: https://www.spinics.net/lists/netdev/msg768284.html Jakub wrote: And when we say "removed" we can just hide it from what's prompted to the user (whatever such internal options are called)? I believe this way we don't bring back Marek's complaint. Side note: these incorrect defaults will result in Android 13 on 5.15 GKI kernels lacking USB_RTL8153_ECM support while having USB_NET_CDCETHER (luckily we also have USB_RTL8150 and USB_RTL8152, so it's probably only an issue for very new RTL815x hardware with no native 5.15 driver). Fixes: 7da17624e7948d5d ("nt: usb: USB_RTL8153_ECM should not default to y") Cc: Geert Uytterhoeven <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Hayes Wang <[email protected]> Cc: Jakub Kicinski <[email protected]> Signed-off-by: Maciej Żenczykowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Aug 9 14:05:18 2022 -0300 net_sched: cls_route: remove from list when handle is 0 commit 9ad36309e2719a884f946678e0296be10f0bb4c1 upstream. When a route filter is replaced and the old filter has a 0 handle, the old one won't be removed from the hashtable, while it will still be freed. The test was there since before commit 1109c00547fc ("net: sched: RCU cls_route"), when a new filter was not allocated when there was an old one. The old filter was reused and the reinserting would only be necessary if an old filter was replaced. That was still wrong for the same case where the old handle was 0. Remove the old filter from the list independently from its handle value. This fixes CVE-2022-2588, also reported as ZDI-CAN-17440. Reported-by: Zhenpeng Lin <[email protected]> Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Reviewed-by: Kamal Mostafa <[email protected]> Cc: <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jakub Kicinski <[email protected]> Date: Tue Jul 26 14:36:05 2022 -0700 netdevsim: Avoid allocation warnings triggered from user space [ Upstream commit d0b80a9edb1a029ff913e81b47540e57ad034329 ] We need to suppress warnings from sily map sizes. Also switch from GFP_USER to GFP_KERNEL_ACCOUNT, I'm pretty sure I misunderstood the flags when writing this code. Fixes: 395cacb5f1a0 ("netdevsim: bpf: support fake map offload") Reported-by: [email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ido Schimmel <[email protected]> Date: Thu Jul 28 14:45:33 2022 +0300 netdevsim: fib: Fix reference count leak on route deletion failure [ Upstream commit 180a6a3ee60a7cb69ed1232388460644f6a21f00 ] As part of FIB offload simulation, netdevsim stores IPv4 and IPv6 routes and holds a reference on FIB info structures that in turn hold a reference on the associated nexthop device(s). In the unlikely case where we are unable to allocate memory to process a route deletion request, netdevsim will not release the reference from the associated FIB info structure, thereby preventing the associated nexthop device(s) from ever being removed [1]. Fix this by scheduling a work item that will flush netdevsim's FIB table upon route deletion failure. This will cause netdevsim to release its reference from all the FIB info structures in its table. Reported by Lucas Leong of Trend Micro Zero Day Initiative. Fixes: 0ae3eb7b4611 ("netdevsim: fib: Perform the route programming in a non-atomic context") Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Amit Cohen <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Aug 9 14:01:47 2022 -0300 netfilter: nf_tables: do not allow CHAIN_ID to refer to another table commit 95f466d22364a33d183509629d0879885b4f547e upstream. When doing lookups for chains on the same batch by using its ID, a chain from a different table can be used. If a rule is added to a table but refers to a chain in a different table, it will be linked to the chain in table2, but would have expressions referring to objects in table1. Then, when table1 is removed, the rule will not be removed as its linked to a chain in table2. When expressions in the rule are processed or removed, that will lead to a use-after-free. When looking for chains by ID, use the table that was used for the lookup by name, and only return chains belonging to that same table. Fixes: 837830a4b439 ("netfilter: nf_tables: add NFTA_RULE_CHAIN_ID attribute") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Cc: <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Aug 9 14:01:48 2022 -0300 netfilter: nf_tables: do not allow RULE_ID to refer to another chain commit 36d5b2913219ac853908b0f1c664345e04313856 upstream. When doing lookups for rules on the same batch by using its ID, a rule from a different chain can be used. If a rule is added to a chain but tries to be positioned next to a rule from a different chain, it will be linked to chain2, but the use counter on chain1 would be the one to be incremented. When looking for rules by ID, use the chain that was used for the lookup by name. The chain used in the context copied to the transaction needs to match that same chain. That way, struct nft_rule does not need to get enlarged with another member. Fixes: 1a94e38d254b ("netfilter: nf_tables: add NFTA_RULE_ID attribute") Fixes: 75dd48e2e420 ("netfilter: nf_tables: Support RULE_ID reference in new rule") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Cc: <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Aug 9 14:01:46 2022 -0300 netfilter: nf_tables: do not allow SET_ID to refer to another table commit 470ee20e069a6d05ae549f7d0ef2bdbcee6a81b2 upstream. When doing lookups for sets on the same batch by using its ID, a set from a different table can be used. Then, when the table is removed, a reference to the set may be kept after the set is freed, leading to a potential use-after-free. When looking for sets by ID, use the table that was used for the lookup by name, and only return sets belonging to that same table. This fixes CVE-2022-2586, also reported as ZDI-CAN-17470. Reported-by: Team Orca of Sea Security (@seasecresponse) Fixes: 958bee14d071 ("netfilter: nf_tables: use new transaction infrastructure to handle sets") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Cc: <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Florian Westphal <[email protected]> Date: Tue Aug 9 18:34:02 2022 +0200 netfilter: nf_tables: fix null deref due to zeroed list head commit 580077855a40741cf511766129702d97ff02f4d9 upstream. In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the transaction object. nft_trans_destroy() calls list_del(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a null dereference: BUG: KASAN: null-ptr-deref in nft_trans_destroy+0x26/0x59 Call Trace: nft_trans_destroy+0x26/0x59 nf_tables_newtable+0x4bc/0x9bc [..] Its sane to assume that nft_trans_destroy() can be called on the transaction object returned by nft_trans_alloc(), so make sure the list head is initialised. Fixes: 55dd6f93076b ("netfilter: nf_tables: use new transaction infrastructure to handle table") Reported-by: mingi cho <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Gleixner <[email protected]> Date: Mon Jun 6 17:23:45 2022 +0200 netfilter: xtables: Bring SPDX identifier back [ Upstream commit 20646f5b1e798bcc20044ae90ac3702f177bf254 ] Commit e2be04c7f995 ("License cleanup: add SPDX license identifier to uapi header files with a license") added the correct SPDX identifier to include/uapi/linux/netfilter/xt_IDLETIMER.h. A subsequent commit removed it for no reason and reintroduced the UAPI license incorrectness as the file is now missing the UAPI exception again. Add it back and remove the GPLv2 boilerplate while at it. Fixes: 68983a354a65 ("netfilter: xtables: Add snapshot of hardidletimer target") Cc: Manoj Basapathi <[email protected]> Cc: Subash Abhinov Kasiviswanathan <[email protected]> Cc: Pablo Neira Ayuso <[email protected]> Cc: [email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Sun Mar 27 16:43:03 2022 -0400 NFSD: Clean up the show_nf_flags() macro commit bb283ca18d1e67c82d22a329c96c9d6036a74790 upstream. The flags are defined using C macros, so TRACE_DEFINE_ENUM is unnecessary. Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeff Layton <[email protected]> Date: Fri Jul 29 17:01:07 2022 -0400 nfsd: eliminate the NFSD_FILE_BREAK_* flags commit 23ba98de6dcec665e15c0ca19244379bb0d30932 upstream. We had a report from the spring Bake-a-thon of data corruption in some nfstest_interop tests. Looking at the traces showed the NFS server allowing a v3 WRITE to proceed while a read delegation was still outstanding. Currently, we only set NFSD_FILE_BREAK_* flags if NFSD_MAY_NOT_BREAK_LEASE was set when we call nfsd_file_alloc. NFSD_MAY_NOT_BREAK_LEASE was intended to be set when finding files for COMMIT ops, where we need a writeable filehandle but don't need to break read leases. It doesn't make any sense to consult that flag when allocating a file since the file may be used on subsequent calls where we do want to break the lease (and the usage of it here seems to be reverse from what it should be anyway). Also, after calling nfsd_open_break_lease, we don't want to clear the BREAK_* bits. A lease could end up being set on it later (more than once) and we need to be able to break those leases as well. This means that the NFSD_FILE_BREAK_* flags now just mirror NFSD_MAY_{READ,WRITE} flags, so there's no need for them at all. Just drop those flags and unconditionally call nfsd_open_break_lease every time. Reported-by: Olga Kornieskaia <[email protected]> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2107360 Fixes: 65294c1f2c5e (nfsd: add a new struct file caching facility to nfsd) Cc: <[email protected]> # 5.4.x : bb283ca18d1e NFSD: Clean up the show_nf_flags() macro Cc: <[email protected]> # 5.4.x Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nicolas Saenz Julienne <[email protected]> Date: Tue Jun 28 11:22:59 2022 +0200 nohz/full, sched/rt: Fix missed tick-reenabling bug in dequeue_task_rt() [ Upstream commit 5c66d1b9b30f737fcef85a0b75bfe0590e16b62a ] dequeue_task_rt() only decrements 'rt_rq->rt_nr_running' after having called sched_update_tick_dependency() preventing it from re-enabling the tick on systems that no longer have pending SCHED_RT tasks but have multiple runnable SCHED_OTHER tasks: dequeue_task_rt() dequeue_rt_entity() dequeue_rt_stack() dequeue_top_rt_rq() sub_nr_running() // decrements rq->nr_running sched_update_tick_dependency() sched_can_stop_tick() // checks rq->rt.rt_nr_running, ... __dequeue_rt_entity() dec_rt_tasks() // decrements rq->rt.rt_nr_running ... Every other scheduler class performs the operation in the opposite order, and sched_update_tick_dependency() expects the values to be updated as such. So avoid the misbehaviour by inverting the order in which the above operations are performed in the RT scheduler. Fixes: 76d92ac305f2 ("sched: Migrate sched to use new tick dependency mask model") Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Reviewed-by: Phil Auld <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jul 15 11:12:14 2022 +0300 null_blk: fix ida error handling in null_add_dev() [ Upstream commit ee452a8d984f94fa8e894f003a52e776e4572881 ] There needs to be some error checking if ida_simple_get() fails. Also call ida_free() if there are errors later. Fixes: 94bc02e30fb8 ("nullb: use ida to manage index") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/YtEhXsr6vJeoiYhd@kili Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Thu Jul 21 07:56:35 2022 +0200 nvme: catch -ENODEV from nvme_revalidate_zones again [ Upstream commit e06b425bc835ead08b9fd935bf5e47eef473e7a0 ] nvme_revalidate_zones can also return -ENODEV if e.g. zone sizes aren't constant or not a power of two. In that case we should jump to marking the gendisk hidden and only support pass through. Fixes: 602e57c9799c ("nvme: also mark passthrough-only namespaces ready in nvme_update_ns_info") Reported-by: Joel Granados <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Joel Granados <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nick Bowler <[email protected]> Date: Wed Jul 20 23:57:35 2022 -0400 nvme: define compat_ioctl again to unbreak 32-bit userspace. [ Upstream commit a25d4261582cf00dad884c194d21084836663d3d ] Commit 89b3d6e60550 ("nvme: simplify the compat ioctl handling") removed the initialization of compat_ioctl from the nvme block_device_operations structures. Presumably the expectation was that 32-bit ioctls would be directed through the regular handler but this is not the case: failing to assign .compat_ioctl actually means that the compat case is disabled entirely, and any attempt to submit nvme ioctls from 32-bit userspace fails outright with -ENOTTY. For example: % smartctl -x /dev/nvme0n1 [...] Read NVMe Identify Controller failed: NVME_IOCTL_ADMIN_CMD: Inappropriate ioctl for device The blkdev_compat_ptr_ioctl helper can be used to direct compat calls through the main ioctl handler and makes things work again. Fixes: 89b3d6e60550 ("nvme: simplify the compat ioctl handling") Signed-off-by: Nick Bowler <[email protected]> Reviewed-by: Guixin Liu <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Keith Busch <[email protected]> Date: Tue Nov 30 08:14:54 2021 -0800 nvme: disable namespace access for unsupported metadata [ Upstream commit d39ad2a45c0e38def3e0c95f5b90d9af4274c939 ] The only fabrics target that supports metadata handling through the separate integrity buffer is RDMA. It is currently usable only if the size is 8B per block and formatted for protection information. If an rdma target were to export a namespace with a different format (ex: 4k+64B), the driver will not be able to submit valid read/write commands for that namespace. Suppress setting the metadata feature in the namespace so that the gendisk capacity will be set to 0. This will prevent read/write access through the block stack, but will continue to allow ioctl passthrough commands. Cc: Max Gurtovoy <[email protected]> Cc: Sagi Grimberg <[email protected]> Signed-off-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Wed Feb 16 15:07:15 2022 +0100 nvme: don't return an error from nvme_configure_metadata [ Upstream commit 363f6368603743072e5f318c668c632bccb097a3 ] When a fabrics controller claims to support an invalidate metadata configuration we already warn and disable metadata support. No need to also return an error during revalidation. Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Daniel Wagner <[email protected]> Tested-by: Kanchan Joshi <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bean Huo <[email protected]> Date: Fri Jul 15 23:27:21 2022 +0200 nvme: use command_id instead of req->tag in trace_nvme_complete_rq() [ Upstream commit 679c54f2de672b7d79d02f8c4ad483ff6dd8ce2e ] Use command_id instead of req->tag in trace_nvme_complete_rq(), because of commit e7006de6c238 ("nvme: code command_id with a genctr for use authentication after release"), cmd->common.command_id is set to ((genctl & 0xf)< 12 | req->tag), no longer req->tag, which makes cid in trace_nvme_complete_rq and trace_nvme_setup_cmd are not the same. Fixes: e7006de6c238 ("nvme: code command_id with a genctr for use authentication after release") Signed-off-by: Bean Huo <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Qiang <[email protected]> Date: Mon Aug 1 12:05:06 2022 +0000 of/fdt: declared return type does not match actual return type [ Upstream commit 7913145afa51bbed9eaf8e5b4ee55fa9884a71e5 ] The commit 649cab56de8e (“of: properly check for error returned by fdt_get_name()â€) changed the return value type from bool to int, but forgot to change the return value simultaneously. populate_node was only called in unflatten_dt_nodes, and returns with values greater than or equal to 0 were discarded without further processing. Considering that return 0 usually indicates success, return 0 instead of return true. Fixes: 649cab56de8e (“of: properly check for error returned by fdt_get_name()â€) Signed-off-by: Xu Qiang <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Vaibhav Jain <[email protected]> Date: Tue May 31 09:44:46 2022 +0530 of: check previous kernel's ima-kexec-buffer against memory bounds [ Upstream commit cbf9c4b9617b6767886a913705ca14b7600c77db ] Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below: $ sudo kexec --initrd initrd vmlinux --append='mem=16G' <snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]--- Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with page_is_ram() to ensure correct memory bounds. Fixes: 467d27824920 ("powerpc: ima: get the kexec buffer passed by the previous kernel") Cc: Frank Rowand <[email protected]> Cc: Prakhar Srivastava <[email protected]> Cc: Lakshmi Ramasubramanian <[email protected]> Cc: Thiago Jung Bauermann <[email protected]> Cc: Rob Herring <[email protected]> Cc: Ritesh Harjani <[email protected]> Cc: Robin Murphy <[email protected]> Signed-off-by: Vaibhav Jain <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Sat Jul 2 09:44:49 2022 +0800 of: device: Fix missing of_node_put() in of_dma_set_restricted_buffer [ Upstream commit d17e37c41b7ed38459957a5d2968ba61516fd5c2 ] We should use of_node_put() for the reference 'node' returned by of_parse_phandle() which will increase the refcount. Fixes: fec9b625095f ("of: Add plumbing for restricted DMA pool") Co-authored-by: Miaoqian Lin <[email protected]> Signed-off-by: Liang He <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tang Bin <[email protected]> Date: Tue May 24 20:31:51 2022 +0800 opp: Fix error check in dev_pm_opp_attach_genpd() [ Upstream commit 4ea9496cbc959eb5c78f3e379199aca9ef4e386b ] dev_pm_domain_attach_by_name() may return NULL in some cases, so IS_ERR() doesn't meet the requirements. Thus fix it. Fixes: 6319aee10e53 ("opp: Attach genpds to devices from within OPP core") Signed-off-by: Tang Bin <[email protected]> [ Viresh: Replace ENODATA with ENODEV ] Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiachen Zhang <[email protected]> Date: Thu Jul 28 19:49:15 2022 +0800 ovl: drop WARN_ON() dentry is NULL in ovl_encode_fh() commit dd524b7f317de8d31d638cbfdc7be4cf9b770e42 upstream. Some code paths cannot guarantee the inode have any dentry alias. So WARN_ON() all !dentry may flood the kernel logs. For example, when an overlayfs inode is watched by inotifywait (1), and someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD, at that time if the dentry has been reclaimed by kernel (such as echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The printed call stack would be like: ? show_mark_fhandle+0xf0/0xf0 show_mark_fhandle+0x4a/0xf0 ? show_mark_fhandle+0xf0/0xf0 ? seq_vprintf+0x30/0x50 ? seq_printf+0x53/0x70 ? show_mark_fhandle+0xf0/0xf0 inotify_fdinfo+0x70/0x90 show_fdinfo.isra.4+0x53/0x70 seq_show+0x130/0x170 seq_read+0x153/0x440 vfs_read+0x94/0x150 ksys_read+0x5f/0xe0 do_syscall_64+0x59/0x1e0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 So let's drop WARN_ON() to avoid kernel log flooding. Reported-by: Hongbo Yin <[email protected]> Signed-off-by: Jiachen Zhang <[email protected]> Signed-off-by: Tianci Zhang <[email protected]> Fixes: 8ed5eec9d6c4 ("ovl: encode pure upper file handles") Cc: <[email protected]> # v4.16 Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Dean <[email protected]> Date: Fri Jul 22 10:57:09 2022 +0800 parisc: Check the return value of ioremap() in lba_driver_probe() commit cf59f34d7f978d14d6520fd80a78a5ad5cb8abf8 upstream. The function ioremap() in lba_driver_probe() can fail, so its return value should be checked. Fixes: 4bdc0d676a643 ("remove ioremap_nocache and devm_ioremap_nocache") Reported-by: Hacash Robot <[email protected]> Signed-off-by: William Dean <[email protected]> Signed-off-by: Helge Deller <[email protected]> Cc: <[email protected]> # v5.6+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Tue Jul 19 06:19:41 2022 +0200 parisc: Drop pa_swapper_pg_lock spinlock commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream. This spinlock was dropped with commit b7795074a046 ("parisc: Optimize per-pagetable spinlocks") in kernel v5.12. Remove it to silence a sparse warning. Signed-off-by: Helge Deller <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: <[email protected]> # v5.12+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Mon Jul 18 17:06:47 2022 +0200 parisc: Fix device names in /proc/iomem commit cab56b51ec0e69128909cef4650e1907248d821b upstream. Fix the output of /proc/iomem to show the real hardware device name including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]". Up to now only the pa_pathname ("[8:16.0]") was shown. Signed-off-by: Helge Deller <[email protected]> Cc: <[email protected]> # v4.9+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Mon Aug 1 17:36:15 2022 +0200 parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream. For all syscalls in 32-bit compat mode on 64-bit kernels the upper 32-bits of the 64-bit registers are zeroed out, so a negative 32-bit signed value will show up as positive 64-bit signed value. This behaviour breaks the io_pgetevents_time64() syscall which expects signed 64-bit values for the "min_nr" and "nr" parameters. Fix this by switching to the compat_sys_io_pgetevents_time64() syscall, which uses "compat_long_t" types for those parameters. Cc: <[email protected]> # v5.1+ Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mohamed Khalfella <[email protected]> Date: Mon May 9 18:14:41 2022 +0000 PCI/AER: Iterate over error counters instead of error strings [ Upstream commit 5e6ae050955b566484f3cc6a66e3925eae87a0ed ] Previously we iterated over AER stat *names*, e.g., aer_correctable_error_string[32], but the actual stat *counters* may not be that large, e.g., pdev->aer_stats->dev_cor_errs[16], which means that we printed junk in the sysfs stats files. Iterate over the stat counter arrays instead of the names to avoid this junk. Also, added a build time check to make sure all counters have entries in strings array. Fixes: 0678e3109a3c ("PCI/AER: Simplify __aer_print_error()") Link: https://lore.kernel.org/r/[email protected] Reported-by: Meeta Saggi <[email protected]> Signed-off-by: Mohamed Khalfella <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Meeta Saggi <[email protected]> Reviewed-by: Eric Badger <[email protected]> Cc: [email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Roese <[email protected]> Date: Tue Jan 25 08:18:19 2022 +0100 PCI/portdrv: Don't disable AER reporting in get_port_device_capability() [ Upstream commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 ] AER reporting is currently disabled in the DevCtl registers of all non Root Port PCIe devices on systems using pcie_ports_native || host->native_aer, disabling AER completely in such systems. This is because 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization"), added a call to pci_disable_pcie_error_reporting() *after* the AER setup was completed for the PCIe device tree. Here a longer analysis about the current status of AER enabling / disabling upon bootup provided by Bjorn: pcie_portdrv_probe pcie_port_device_register get_port_device_capability pci_disable_pcie_error_reporting clear CERE NFERE FERE URRE # <-- disable for RP USP DSP pcie_device_init device_register # new AER service device aer_probe aer_enable_rootport # RP only set_downstream_devices_error_reporting set_device_error_reporting # self (RP) if (RP || USP || DSP) pci_enable_pcie_error_reporting set CERE NFERE FERE URRE # <-- enable for RP pci_walk_bus set_device_error_reporting if (RP || USP || DSP) pci_enable_pcie_error_reporting set CERE NFERE FERE URRE # <-- enable for USP DSP In a typical Root Port -> Endpoint hierarchy, the above: - Disables Error Reporting for the Root Port, - Enables Error Reporting for the Root Port, - Does NOT enable Error Reporting for the Endpoint because it is not a Root Port or Switch Port. In a deeper Root Port -> Upstream Switch Port -> Downstream Switch Port -> Endpoint hierarchy: - Disables Error Reporting for the Root Port, - Enables Error Reporting for the Root Port, - Enables Error Reporting for both Switch Ports, - Does NOT enable Error Reporting for the Endpoint because it is not a Root Port or Switch Port, - Disables Error Reporting for the Switch Ports when pcie_portdrv_probe() claims them. AER does not re-enable it because these are not Root Ports. Remove this call to pci_disable_pcie_error_reporting() from get_port_device_capability(), leaving the already enabled AER configuration intact. With this change, AER is enabled in the Root Port and the PCIe switch upstream and downstream ports. Only the PCIe Endpoints don't have AER enabled yet. A follow-up patch will take care of this Endpoint enabling. Fixes: 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port services during port initialization") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stefan Roese <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Pali Rohár <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Bharat Kumar Gogada <[email protected]> Cc: Michal Simek <[email protected]> Cc: Yao Hongbo <[email protected]> Cc: Naveen Naidu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Mon Feb 14 12:41:08 2022 +0100 PCI: Add defines for normal and subtractive PCI bridges commit 904b10fb189cc15376e9bfce1ef0282e68b0b004 upstream. Add these PCI class codes to pci_ids.h: PCI_CLASS_BRIDGE_PCI_NORMAL PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE Use these defines in all kernel code for describing PCI class codes for normal and subtractive PCI bridges. [bhelgaas: similar change in pci-mvebu.c] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Cc: Guenter Roeck <[email protected]>a Cc: Naresh Kamboju <[email protected]> [ gregkh - take only the pci_ids.h portion for stable backports ] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:12 2022 +0300 PCI: dwc: Add unroll iATU space support to dw_pcie_disable_atu() [ Upstream commit d1cf738f2b65a5640234e1da90a68d3523fbed83 ] dw_pcie_disable_atu() was introduced by f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") and supported only the viewport version of the iATU CSRs. DW PCIe IP cores v4.80a and newer also support unrolled iATU/eDMA space. Callers of dw_pcie_disable_atu(), including pci_epc_ops.clear_bar(), pci_epc_ops.unmap_addr(), and dw_pcie_setup_rc(), don't work correctly when it is enabled. Add dw_pcie_disable_atu() support for controllers with unrolled iATU CSRs enabled. [bhelgaas: commit log] Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:16 2022 +0300 PCI: dwc: Always enable CDM check if "snps,enable-cdm-check" exists [ Upstream commit ec7b952f453ce7eabe7e1bea584626934d44f668 ] If the "snps,enable-cdm-check" property exists, we should enable the CDM check. But previously dw_pcie_setup() could exit before doing so if the "num-lanes" property was absent or invalid. Move the CDM enable earlier so we do it regardless of whether "num-lanes" is present. [bhelgaas: commit log] Fixes: 07f123def73e ("PCI: dwc: Add support to enable CDM register check") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Vidya Sagar <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:15 2022 +0300 PCI: dwc: Deallocate EPC memory on dw_pcie_ep_init() errors [ Upstream commit 8161e9626b50892eaedbd8070ecb1586ecedb109 ] If dw_pcie_ep_init() fails to perform any action after the EPC memory is initialized and the MSI memory region is allocated, the latter parts won't be undone thus causing a memory leak. Add a cleanup-on-error path to fix these leaks. [bhelgaas: commit log] Fixes: 2fd0c9d966cc ("PCI: designware-ep: Pre-allocate memory for MSI in dw_pcie_ep_init") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:13 2022 +0300 PCI: dwc: Disable outbound windows only for controllers using iATU [ Upstream commit d60a2e281e9de2b2f67343b2e39417ca0f4fd54e ] Some DWC-based controllers (e.g., pcie-al.c and pci-keystone.c, identified by the fact that they override the default dw_child_pcie_ops) use their own address translation approach instead of the DWC internal ATU (iATU). For those controllers, skip disabling the iATU outbound windows. [bhelgaas: commit log, update multiple window comment] Fixes: 458ad06c4cdd ("PCI: dwc: Ensure all outbound ATU windows are reset") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:14 2022 +0300 PCI: dwc: Set INCREASE_REGION_SIZE flag based on limit address [ Upstream commit 777e7c3ab73036105e6fc4a67ed950179dbffbab ] We program the 64-bit ATU limit address (in PCIE_ATU_LIMIT/ PCIE_ATU_UPPER_LIMIT or PCIE_ATU_UNR_LOWER_LIMIT/PCIE_ATU_UNR_UPPER_LIMIT), but in addition, the PCIE_ATU_INCREASE_REGION_SIZE bit must be set if the upper 32 bits of the limit address differ from the upper 32 bits of the base address (see [1,2]). 5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU") set PCIE_ATU_INCREASE_REGION_SIZE, but only when the *size* was greater than 4GB. It did not set it when a smaller region crossed a 4GB boundary, e.g., [mem 0x0_f0000000-0x1_0fffffff]. Set PCIE_ATU_INCREASE_REGION_SIZE whenever PCIE_ATU_UPPER_LIMIT is greater than PCIE_ATU_UPPER_BASE. [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v5.40a, March 2019, fig.3-36, p.175 [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port, v5.40a, March 2019, fig.3-37, p.176 [bhelgaas: commit log] Fixes: 5b4cf0f65324 ("PCI: dwc: Add upper limit address for outbound iATU") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:11 2022 +0300 PCI: dwc: Stop link on host_init errors and de-initialization [ Upstream commit 113fa857b74c947137d845e7e635afcf6a59c43a ] It's logically correct to undo everything that was done when an error is discovered or in the corresponding cleanup counterpart. Otherwise the host controller will be left in an undetermined state. Since the link is set up in the host_init method, deactivate it there in the cleanup-on-error block and stop the link in the antagonistic routine - dw_pcie_host_deinit(). Link deactivation is platform-specific and should be implemented in dw_pcie_ops.stop_link(). Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code") Link: https://lore.kernel.org/r/[email protected] Tested-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shunsuke Mie <[email protected]> Date: Wed Jun 22 13:09:24 2022 +0900 PCI: endpoint: Don't stop controller when unbinding endpoint function [ Upstream commit 1bc2b7bfba6e2f64edf5e246f3af2967261f6c3d ] Unbinding an endpoint function from the endpoint controller shouldn't stop the controller. This is especially a problem for multi-function endpoints where other endpoints may still be active. Don't stop the controller when unbinding one of its endpoints. Normally the controller is stopped via configfs. Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shunsuke Mie <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed Jun 1 08:12:58 2022 +0400 PCI: mediatek-gen3: Fix refcount leak in mtk_pcie_init_irq_domains() [ Upstream commit bf038503d5fe90189743124233fe7aeb0984e961 ] of_get_child_by_name() returns a node pointer with refcount incremented, so we should use of_node_put() on it when we don't need it anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 814cceebba9b ("PCI: mediatek-gen3: Add INTx support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Miles Chen <[email protected]> Acked-by: Jianjun Wang <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 09:51:23 2022 +0400 PCI: microchip: Fix refcount leak in mc_pcie_init_irq_domains() [ Upstream commit f030304fdeb87ec8f1b518c73703214aec6cc24a ] of_get_next_child() returns a node pointer with refcount incremented, so we should use of_node_put() on it when we don't need it anymore. mc_pcie_init_irq_domains() only calls of_node_put() in the normal path, missing it in some error paths. Add missing of_node_put() to avoid refcount leak. Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robert Marko <[email protected]> Date: Thu Jun 23 17:50:03 2022 +0200 PCI: qcom: Power on PHY before IPQ8074 DBI register accesses [ Upstream commit a0e43bb9973b06ce5c666f0901e104e2037c1b34 ] Currently the Gen2 port in IPQ8074 will cause the system to hang as it accesses DBI registers in qcom_pcie_init_2_3_3(), and those are only accesible after phy_power_on(). Move the DBI read/writes to a new qcom_pcie_post_init_2_3_3(), which is executed after phy_power_on(). Link: https://lore.kernel.org/r/[email protected] Fixes: a0fd361db8e5 ("PCI: dwc: Move "dbi", "dbi2", and "addr_space" resource setup into common code") Signed-off-by: Robert Marko <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Cc: [email protected] # v5.11+ Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Marangi <[email protected]> Date: Sat Jul 9 00:27:43 2022 +0200 PCI: qcom: Set up rev 2.1.0 PARF_PHY before enabling clocks [ Upstream commit 38f897ae3d44900f627cad708a15db498ce2ca31 ] We currently enable clocks BEFORE we write to PARF_PHY_CTRL reg to enable clocks and resets. This causes the driver to never set to a ready state with the error 'Phy link never came up'. This is caused by the PHY clock getting enabled before setting the required bits in the PARF regs. A workaround for this was set but with this new discovery we can drop the workaround and use a proper solution to the problem by just enabling the clock only AFTER the PARF_PHY_CTRL bit is set. This correctly sets up the PCIe link and makes it usable even when a bootloader leaves the PCIe link in an undefined state. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Marangi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vidya Sagar <[email protected]> Date: Thu Jul 21 19:50:50 2022 +0530 PCI: tegra194: Fix link up retry sequence [ Upstream commit e05fd6ae77c3e2cc0dba283005d24b6d56d2b1fa ] Add the missing DLF capability offset while clearing DL_FEATURE_EXCHANGE_EN bit during link up retry. Link: https://lore.kernel.org/r/[email protected] Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu Jun 2 07:19:08 2022 +0400 PCI: tegra194: Fix PM error handling in tegra_pcie_config_ep() [ Upstream commit e8fbd344a5ea62663554b8546b6bf9f88b93785a ] pm_runtime_enable() will increase power disable depth. If dw_pcie_ep_init() fails, we should use pm_runtime_disable() to balance it with pm_runtime_enable(). Add missing pm_runtime_disable() for tegra_pcie_config_ep(). Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Vidya Sagar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vidya Sagar <[email protected]> Date: Thu Jul 21 19:50:46 2022 +0530 PCI: tegra194: Fix Root Port interrupt handling [ Upstream commit 6646e99bcec627e866bc84365af37942c72b4b76 ] As part of Root Port interrupt handling, level-0 register is read first and based on the bits set in that, corresponding level-1 registers are read for further interrupt processing. Since both these values are currently read into the same 'val' variable, checking level-0 bits the second time around is happening on the 'val' variable value of level-1 register contents instead of freshly reading the level-0 value again. Fix by using different variables to store level-0 and level-1 registers contents. Link: https://lore.kernel.org/r/[email protected] Fixes: 56e15a238d92 ("PCI: tegra: Add Tegra194 PCIe support") Signed-off-by: Vidya Sagar <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ian Rogers <[email protected]> Date: Sun Jul 31 09:49:23 2022 -0700 perf symbol: Fail to read phdr workaround [ Upstream commit 6d518ac7be6223811ab947897273b1bbef846180 ] The perf jvmti agent doesn't create program headers, in this case fallback on section headers as happened previously. Committer notes: To test this, from a public post by Ian: 1) download a Java workload dacapo-9.12-MR1-bach.jar from https://sourceforge.net/projects/dacapobench/ 2) build perf such as "make -C tools/perf O=/tmp/perf NO_LIBBFD=1" it should detect Java and create /tmp/perf/libperf-jvmti.so 3) run perf with the jvmti agent: perf record -k 1 java -agentpath:/tmp/perf/libperf-jvmti.so -jar dacapo-9.12-MR1-bach.jar -n 10 fop 4) run perf inject: perf inject -i perf.data -o perf-injected.data -j 5) run perf report perf report -i perf-injected.data | grep org.apache.fop With this patch reverted I see lots of symbols like: 0.00% java jitted-388040-4656.so [.] org.apache.fop.fo.FObj.bind(org.apache.fop.fo.PropertyList) With the patch (2d86612aacb7805f ("perf symbol: Correct address for bss symbols")) I see lots of: dso__load_sym_internal: failed to find program header for symbol: Lorg/apache/fop/fo/FObj;bind(Lorg/apache/fop/fo/PropertyList;)V st_value: 0x40 Fixes: 2d86612aacb7805f ("perf symbol: Correct address for bss symbols") Reviewed-by: Leo Yan <[email protected]> Signed-off-by: Ian Rogers <[email protected]> Tested-by: Leo Yan <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Leo Yan <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adrian Hunter <[email protected]> Date: Mon Jul 11 12:31:44 2022 +0300 perf tools: Fix dso_id inode generation comparison [ Upstream commit 68566a7cf56bf3148797c218ed45a9de078ef47c ] Synthesized MMAP events have zero ino_generation, so do not compare them to DSOs with a real ino_generation otherwise we end up with a DSO without a build id. Fixes: 0e3149f86b99ddab ("perf dso: Move dso_id from 'struct map' to 'struct dso'") Signed-off-by: Adrian Hunter <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: [email protected] Cc: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ Added clarification to the comment from Ian + more detailed explanation from Adrian ] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chanho Park <[email protected]> Date: Fri Jun 3 14:05:36 2022 +0900 phy: samsung: exynosautov9-ufs: correct TSRV register configurations [ Upstream commit f7fdc4db071f7ee7d408ea3f083222a060c76623 ] For exynos auto v9's UFS MPHY, We should use 0x50 offset of TSRV register configurations. So, it must be s/PHY_TRSV_REG_CFG/PHY_TRSV_REG_CFG_AUTOV9/g Fixes: d64519249e1d ("phy: samsung-ufs: support exynosauto ufs phy driver") Signed-off-by: Chanho Park <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabrice Gasnier <[email protected]> Date: Wed Jul 13 15:39:53 2022 +0200 phy: stm32: fix error return in stm32_usbphyc_phy_init [ Upstream commit 32b378a9179ae4db61cfc5d502717214e6cd1e1c ] Error code is overridden, in case the PLL doesn't lock. So, the USB initialization can continue. This leads to a platform freeze. This can be avoided by returning proper error code to avoid USB probe freezing the platform. It also displays proper errors in log. Fixes: 5b1af71280ab ("phy: stm32: rework PLL Lock detection") Signed-off-by: Fabrice Gasnier <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stephen Boyd <[email protected]> Date: Tue Jun 14 00:57:26 2022 -0700 platform/chrome: cros_ec: Always expose last resume result [ Upstream commit 74bb746407bf0d7c7d126c7731dbcd66d467619b ] The last resume result exposing logic in cros_ec_sleep_event() incorrectly requires S0ix support, which doesn't work on ARM based systems where S0ix doesn't exist. That's because cros_ec_sleep_event() only reports the last resume result when the EC indicates the last sleep event was an S0ix resume. On ARM systems, the last sleep event is always S3 resume, but the EC can still detect sleep hang events in case some other part of the AP is blocking sleep. Always expose the last resume result if the EC supports it so that this works on all devices regardless of S0ix support. This fixes sleep hang detection on ARM based chromebooks like Trogdor. Cc: Rajat Jain <[email protected]> Cc: Matthias Kaehlcke <[email protected]> Cc: Hsin-Yi Wang <[email protected]> Cc: Tzung-Bi Shih <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Reviewed-by: Evan Green <[email protected]> Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event") Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Tzung-Bi Shih <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jul 20 21:23:38 2022 +0300 platform/olpc: Fix uninitialized data in debugfs write [ Upstream commit 40ec787e1adf302c11668d4cc69838f4d584187d ] The call to: size = simple_write_to_buffer(cmdbuf, sizeof(cmdbuf), ppos, buf, size); will succeed if at least one byte is written to the "cmdbuf" buffer. The "*ppos" value controls which byte is written. Another problem is that this code does not check for errors so it's possible for the entire buffer to be uninitialized. Inintialize the struct to zero to prevent reading uninitialized stack data. Debugfs is normally only writable by root so the impact of this bug is very minimal. Fixes: 6cca83d498bd ("Platform: OLPC: move debugfs support from x86 EC driver") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/YthIKn+TfZSZMEcM@kili Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hsin-Yi Wang <[email protected]> Date: Wed Jul 6 01:16:49 2022 +0800 PM: domains: Ensure genpd_debugfs_dir exists before remove [ Upstream commit 37101d3c719386040ded735a5ec06974f1d94d1f ] Both genpd_debug_add() and genpd_debug_remove() may be called indirectly by other drivers while genpd_debugfs_dir is not yet set. For example, drivers can call pm_genpd_init() in probe or pm_genpd_init() in probe fail/cleanup path: pm_genpd_init() --> genpd_debug_add() pm_genpd_remove() --> genpd_remove() --> genpd_debug_remove() At this time, genpd_debug_init() may not yet be called. genpd_debug_add() checks that if genpd_debugfs_dir is NULL, it will return directly. Make sure this is also checked in pm_genpd_remove(), otherwise components under debugfs root which has the same name as other components under pm_genpd may be accidentally removed, since NULL represents debugfs root. Fixes: 718072ceb211 ("PM: domains: create debugfs nodes when adding power domains") Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Ulf Hansson <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Fri Jul 15 14:49:58 2022 +0900 PM: hibernate: defer device probing when resuming from hibernation [ Upstream commit 8386c414e27caba8501119948e9551e52b527f59 ] syzbot is reporting hung task at misc_open() [1], for there is a race window of AB-BA deadlock which involves probe_count variable. Currently wait_for_device_probe() from snapshot_open() from misc_open() can sleep forever with misc_mtx held if probe_count cannot become 0. When a device is probed by hub_event() work function, probe_count is incremented before the probe function starts, and probe_count is decremented after the probe function completed. There are three cases that can prevent probe_count from dropping to 0. (a) A device being probed stopped responding (i.e. broken/malicious hardware). (b) A process emulating a USB device using /dev/raw-gadget interface stopped responding for some reason. (c) New device probe requests keeps coming in before existing device probe requests complete. The phenomenon syzbot is reporting is (b). A process which is holding system_transition_mutex and misc_mtx is waiting for probe_count to become 0 inside wait_for_device_probe(), but the probe function which is called from hub_event() work function is waiting for the processes which are blocked at mutex_lock(&misc_mtx) to respond via /dev/raw-gadget interface. This patch mitigates (b) by deferring wait_for_device_probe() from snapshot_open() to snapshot_write() and snapshot_ioctl(). Please note that the possibility of (b) remains as long as any thread which is emulating a USB device via /dev/raw-gadget interface can be blocked by uninterruptible blocking operations (e.g. mutex_lock()). Please also note that (a) and (c) are not addressed. Regarding (c), we should change the code to wait for only one device which contains the image for resuming from hibernation. I don't know how to address (a), for use of timeout for wait_for_device_probe() might result in loss of user data in the image. Maybe we should require the userland to wait for the image device before opening /dev/snapshot interface. Link: https://syzkaller.appspot.com/bug?extid=358c9ab4c93da7b7238c [1] Reported-by: syzbot <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Tested-by: syzbot <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Wed May 18 16:09:06 2022 -0400 pNFS/flexfiles: Report RDMA connection errors to the server commit 7836d75467e9d214bdf5c693b32721de729a6e38 upstream. The RPC/RDMA driver will return -EPROTO and -ENODEV as connection errors under certain circumstances. Make sure that we handle them and report them to the server. If not, we can end up cycling forever in a LAYOUTGET/LAYOUTRETURN loop. Fixes: a12f996d3413 ("NFSv4/pNFS: Use connections to a DS that are all of the same protocol family") Cc: [email protected] # 5.11.x Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thadeu Lima de Souza Cascardo <[email protected]> Date: Tue Aug 9 14:07:51 2022 -0300 posix-cpu-timers: Cleanup CPU timers before freeing them during exec commit e362359ace6f87c201531872486ff295df306d13 upstream. Commit 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") started looking up tasks by PID when deleting a CPU timer. When a non-leader thread calls execve, it will switch PIDs with the leader process. Then, as it calls exit_itimers, posix_cpu_timer_del cannot find the task because the timer still points out to the old PID. That means that armed timers won't be disarmed, that is, they won't be removed from the timerqueue_list. exit_itimers will still release their memory, and when that list is later processed, it leads to a use-after-free. Clean up the timers from the de-threaded task before freeing them. This prevents a reported use-after-free. Fixes: 55e8c8eb2c7b ("posix-cpu-timers: Store a reference to a pid not a task") Signed-off-by: Thadeu Lima de Souza Cascardo <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Thomas Gleixner <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Tue Jun 14 12:34:08 2022 +0200 powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping. [ Upstream commit 980bbf7ca72012d317617fcdbfabe8708e4cef29 ] mark_initmem_nx() calls either mmu_mark_initmem_nx() or set_memory_attr() based on return from v_block_mapped() of _sinittext. But we can now handle text and data independently, so that text may be mapped by block even when data is mapped by pages. On the 8xx for instance, at startup 32Mbytes of memory are pinned in TLB. So the pinned entries need to go away for sinittext. In next patch a BAT will be set to also covers sinittext on book3s/32. So it will also be needed to call mmu_mark_initmem_nx() even when data above sinittext is not mapped with BATs. As this is highly dependent on the platform, call mmu_mark_initmem_nx() regardless of data block mapping. Then the platform will know what to do. Modify 8xx mmu_mark_initmem_nx() so that inittext mapping is modified only when pagealloc debug and kfence are not active, otherwise inittext is mapped with standard pages. And don't do anything on kernel text which is already mapped with PAGE_KERNEL_TEXT. Fixes: da1adea07576 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/db3fc14f3bfa6215b0786ef58a6e2bc1e1f964d7.1655202804.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Mon Jul 11 16:19:29 2022 +0200 powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32 [ Upstream commit 9be013b2a9ecb29b5168e4b9db0e48ed53acf37c ] Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") enlarged the CPU selection logic to PPC32 by removing depend to PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU. Fortunately that got unnoticed because -mcpu=8540 will override the -mcpu=e500mc64 or -mpcu=e6500 as they are ealier, but that's fragile and may no be right in the future. Add back the depend PPC64 on E5500_CPU and E6500_CPU. Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/8abab4888da69ff78b73a56f64d9678a7bf684e9.1657549153.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Ellerman <[email protected]> Date: Mon Jul 18 23:44:18 2022 +1000 powerpc/64s: Disable stack variable initialisation for prom_init [ Upstream commit be640317a1d0b9cf42fedb2debc2887a7cfa38de ] With GCC 12 allmodconfig prom_init fails to build: Error: External symbol 'memset' referenced from prom_init.c make[2]: *** [arch/powerpc/kernel/Makefile:204: arch/powerpc/kernel/prom_init_check] Error 1 The allmodconfig build enables KASAN, so all calls to memset in prom_init should be converted to __memset by the #ifdefs in asm/string.h, because prom_init must use the non-KASAN instrumented versions. The build failure happens because there's a call to memset that hasn't been caught by the pre-processor and converted to __memset. Typically that's because it's a memset generated by the compiler itself, and that is the case here. With GCC 12, allmodconfig enables CONFIG_INIT_STACK_ALL_PATTERN, which causes the compiler to emit memset calls to initialise on-stack variables with a pattern. Because prom_init is non-user-facing boot-time only code, as a workaround just disable stack variable initialisation to unbreak the build. Reported-by: Sudip Mukherjee <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 10:51:29 2022 +0400 powerpc/cell/axon_msi: Fix refcount leak in setup_msi_msg_address [ Upstream commit df5d4b616ee76abc97e5bd348e22659c2b095b1c ] of_get_next_parent() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() in the error path to avoid refcount leak. Fixes: ce21b3c9648a ("[CELL] add support for MSI on Axon-based Cell systems") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Wed Jul 6 12:10:43 2022 +0200 powerpc/fsl-pci: Fix Class Code of PCIe Root Port commit 0c551abfa004ce154d487d91777bf221c808a64f upstream. By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020 board which has this pre-3.0 controller: $ lspci -bvnn 00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) !!! Invalid class 0b20 for header type 01 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Fix this issue by programming correct PCI Class Code 0x0604 for PCIe Root Port to the Freescale specific PCIe register 0x474. With this change lspci -b output is: $ lspci -bvnn 00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) (prog-if 00 [Normal decode]) Capabilities: [4c] Express Root Port (Slot-), MSI 00 Without any "Invalid class" error. So class code was properly reflected into standard (read-only) PCI register 0x08. Same fix is already implemented in U-Boot pcie_fsl.c driver in commit: http://source.denx.de/u-boot/u-boot/-/commit/d18d06ac35229345a0af80977a408cfbe1d1015b Fix activated by U-Boot stay active also after booting Linux kernel. But boards which use older U-Boot version without that fix are affected and still require this fix. So implement this class code fix also in kernel fsl_pci.c driver. Cc: [email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexey Kardashevskiy <[email protected]> Date: Thu Jul 14 18:11:19 2022 +1000 powerpc/iommu: Fix iommu_table_in_use for a small default DMA window case [ Upstream commit d80f6de9d601c30b53c17f00cb7cfe3169f2ddad ] The existing iommu_table_in_use() helper checks if the kernel is using any of TCEs. There are some reserved TCEs: 1) the very first one if DMA window starts from 0 to avoid having a zero but still valid DMA handle; 2) it_reserved_start..it_reserved_end to exclude MMIO32 window in case the default window spans across that - this is the default for the first DMA window on PowerNV. When 1) is the case and 2) is not the helper does not skip 1) and returns wrong status. This only seems occurring when passing through a PCI device to a nested guest (not something we support really well) so it has not been seen before. This fixes the bug by adding a special case for no MMIO32 reservation. Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Ellerman <[email protected]> Date: Tue Aug 2 20:38:32 2022 +1000 powerpc/pci: Fix PHB numbering when using opal-phbid [ Upstream commit f4b39e88b42d13366b831270306326b5c20971ca ] The recent change to the PHB numbering logic has a logic error in the handling of "ibm,opal-phbid". When an "ibm,opal-phbid" property is present, &prop is written to and ret is set to zero. The following call to of_alias_get_id() is skipped because ret == 0. But then the if (ret >= 0) is true, and the body of that if statement sets prop = ret which throws away the value that was just read from "ibm,opal-phbid". Fix the logic by only doing the ret >= 0 check in the of_alias_get_id() case. Fixes: 0fe1e96fef0a ("powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias") Reviewed-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Pali Rohár <[email protected]> Date: Wed Jul 6 12:21:48 2022 +0200 powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias [ Upstream commit 0fe1e96fef0a5c53b4c0d1500d356f3906000f81 ] Other Linux architectures use DT property 'linux,pci-domain' for specifying fixed PCI domain of PCI controller specified in Device-Tree. And lot of Freescale powerpc boards have defined numbered pci alias in Device-Tree for every PCIe controller which number specify preferred PCI domain. So prefer usage of DT property 'linux,pci-domain' (via function of_get_pci_domain_nr()) and DT pci alias (via function of_alias_get_id()) on powerpc architecture for assigning PCI domain to PCI controller. Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Athira Rajeev <[email protected]> Date: Sun May 22 19:52:56 2022 +0530 powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable [ Upstream commit 890005a7d98f7452cfe86dcfb2aeeb7df01132ce ] commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SPR read also. From point 1, we know that if PMI pending in Paca from inactive cases, that is going to be ignored during replay. Hence if there is pending PMI in Paca, just clear it irrespective of PMC overflown or not. In summary, remove the any_pmc_overflown check entirely in power_pmu_disable. ie If there is a pending PMI in Paca, clear it, since we are in pmu_disable. There could be cases where PMI is pending because of inactive PMC ( which later when replayed also will get ignored ), so WARN_ON could give false warning. Hence removing it. Fixes: 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") Signed-off-by: Athira Rajeev <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Thu Jul 28 00:32:18 2022 +1000 powerpc/powernv/kvm: Use darn for H_RANDOM on Power9 [ Upstream commit 7ef3d06f1bc4a5e62273726f3dc2bd258ae1c71f ] The existing logic in KVM to support guests calling H_RANDOM only works on Power8, because it looks for an RNG in the device tree, but on Power9 we just use darn. In addition the existing code needs to work in real mode, so we have the special cased powernv_get_random_real_mode() to deal with that. Instead just have KVM call ppc_md.get_random_seed(), and do the real mode check inside of there, that way we use whatever RNG is available, including darn on Power9. Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.") Cc: [email protected] # v4.1+ Signed-off-by: Jason A. Donenfeld <[email protected]> Tested-by: Sachin Sant <[email protected]> [mpe: Rebase on previous commit, update change log appropriately] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Ellerman <[email protected]> Date: Thu Jul 28 00:32:17 2022 +1000 powerpc/powernv: Avoid crashing if rng is NULL commit 90b5d4fe0b3ba7f589c6723c6bfb559d9e83956a upstream. On a bare-metal Power8 system that doesn't have an "ibm,power-rng", a malicious QEMU and guest that ignore the absence of the KVM_CAP_PPC_HWRNG flag, and calls H_RANDOM anyway, will dereference a NULL pointer. In practice all Power8 machines have an "ibm,power-rng", but let's not rely on that, add a NULL check and early return in powernv_get_random_real_mode(). Fixes: e928e9cb3601 ("KVM: PPC: Book3S HV: Add fast real-mode H_RANDOM implementation.") Cc: [email protected] # v4.1+ Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Tue Jun 28 16:43:35 2022 +0200 powerpc/ptdump: Fix display of RW pages on FSL_BOOK3E commit dd8de84b57b02ba9c1fe530a6d916c0853f136bd upstream. On FSL_BOOK3E, _PAGE_RW is defined with two bits, one for user and one for supervisor. As soon as one of the two bits is set, the page has to be display as RW. But the way it is implemented today requires both bits to be set in order to display it as RW. Instead of display RW when _PAGE_RW bits are set and R otherwise, reverse the logic and display R when _PAGE_RW bits are all 0 and RW otherwise. This change has no impact on other platforms as _PAGE_RW is a single bit on all of them. Fixes: 8eb07b187000 ("powerpc/mm: Dump linux pagetables") Cc: [email protected] Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/0c33b96317811edf691e81698aaee8fa45ec3449.1656427391.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 16:15:42 2022 +0400 powerpc/spufs: Fix refcount leak in spufs_init_isolated_loader [ Upstream commit 6ac059dacffa8ab2f7798f20e4bd3333890c541c ] of_find_node_by_path() returns remote device nodepointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 0afacde3df4c ("[POWERPC] spufs: allow isolated mode apps by starting the SPE loader") Signed-off-by: Miaoqian Lin <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 09:32:23 2022 +0400 powerpc/xive: Fix refcount leak in xive_get_max_prio [ Upstream commit 255b650cbec6849443ce2e0cdd187fd5e61c218c ] of_find_node_by_path() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: eac1e731b59e ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Tue Aug 2 11:02:36 2022 +0200 powerpc: Fix eh field when calling lwarx on PPC32 commit 18db466a9a306406dab3b134014d9f6ed642471c upstream. Commit 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros") properly handled the eh field of lwarx in asm/bitops.h but failed to clear it for PPC32 in asm/simple_spinlock.h So, do as in arch_atomic_try_cmpxchg_lock(), set it to 1 if PPC64 but set it to 0 if PPC32. For that use IS_ENABLED(CONFIG_PPC64) which returns 1 when CONFIG_PPC64 is set and 0 otherwise. Fixes: 9401f4e46cf6 ("powerpc: Use lwarx/ldarx directly instead of PPC_LWARX/LDARX macros") Cc: [email protected] # v5.15+ Reported-by: Pali Rohár <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Pali Rohár <[email protected]> Reviewed-by: Segher Boessenkool <[email protected]> [mpe: Use symbolic names, use 'n' constraint per Segher] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/a1176e19e627dd6a1b8d24c6c457a8ab874b7d12.1659430931.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhihao Cheng <[email protected]> Date: Wed Jul 13 21:00:29 2022 +0800 proc: fix a dentry lock race between release_task and lookup [ Upstream commit d919a1e79bac890421537cf02ae773007bf55e6b ] Commit 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") moved proc_flush_task() behind __exit_signal(). Then, process systemd can take long period high cpu usage during releasing task in following concurrent processes: systemd ps kernel_waitid stat(/proc/tgid) do_wait filename_lookup wait_consider_task lookup_fast release_task __exit_signal __unhash_process detach_pid __change_pid // remove task->pid_links d_revalidate -> pid_revalidate // 0 d_invalidate(/proc/tgid) shrink_dcache_parent(/proc/tgid) d_walk(/proc/tgid) spin_lock_nested(/proc/tgid/fd) // iterating opened fd proc_flush_pid | d_invalidate (/proc/tgid/fd) | shrink_dcache_parent(/proc/tgid/fd) | shrink_dentry_list(subdirs) ↓ shrink_lock_dentry(/proc/tgid/fd) --> race on dentry lock Function d_invalidate() will remove dentry from hash firstly, but why does proc_flush_pid() process dentry '/proc/tgid/fd' before dentry '/proc/tgid'? That's because proc_pid_make_inode() adds proc inode in reverse order by invoking hlist_add_head_rcu(). But proc should not add any inodes under '/proc/tgid' except '/proc/tgid/task/pid', fix it by adding inode into 'pid->inodes' only if the inode is /proc/tgid or /proc/tgid/task/pid. Performance regression: Create 200 tasks, each task open one file for 50,000 times. Kill all tasks when opened files exceed 10,000,000 (cat /proc/sys/fs/file-nr). Before fix: $ time killall -wq aa real 4m40.946s # During this period, we can see 'ps' and 'systemd' taking high cpu usage. After fix: $ time killall -wq aa real 1m20.732s # During this period, we can see 'systemd' taking high cpu usage. Link: https://lkml.kernel.org/r/[email protected] Fixes: 7bc3e6e55acf06 ("proc: Use a list of inodes to flush from proc") Link: https://bugzilla.kernel.org/show_bug.cgi?id=216054 Signed-off-by: Zhihao Cheng <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Suggested-by: Brian Foster <[email protected]> Reviewed-by: Brian Foster <[email protected]> Cc: Al Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Eric Biederman <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Baoquan He <[email protected]> Cc: Kalesh Singh <[email protected]> Cc: Yu Kuai <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Zhongjin <[email protected]> Date: Tue May 31 09:28:54 2022 +0800 profiling: fix shift too large makes kernel panic [ Upstream commit 0fe6ee8f123a4dfb529a5aff07536bb481f34043 ] 2d186afd04d6 ("profiling: fix shift-out-of-bounds bugs") limits shift value by [0, BITS_PER_LONG -1], which means [0, 63]. However, syzbot found that the max shift value should be the bit number of (_etext - _stext). If shift is outside of this, the "buffer_bytes" will be zero and will cause kzalloc(0). Then the kernel panics due to dereferencing the returned pointer 16. This can be easily reproduced by passing a large number like 60 to enable profiling and then run readprofile. LOGS: BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 6148067 P4D 6148067 PUD 6142067 PMD 0 PREEMPT SMP CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ #162 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_profile+0x104/0x220 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30 FS: 000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0 Call Trace: <TASK> proc_reg_read+0x56/0x70 vfs_read+0x9a/0x1b0 ksys_read+0xa1/0xe0 ? fpregs_assert_state_consistent+0x1e/0x40 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x4d4b4e RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60 </TASK> Modules linked in: CR2: 0000000000000010 Killed ---[ end trace 0000000000000000 ]--- Check prof_len in profile_init() to prevent it be zero. Link: https://lkml.kernel.org/r/[email protected] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Chen Zhongjin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Wed Nov 10 09:49:49 2021 +0100 pwm: lpc18xx-sct: Reduce number of devm memory allocations [ Upstream commit 20d9de9c4d6642bb40c935233697723b56573cbc ] Each devm allocations has an overhead of 24 bytes to store the related struct devres_node additionally to the fragmentation of the allocator. So allocating 16 struct lpc18xx_pwm_data (which only hold a single int) adds quite some overhead. Instead put the per-channel data into the driver data struct and allocate it in one go. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Wed Nov 10 09:49:50 2021 +0100 pwm: lpc18xx-sct: Simplify driver by not using pwm_[gs]et_chip_data() [ Upstream commit 9136a39e6cf69e49803ac6123a4ac4431bc915a2 ] The per-channel data is available directly in the driver data struct. So use it without making use of pwm_[gs]et_chip_data(). The relevant change introduced by this patch to lpc18xx_pwm_disable() at the assembler level (for an arm lpc18xx_defconfig build) is: push {r3, r4, r5, lr} mov r4, r0 mov r0, r1 mov r5, r1 bl 0 <pwm_get_chip_data> ldr r3, [r0, #0] changes to ldr r3, [r1, #8] push {r4, lr} add.w r3, r0, r3, lsl #2 ldr r3, [r3, #92] ; 0x5c So this reduces stack usage, has an improved runtime behavior because of better pipeline usage, doesn't branch to an external function and the generated code is a bit smaller occupying less memory. The codesize of lpc18xx_pwm_probe() is reduced by 32 bytes. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Tue Jul 12 18:15:19 2022 +0200 pwm: lpc18xx: Fix period handling [ Upstream commit 8933d30c5f468d6cc1e4bf9bb535149da35f202e ] The calculation: val = (u64)NSEC_PER_SEC * LPC18XX_PWM_TIMER_MAX; do_div(val, lpc18xx_pwm->clk_rate); lpc18xx_pwm->max_period_ns = val; is bogus because with NSEC_PER_SEC = 1000000000, LPC18XX_PWM_TIMER_MAX = 0xffffffff and clk_rate < NSEC_PER_SEC this overflows the (on lpc18xx (i.e. ARM32) 32 bit wide) unsigned int .max_period_ns. This results (dependant of the actual clk rate) in an arbitrary limitation of the maximal period. E.g. for clkrate = 333333333 (Hz) we get max_period_ns = 9 instead of 12884901897. So make .max_period_ns an u64 and pass period and duty as u64 to not discard relevant digits. And also make use of mul_u64_u64_div_u64() which prevents all overflows assuming clk_rate < NSEC_PER_SEC. Fixes: 841e6f90bb78 ("pwm: NXP LPC18xx PWM/SCT driver") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Thu Jul 21 12:31:28 2022 +0200 pwm: sifive: Ensure the clk is enabled exactly once per running PWM [ Upstream commit ace41d7564e655c39f709a78c035188a460c7cbd ] .apply() assumes the clk to be for a given PWM iff the PWM is enabled. So make sure this is the case when .probe() completes. And in .remove() disable the according number of times. This fixes a clk enable/disable imbalance, if some PWMs are already running at probe time. Fixes: 9e37a53eb051 (pwm: sifive: Add a driver for SiFive SoC PWM) Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Thu Jul 21 12:31:29 2022 +0200 pwm: sifive: Shut down hardware only after pwmchip_remove() completed [ Upstream commit 2375e964d541bb09158cd2dff67b5d74e8de61cd ] The PWMs are expected to be functional until pwmchip_remove() is called. So disable the clks only afterwards. Fixes: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM") Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Thu Jul 21 12:31:23 2022 +0200 pwm: sifive: Simplify offset calculation for PWMCMP registers [ Upstream commit 20550a61880fc55e68a0d290ad195b74729c0e7b ] Instead of explicitly using PWM_SIFIVE_PWMCMP0 + pwm->hwpwm * PWM_SIFIVE_SIZE_PWMCMP for each access to one of the PWMCMP registers, introduce a macro that takes the hwpwm id as parameter. For the register definition using a plain 4 instead of the cpp constant PWM_SIFIVE_SIZE_PWMCMP is easier to read, so define the offset macro without the constant. The latter can then be dropped as there are no users left. Signed-off-by: Uwe Kleine-König <[email protected]> Tested-by: Emil Renner Berthing <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul E. McKenney <[email protected]> Date: Fri Aug 6 08:57:26 2021 -0700 rcutorture: Don't cpuhp_remove_state() if cpuhp_setup_state() failed [ Upstream commit fd13fe16db0d82612b260640f4e26f6d9d1e11fd ] Currently, in CONFIG_RCU_BOOST kernels, if the rcu_torture_init() function's call to cpuhp_setup_state() fails, rcu_torture_cleanup() gamely passes nonsense to cpuhp_remove_state(). This results in strange and misleading splats. This commit therefore ensures that if the rcu_torture_init() function's call to cpuhp_setup_state() fails, rcu_torture_cleanup() avoids invoking cpuhp_remove_state(). Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frederic Weisbecker <[email protected]> Date: Fri Jun 10 15:03:57 2022 +0200 rcutorture: Fix ksoftirqd boosting timing and iteration [ Upstream commit 3002153a91a9732a6d1d0bb95138593c7da15743 ] The RCU priority boosting can fail in two situations: 1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs is higher than those brought online at boot, then torture_onoff() may later bring up CPUs that weren't online on boot. Now since rcutorture initialization only boosts the ksoftirqds of the CPUs that have been set online on boot, the CPUs later set online by torture_onoff won't benefit from the boost, making RCU priority boosting fail. 2) The ksoftirqd kthreads are boosted after the creation of rcu_torture_boost() kthreads, which opens a window large enough for these rcu_torture_boost() kthreads to wait (despite running at FIFO priority) for ksoftirqds that are still running at SCHED_NORMAL priority. The issues can trigger for example with: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Modules linked in: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1 [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: De-offloading 8 [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Call Trace: [ 37.295049] <TASK> [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] </TASK> Fix this with boosting the ksoftirqds kthreads from the boosting hotplug callback itself and before the boosting kthreads are created. Fixes: ea6d962e80b6 ("rcutorture: Judge RCU priority boosting on grace periods, not callbacks") Signed-off-by: Frederic Weisbecker <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Paul E. McKenney <[email protected]> Date: Thu Aug 5 13:28:24 2021 -0700 rcutorture: Warn on individual rcu_torture_init() error conditions [ Upstream commit efeff6b39b9de4480572c7b0c5eb77204795cb57 ] When running rcutorture as a module, any rcu_torture_init() issues will be reflected in the error code from modprobe or insmod, as the case may be. However, these error codes are not available when running rcutorture built-in, for example, when using the kvm.sh script. This commit therefore adds WARN_ON_ONCE() to allow distinguishing rcu_torture_init() errors when running rcutorture built-in. Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jianglei Nie <[email protected]> Date: Mon Jul 11 15:07:18 2022 +0800 RDMA/hfi1: fix potential memory leak in setup_base_ctxt() [ Upstream commit aa2a1df3a2c85f855af7d54466ac10bd48645d63 ] setup_base_ctxt() allocates a memory chunk for uctxt->groups with hfi1_alloc_ctxt_rcv_groups(). When init_user_ctxt() fails, uctxt->groups is not released, which will lead to a memory leak. We should release the uctxt->groups with hfi1_free_ctxt_rcv_groups() when init_user_ctxt() fails. Fixes: e87473bc1b6c ("IB/hfi1: Only set fd pointer when base context is completely initialized") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jianglei Nie <[email protected]> Acked-by: Dennis Dalessandro <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Haoyue Xu <[email protected]> Date: Thu Jul 14 21:43:51 2022 +0800 RDMA/hns: Fix incorrect clearing of interrupt status register [ Upstream commit ecb4db5c3590aa956b4b2c352081a5b632d1f9f9 ] The driver will clear all the interrupts in the same area when the driver handles the interrupt of type AEQ overflow. It should only set the interrupt status bit of type AEQ overflow. Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Haoyue Xu <[email protected]> Signed-off-by: Wenpeng Liang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mustafa Ismail <[email protected]> Date: Tue Jul 5 18:08:13 2022 -0500 RDMA/irdma: Fix a window for use-after-free [ Upstream commit 8ecef7890b3aea78c8bbb501a4b5b8134367b821 ] During a destroy CQ an interrupt may cause processing of a CQE after CQ resources are freed by irdma_cq_free_rsrc(). Fix this by moving the call to irdma_cq_free_rsrc() after the irdma_sc_cleanup_ceqes(), which is called under the cq_lock. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Sobczak <[email protected]> Signed-off-by: Mustafa Ismail <[email protected]> Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mustafa Ismail <[email protected]> Date: Tue Jul 5 18:08:15 2022 -0500 RDMA/irdma: Fix setting of QP context err_rq_idx_valid field [ Upstream commit 3a844596ed71b7c12ac602f6f6b7b0f17e4d6a90 ] Setting err_rq_idx_valid field in QP context when the AE source of the AEQE is not associated with an RQ causes the firmware flush to fail. Set err_rq_idx_valid field in QP context only if it is associated with an RQ. Additionally, cleanup the redundant setting of this field in irdma_process_aeq. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mustafa Ismail <[email protected]> Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mustafa Ismail <[email protected]> Date: Tue Jul 5 18:08:14 2022 -0500 RDMA/irdma: Fix VLAN connection with wildcard address [ Upstream commit 82ab2b52654c43ba24a3f6603fec40874cc5a7e5 ] When an application listens on a wildcard address, and there are VLAN and non-VLAN IP addresses, iWARP connection establishemnt can fail if the listen node VLAN ID does not match. Fix this by checking the vlan_id only if not a wildcard listen node. Fixes: 146b9756f14c ("RDMA/irdma: Add connection manager") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mustafa Ismail <[email protected]> Signed-off-by: Shiraz Saleem <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maor Gottlieb <[email protected]> Date: Sun Jul 31 11:29:08 2022 +0300 RDMA/mlx5: Add missing check for return value in get namespace flow [ Upstream commit c9776457bd5eaad4ce4ecb17af8d8f3cc6957c0b ] Add missing check for return value when calling to mlx5_ib_ft_type_to_namespace, even though it can't really fail in this specific call. Fixes: 52438be44112 ("RDMA/mlx5: Allow inserting a steering rule to the FDB") Link: https://lore.kernel.org/r/7b9ceda217d9368a51dc47a46b769bad4af9ac92.1659256069.git.leonro@nvidia.com Reviewed-by: Itay Aveksis <[email protected]> Signed-off-by: Maor Gottlieb <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jianglei Nie <[email protected]> Date: Thu Jul 14 14:15:05 2022 +0800 RDMA/qedr: Fix potential memory leak in __qedr_alloc_mr() [ Upstream commit b3236a64ddd125a455ef5b5316c1b9051b732974 ] __qedr_alloc_mr() allocates a memory chunk for "mr->info.pbl_table" with init_mr_info(). When rdma_alloc_tid() and rdma_register_tid() fail, "mr" is released while "mr->info.pbl_table" is not released, which will lead to a memory leak. We should release the "mr->info.pbl_table" with qedr_free_pbl() when error occurs to fix the memory leak. Fixes: e0290cce6ac0 ("qedr: Add support for memory registeration verbs") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jianglei Nie <[email protected]> Acked-by: Michal Kalderon <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vaishali Thakkar <[email protected]> Date: Wed Jan 5 19:07:06 2022 +0100 RDMA/rtrs-clt: Rename rtrs_clt_sess to rtrs_clt_path [ Upstream commit caa84d95c78f35168847e2ab861a3a7f87033d36 ] rtrs_clt_sess is used for paths and not sessions on the client side. This creates confusion so let's rename it to rtrs_clt_path. Also, rename related variables and functions. Coccinelle is used to do the transformations for most of the occurrences and remaining ones were handled manually. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vaishali Thakkar <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Tue Jul 12 12:31:12 2022 +0200 RDMA/rtrs-clt: Replace list_next_or_null_rr_rcu with an inline function [ Upstream commit c14adff285ad1bb8eefc5d8fc202ceb1f7e3a2f1 ] removes list_next_or_null_rr_rcu macro to fix below warnings. That macro is used only twice. CHECK:MACRO_ARG_REUSE: Macro argument reuse 'head' - possible side-effects? CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ptr' - possible side-effects? CHECK:MACRO_ARG_REUSE: Macro argument reuse 'memb' - possible side-effects? Replaces that macro with an inline function. Fixes: 6a98d71daea1 ("RDMA/rtrs: client: main functionality") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Suggested-by: Jason Gunthorpe <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Wang <[email protected]> Date: Tue Jul 12 12:31:09 2022 +0200 RDMA/rtrs-srv: Fix modinfo output for stringify [ Upstream commit ed6e53820ee4f68ed927de17e5675ff2a07a47e2 ] stringify works with define, not enum. Fixes: 91fddedd439c ("RDMA/rtrs: private headers with rtrs protocol structs and helpers") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Md Haris Iqbal <[email protected]> Reviewed-by: Aleksei Marov <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vaishali Thakkar <[email protected]> Date: Wed Jan 5 19:07:05 2022 +0100 RDMA/rtrs-srv: Rename rtrs_srv_sess to rtrs_srv_path [ Upstream commit ae4c81644e9105d9f7f713bb0d444737bb6a0cf1 ] rtrs_srv_sess is used for paths and not sessions on the server side. This creates confusion so let's rename it to rtrs_srv_path. Also, rename related variables and functions. Coccinelle is used to do the transformations for most of the occurrences and remaining ones were handled manually. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vaishali Thakkar <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Wed Sep 22 14:53:32 2021 +0200 RDMA/rtrs: Do not allow sessname to contain special symbols / and . [ Upstream commit dea7bb3ad3e08f96815330f88a62c24d7a9dacae ] Allowing these characters in sessname can lead to unexpected results, particularly because / is used as a separator between files in a path, and . points to the current directory. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Reviewed-by: Gioh Kim <[email protected]> Reviewed-by: Aleksei Marov <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Wang <[email protected]> Date: Wed Sep 22 14:53:29 2021 +0200 RDMA/rtrs: Fix warning when use poll mode on client side. [ Upstream commit 4b6afe9bc955bee44c0527005c3fb0edac91ac30 ] When testing with poll mode, it will fail and lead to warning below on client side: $ echo "sessname=bla path=gid:fe80::2:c903:4e:d0b3@gid:fe80::2:c903:8:ca17 device_path=/dev/nullb2 nr_poll_queues=-1" | \ sudo tee /sys/devices/virtual/rnbd-client/ctl/map_device rnbd_client L597: Mapping device /dev/nullb2 on session bla, (access_mode: rw, nr_poll_queues: 8) WARNING: CPU: 3 PID: 9886 at drivers/infiniband/core/cq.c:447 ib_cq_pool_get+0x26f/0x2a0 [ib_core] The problem is in case of poll queue, we need to still call ib_alloc_cq/ib_free_cq, we can't use cq_poll api for poll queue. As both client and server use shared function from rtrs, set irq_con_num to con_num on server side, which is number of total connection of the session, this way we can differ if the rtrs_con requires pollqueue. Following up patches will replace the duplicate code with helpers. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jack Wang <[email protected]> Reviewed-by: Gioh Kim <[email protected]> Signed-off-by: Md Haris Iqbal <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Wed Sep 22 14:53:31 2021 +0200 RDMA/rtrs: Introduce destroy_cq helper [ Upstream commit 6f5649afd3984e35c4b862a05c4511c6d18b27af ] The same code snip used twice, to avoid duplicate, replace it with a destroy_cq helper. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Md Haris Iqbal <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vaishali Thakkar <[email protected]> Date: Wed Jan 5 19:07:04 2022 +0100 RDMA/rtrs: Rename rtrs_sess to rtrs_path [ Upstream commit d9372794717f44b6e746d8fbab66763b6d753e71 ] rtrs_sess is in fact a path. This makes it confusing and difficult to get into the code. So let's rename the structure and related use cases of it. Coccinelle was used to do the transformation for most of the occurrences and remaining ones were handled manually. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vaishali Thakkar <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Wang <[email protected]> Date: Wed Sep 22 14:53:30 2021 +0200 RDMA/rtrs: Replace duplicate check with is_pollqueue helper [ Upstream commit 36332ded46b6292296bc7170fada6e238a0802cc ] if (con->cid >= con->sess->irq_con_num) check can be replaced with a is_pollqueue helper. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Md Haris Iqbal <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bob Pearson <[email protected]> Date: Tue Sep 14 11:42:03 2021 -0500 RDMA/rxe: Add memory barriers to kernel queues [ Upstream commit ae6e843fe08d0ea8e158815809dcc20e3a1afc22 ] Earlier patches added memory barriers to protect user space to kernel space communications. The user space queues were previously shown to have occasional memory synchonization errors which were removed by adding smp_load_acquire, smp_store_release barriers. This patch extends that to the case where queues are used between kernel space threads. This patch also extends the queue types to include kernel ULP queues which access the other end of the queues in kernel verbs calls like poll_cq and post_send/recv. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bob Pearson <[email protected]> Date: Mon May 23 17:32:52 2022 -0500 RDMA/rxe: Fix deadlock in rxe_do_local_ops() [ Upstream commit 7cb33d1bc1ac8e51fd88928f96674d392f8e07c4 ] When a local operation (invalidate mr, reg mr, bind mw) is finished there will be no ack packet coming from a responder to cause the wqe to be completed. This may happen anyway if a subsequent wqe performs IO. Currently if the wqe is signalled the completer tasklet is scheduled immediately but not otherwise. This leads to a deadlock if the next wqe has the fence bit set in send flags and the operation is not signalled. This patch removes the condition that the wqe must be signalled in order to schedule the completer tasklet which is the simplest fix for this deadlock and is fairly low cost. This is the analog for local operations of always setting the ackreq bit in all last or only request packets even if the operation is not signalled. Link: https://lore.kernel.org/r/[email protected] Reported-by: Jenny Hack <[email protected]> Fixes: c1a411268a4b ("RDMA/rxe: Move local ops to subroutine") Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhu Yanjun <[email protected]> Date: Sun Jul 31 02:36:21 2022 -0400 RDMA/rxe: Fix error unwind in rxe_create_qp() [ Upstream commit fd5382c5805c4bcb50fd25b7246247d3f7114733 ] In the function rxe_create_qp(), rxe_qp_from_init() is called to initialize qp, internally things like the spin locks are not setup until rxe_qp_init_req(). If an error occures before this point then the unwind will call rxe_cleanup() and eventually to rxe_qp_do_cleanup()/rxe_cleanup_task() which will oops when trying to access the uninitialized spinlock. Move the spinlock initializations earlier before any failures. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/[email protected] Reported-by: [email protected] Signed-off-by: Zhu Yanjun <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bob Pearson <[email protected]> Date: Thu Jul 14 15:46:20 2022 -0500 RDMA/rxe: Fix mw bind to allow any consumer key portion [ Upstream commit 1603f89935ec86d40a7667e1250392626976ccc2 ] The current implementation of rxe_check_bind_mw() in rxe_mw.c is incorrect since it requires the new key portion provided by the mw consumer to be different than the previous key portion. This is not required by the IBA. Remove the test. Link: https://lore.kernel.org/linux-rdma/[email protected]/ Fixes: 32a577b4c3a9 ("Add support for bind MW work requests") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Md Haris Iqbal <[email protected]> Date: Thu Jul 7 09:30:06 2022 +0200 RDMA/rxe: For invalidate compare according to set keys in mr [ Upstream commit 174e7b137042f19b5ce88beb4fc0ff4ec6b0c72a ] The 'rkey' input can be an lkey or rkey, and in rxe the lkey or rkey have the same value, including the variant bits. So, if mr->rkey is set, compare the invalidate key with it, otherwise compare with the mr->lkey. Since we already did a lookup on the non-varient bits to get this far, the check's only purpose is to confirm that the wqe has the correct variant bits. Fixes: 001345339f4c ("RDMA/rxe: Separate HW and SW l/rkeys") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Md Haris Iqbal <[email protected]> Reviewed-by: Bob Pearson <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiao Yang <[email protected]> Date: Thu Sep 30 17:48:10 2021 +0800 RDMA/rxe: Remove the is_user members of struct rxe_sq/rxe_rq/rxe_srq [ Upstream commit 1cf2ce8272802e677398fab47a73713bc6e1fd5c ] The is_user members of struct rxe_sq/rxe_rq/rxe_srq are unsed since commit ae6e843fe08d ("RDMA/rxe: Add memory barriers to kernel queues"). In this case, it is fine to remove them directly. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xiao Yang <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Cheng Xu <[email protected]> Date: Thu Jul 14 09:30:47 2022 +0800 RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event [ Upstream commit 3056fc6c32e613b760422b94c7617ac9a24a4721 ] If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY in this case. This may trigger a call trace in iw_cm. A simple way to trigger this: server: ib_send_lat client: ib_send_lat -R <server_ip> The call trace looks like this: kernel BUG at drivers/infiniband/core/iwcm.c:894! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <...> Workqueue: iw_cm_wq cm_work_handler [iw_cm] Call Trace: <TASK> cm_work_handler+0x1dd/0x370 [iw_cm] process_one_work+0x1e2/0x3b0 worker_thread+0x49/0x2e0 ? rescuer_thread+0x370/0x370 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Link: https://lore.kernel.org/r/dae34b5fd5c2ea2bd9744812c1d2653a34a94c67.1657706960.git.chengyou@linux.alibaba.com Signed-off-by: Cheng Xu <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Wed Jul 27 12:34:13 2022 -0700 RDMA/srpt: Duplicate port name members [ Upstream commit b03b1ae2a3125d4475452e4f19f5d3a6e910ff6e ] Prepare for decoupling the lifetimes of struct srpt_port and struct srpt_port_id by duplicating the port name into struct srpt_port. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Wed Jul 27 12:34:15 2022 -0700 RDMA/srpt: Fix a use-after-free [ Upstream commit b5605148e6ce36bb21020d49010b617693933128 ] Change the LIO port members inside struct srpt_port from regular members into pointers. Allocate the LIO port data structures from inside srpt_make_tport() and free these from inside srpt_make_tport(). Keep struct srpt_device as long as either an RDMA port or a LIO target port is associated with it. This patch decouples the lifetime of struct srpt_port (controlled by the RDMA core) and struct srpt_port_id (controlled by LIO). This patch fixes the following KASAN complaint: BUG: KASAN: use-after-free in srpt_enable_tpg+0x31/0x70 [ib_srpt] Read of size 8 at addr ffff888141cc34b8 by task check/5093 Call Trace: <TASK> show_stack+0x4e/0x53 dump_stack_lvl+0x51/0x66 print_address_description.constprop.0.cold+0xea/0x41e print_report.cold+0x90/0x205 kasan_report+0xb9/0xf0 __asan_load8+0x69/0x90 srpt_enable_tpg+0x31/0x70 [ib_srpt] target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod] configfs_write_iter+0x18b/0x210 new_sync_write+0x1f2/0x2f0 vfs_write+0x3e3/0x540 ksys_write+0xbb/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> Link: https://lore.kernel.org/r/[email protected] Reported-by: Li Zhijian <[email protected]> Tested-by: Li Zhijian <[email protected]> Fixes: a42d985bd5b2 ("ib_srpt: Initial SRP Target merge for v3.3-rc1") Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Wed Jul 27 12:34:14 2022 -0700 RDMA/srpt: Introduce a reference count in struct srpt_device [ Upstream commit aa7dfbb41b5a60ab90e244d6f586b8cb5c791c3e ] This will be used to keep struct srpt_device around as long as either the RDMA port exists or a LIO target port is associated with the struct srpt_device. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bart Van Assche <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liang He <[email protected]> Date: Fri Jul 15 19:10:27 2022 +0800 regulator: of: Fix refcount leak bug in of_get_regulation_constraints() [ Upstream commit 66efb665cd5ad69b27dca8571bf89fc6b9c628a4 ] We should call the of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 40e20d68bb3f ("regulator: of: Add support for parsing regulator_state for suspend state") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stephan Gerhold <[email protected]> Date: Thu Jun 23 11:46:12 2022 +0200 regulator: qcom_smd: Fix pm8916_pldo range [ Upstream commit e8977917e116d1571dacb8e9864474551c1c12bd ] The PM8916 device specification [1] documents a programmable range of 1.75V to 3.337V with 12.5mV steps for the PMOS LDOs in PM8916. This range is also used when controlling the regulator directly using the qcom_spmi-regulator driver ("ult_pldo" there). However, for some reason the qcom_smd-regulator driver allows a much larger range for the same hardware component. This could be simply a typo, since the start of the range is essentially just missing a '1'. In practice this does not cause any major problems, since the driver just sends the actual voltage to the RPM firmware instead of making use of the incorrect voltage selector. Still, having the wrong range there is confusing and prevents the regulator core from validating requests correctly. [1]: https://developer.qualcomm.com/download/sd410/pm8916pm8916-1-power-management-ic-device-specification.pdf Fixes: 57d6567680ed ("regulator: qcom-smd: Add PM8916 support") Signed-off-by: Stephan Gerhold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu May 12 08:55:58 2022 +0400 remoteproc: imx_rproc: Fix refcount leak in imx_rproc_addr_init [ Upstream commit 61afafe8b938bc74841cf4b1a73dd08b9d287c5a ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. This function has two paths missing of_node_put(). Fixes: 6e962bfe56b9 ("remoteproc: imx_rproc: add missing of_node_put") Fixes: a0ff4aa6f010 ("remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver") Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Sun Jun 5 12:33:34 2022 +0400 remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init [ Upstream commit fa220c05d282e7479abe08b54e3bdffd06c25e97 ] Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. When breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node. Add missing of_node_put() to avoid refcount leak. Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Miaoqian Lin <[email protected]> Acked-by: Suman Anna <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Siddharth Gupta <[email protected]> Date: Tue Jul 5 17:38:17 2022 +0530 remoteproc: qcom: pas: Check if coredump is enabled [ Upstream commit 7b6ece968fca4ec9e42d34caff7e06dc84c45717 ] Client drivers need to check if coredump is enabled for the rproc before continuing with coredump generation. This change adds a check in the PAS driver. Fixes: 8ed8485c4f05 ("remoteproc: qcom: Add capability to collect minidumps") Signed-off-by: Siddharth Gupta <[email protected]> Signed-off-by: Sibi Sankar <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sireesh Kodali <[email protected]> Date: Thu May 26 19:47:39 2022 +0530 remoteproc: qcom: wcnss: Fix handling of IRQs [ Upstream commit bed0adac1ded4cb486ba19a3a7e730fbd9a1c9c6 ] The wcnss_get_irq function is expected to return a value > 0 in the event that an IRQ is succssfully obtained, but it instead returns 0. This causes the stop and ready IRQs to never actually be used despite being defined in the device-tree. This patch fixes that. Fixes: aed361adca9f ("remoteproc: qcom: Introduce WCNSS peripheral image loader") Signed-off-by: Sireesh Kodali <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Sibi Sankar <[email protected]> Date: Tue Jul 5 17:38:19 2022 +0530 remoteproc: sysmon: Wait for SSCTL service to come up [ Upstream commit 47c04e00eff86a81cd357c3feed04c86089bcb85 ] The SSCTL service comes up after a finite time when the remote Q6 comes out of reset. Any graceful shutdowns requested during this period will be a NOP and abrupt tearing down of the glink channel might lead to pending transactions on the remote Q6 side and will ultimately lead to a fatal error. Fix this by waiting for the SSCTL service when a graceful shutdown is requested. Fixes: 1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon") Reviewed-by: Matthias Kaehlcke <[email protected]> Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Mon Jun 27 16:35:59 2022 +0200 Revert "mwifiex: fix sleep in atomic context bugs caused by dev_coredumpv" commit 5f8954e099b8ae96e7de1bb95950e00c85bedd40 upstream. This reverts commit a52ed4866d2b90dd5e4ae9dabd453f3ed8fa3cbc as it causes build problems in linux-next. It needs to be reintroduced in a way that can allow the api to evolve and not require a "flag day" to catch all users. Link: https://lore.kernel.org/r/[email protected] Cc: Duoming Zhou <[email protected]> Cc: Brian Norris <[email protected]> Cc: Johannes Berg <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jose Alonso <[email protected]> Date: Mon Aug 8 08:35:04 2022 -0300 Revert "net: usb: ax88179_178a needs FLAG_SEND_ZLP" commit 6fd2c17fb6e02a8c0ab51df1cfec82ce96b8e83d upstream. This reverts commit 36a15e1cb134c0395261ba1940762703f778438c. The usage of FLAG_SEND_ZLP causes problems to other firmware/hardware versions that have no issues. The FLAG_SEND_ZLP is not safe to use in this context. See: https://patchwork.ozlabs.org/project/netdev/patch/1270599787.8900.8.camel@Linuxdev4-laptop/#118378 The original problem needs another way to solve. Fixes: 36a15e1cb134 ("net: usb: ax88179_178a needs FLAG_SEND_ZLP") Cc: [email protected] Reported-by: Ronald Wahl <[email protected]> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216327 Link: https://bugs.archlinux.org/task/75491 Signed-off-by: Jose Alonso <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Wed May 18 16:37:56 2022 -0400 Revert "pNFS: nfs3_set_ds_client should set NFS_CS_NOPING" commit 9597152d98840c2517230740952df97cfcc07e2f upstream. This reverts commit c6eb58435b98bd843d3179664a0195ff25adb2c3. If a transport is down, then we want to fail over to other transports if they are listed in the GETDEVICEINFO reply. Fixes: c6eb58435b98 ("pNFS: nfs3_set_ds_client should set NFS_CS_NOPING") Cc: [email protected] # 5.11.x Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Sat Aug 6 09:29:46 2022 +0200 Revert "s390/smp: enforce lowcore protection on CPU restart" commit 953503751a426413ea8aee2299ae3ee971b70d9b upstream. This reverts commit 6f5c672d17f583b081e283927f5040f726c54598. This breaks normal crash dump when CPU0 is offline. Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xianting Tian <[email protected]> Date: Thu Aug 11 15:41:48 2022 +0800 RISC-V: Add modules to virtual kernel memory layout dump commit f9293ad46d8ba9909187a37b7215324420ad4596 upstream. Modules always live before the kernel, MODULES_END is fixed but MODULES_VADDR isn't fixed, it depends on the kernel size. Let's add it to virtual kernel memory layout dump. As MODULES is only defined for CONFIG_64BIT, so we dump it when CONFIG_64BIT=y. eg, MODULES_VADDR - MODULES_END 0xffffffff01133000 - 0xffffffff80000000 Reviewed-by: Guo Ren <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Xianting Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping") Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xianting Tian <[email protected]> Date: Thu Aug 11 15:41:46 2022 +0800 RISC-V: Fixup get incorrect user mode PC for kernel mode regs commit 59c026c359c30f116fef6ee958e24d04983efbb0 upstream. When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs() will be called to save regs for vmcore, we found "epc" value 00ffffffa5537400 is not a valid kernel virtual address, but is a user virtual address. Other regs(eg, ra, sp, gp...) are correct kernel virtual address. Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which is saved in the task's stack. [ 21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45 [ 21.201979] Hardware name: riscv-virtio,qemu (DT) [ 21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90 [ 21.202435] gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c [ 21.202707] t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0 [ 21.202973] s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001 [ 21.203243] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00 [ 21.203519] a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8 [ 21.203794] s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98 [ 21.204062] s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468 [ 21.204331] s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700 [ 21.204606] s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00 [ 21.204876] t5 : ff60000001218000 t6 : ff200000103338b8 [ 21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008 With the incorrect PC, the backtrace showed by crash tool as below, the first stack frame is abnormal, crash> bt PID: 113 TASK: ff60000002269600 CPU: 0 COMMAND: "sh" #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal #1 [ff2000001039bcf0] panic at ffffffff806578ba #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030 #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8 #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8 #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc #6 [ff2000001039be40] vfs_write at ffffffff80152ba6 #7 [ff2000001039be80] ksys_write at ffffffff80152ece #8 [ff2000001039bed0] sys_write at ffffffff80152f46 With the patch, we can get current kernel mode PC, the output as below, [ 17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42 [ 17.607937] Hardware name: riscv-virtio,qemu (DT) [ 17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90 [ 17.608441] gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68 [ 17.608741] t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0 [ 17.609025] s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001 [ 17.609320] a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000 [ 17.609601] a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4 [ 17.609894] s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98 [ 17.610186] s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468 [ 17.610469] s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700 [ 17.610755] s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00 [ 17.611041] t5 : ff60000001218000 t6 : ff20000010333988 [ 17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008 With the correct PC, the backtrace showed by crash tool as below, crash> bt PID: 113 TASK: ff6000000226c200 CPU: 0 COMMAND: "sh" #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal #1 [ff20000010333cf0] panic at ffffffff806578c6 #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604 #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4 #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8 #6 [ff20000010333e40] vfs_write at ffffffff80152bb2 #7 [ff20000010333e80] ksys_write at ffffffff80152eda #8 [ff20000010333ed0] sys_write at ffffffff80152f52 Fixes: e53d28180d4d ("RISC-V: Add kdump support") Co-developed-by: Guo Ren <[email protected]> Signed-off-by: Xianting Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xianting Tian <[email protected]> Date: Thu Aug 11 15:41:47 2022 +0800 RISC-V: Fixup schedule out issue in machine_crash_shutdown() commit ad943893d5f1d0aeea892bf7b781cf8062b36d58 upstream. Current task of executing crash kexec will be schedule out when panic is triggered by RCU Stall, as it needs to wait rcu completion. It lead to inability to enter the crash system. The implementation of machine_crash_shutdown() is non-standard for RISC-V according to other Arch's implementation(eg, x86, arm64), we need to send IPI to stop secondary harts. [224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [224521.883471] rcu: 0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793 fqs=2495 [224521.891742] (detected by 2, t=5255 jiffies, g=60855593, q=328) [224521.897754] Task dump for CPU 0: [224521.901074] task:swapper/0 state:R running task stack: 0 pid: 0 ppid: 0 flags:0x00000008 [224521.911090] Call Trace: [224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea [224521.918957] Kernel panic - not syncing: RCU Stall [224521.923773] bad: scheduling from the idle thread! [224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G O 5.10.113-yocto-standard #1 [224521.938658] Call Trace: [224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa [224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e [224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2 [224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c [224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40 [224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea [224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4 [224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170 [224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2 [224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a [224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66 [224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6 [224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c [224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a [224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118 [224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a [224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6 [224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6 [224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8 [224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a [224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102 [224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318 [224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228 [224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48 [224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c [224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122 [224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60 [224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc [224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8 With the patch, it can enter crash system when RCU Stall occur. Fixes: e53d28180d4d ("RISC-V: Add kdump support") Signed-off-by: Xianting Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xianting Tian <[email protected]> Date: Thu Aug 11 15:41:45 2022 +0800 RISC-V: kexec: Fixup use of smp_processor_id() in preemptible context commit 357628e68f5c08ad578a718dc62a0031e06dbe91 upstream. Use __smp_processor_id() to avoid check the preemption context when CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no return. Without the patch, [ 103.781044] sysrq: Trigger a crash [ 103.784625] Kernel panic - not syncing: sysrq triggered crash [ 103.837634] CPU1: off [ 103.889668] CPU2: off [ 103.933479] CPU3: off [ 103.939424] Starting crashdump kernel... [ 103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346 [ 103.950884] caller is debug_smp_processor_id+0x1c/0x26 [ 103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted 5.10.113-00002-gce03f03bf4ec-dirty #149 [ 103.965355] Call Trace: [ 103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2 [ 103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e [ 103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e [ 103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c [ 103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa [ 103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26 [ 104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0 [ 104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4 [ 104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0 [ 104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70 [ 104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154 [ 104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a [ 104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4 [ 104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254 [ 104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe [ 104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16 [ 104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2 [ 104.067863] Will call new kernel at ecc00000 from hart id 0 [ 104.074939] FDT image at fc5ee000 [ 104.079523] Bye... With the patch we can got clear output, [ 67.740553] sysrq: Trigger a crash [ 67.744166] Kernel panic - not syncing: sysrq triggered crash [ 67.809123] CPU1: off [ 67.865210] CPU2: off [ 67.909075] CPU3: off [ 67.919123] Starting crashdump kernel... [ 67.924900] Will call new kernel at ecc00000 from hart id 0 [ 67.932045] FDT image at fc5ee000 [ 67.935560] Bye... Fixes: 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec") Reviewed-by: Guo Ren <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Reviewed-by: Atish Patra <[email protected]> Signed-off-by: Xianting Tian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dimitri John Ledkov <[email protected]> Date: Tue Sep 7 01:28:47 2021 +0100 riscv: set default pm_power_off to NULL commit f2928e224d85e7cc139009ab17cefdfec2df5d11 upstream. Set pm_power_off to NULL like on all other architectures, check if it is set in machine_halt() and machine_power_off() and fallback to default_power_off if no other power driver got registered. This brings riscv architecture inline with all other architectures, and allows to reuse exiting power drivers unmodified. Kernels without legacy SBI v0.1 extensions (CONFIG_RISCV_SBI_V01 is not set), do not set pm_power_off to sbi_shutdown(). There is no support for SBI v0.3 system reset extension either. This prevents using gpio_poweroff on SiFive HiFive Unmatched. Tested on SiFive HiFive unmatched, with a dtb specifying gpio-poweroff node and kernel complied without CONFIG_RISCV_SBI_V01. BugLink: https://bugs.launchpad.net/bugs/1942806 Signed-off-by: Dimitri John Ledkov <[email protected]> Reviewed-by: Anup Patel <[email protected]> Tested-by: Ron Economos <[email protected]> Signed-off-by: Palmer Dabbelt <[email protected]> Cc: Nathan Chancellor <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yipeng Zou <[email protected]> Date: Thu Jul 21 14:58:20 2022 +0800 riscv:uprobe fix SR_SPIE set/clear handling commit 3dbe5829408bc1586f75b4667ef60e5aab0209c7 upstream. In riscv the process of uprobe going to clear spie before exec the origin insn,and set spie after that.But When access the page which origin insn has been placed a page fault may happen and irq was disabled in arch_uprobe_pre_xol function,It cause a WARN as follows. There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol. We can just remove it. [ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488 [ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work [ 31.684929] preempt_count: 0, expected: 0 [ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G [ 31.686542] Hardware name: riscv-virtio,qemu (DT) [ 31.686797] Call Trace: [ 31.687053] [<ffffffff80006442>] dump_backtrace+0x30/0x38 [ 31.687699] [<ffffffff80812118>] show_stack+0x40/0x4c [ 31.688141] [<ffffffff8081817a>] dump_stack_lvl+0x44/0x5c [ 31.688396] [<ffffffff808181aa>] dump_stack+0x18/0x20 [ 31.688653] [<ffffffff8003e454>] __might_resched+0x114/0x122 [ 31.688948] [<ffffffff8003e4b2>] __might_sleep+0x50/0x7a [ 31.689435] [<ffffffff80822676>] down_read+0x30/0x130 [ 31.689728] [<ffffffff8000b650>] do_page_fault+0x166/x446 [ 31.689997] [<ffffffff80003c0c>] ret_from_exception+0x0/0xc Fixes: 74784081aac8 ("riscv: Add uprobes supported") Signed-off-by: Yipeng Zou <[email protected]> Reviewed-by: Guo Ren <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Palmer Dabbelt <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Shengjiu Wang <[email protected]> Date: Sat May 21 11:35:05 2022 +0800 rpmsg: char: Add mutex protection for rpmsg_eptdev_open() [ Upstream commit abe13e9a561d6b3e82b21362c0d6dd3ecd8a5b13 ] There is no mutex protection for rpmsg_eptdev_open(), especially for eptdev->ept read and write operation. It may cause issues when multiple instances call rpmsg_eptdev_open() in parallel,the return state may be success or EBUSY. Fixes: 964e8bedd5a1 ("rpmsg: char: Return an error if device already open") Signed-off-by: Shengjiu Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Wed May 25 11:12:01 2022 +0200 rpmsg: mtk_rpmsg: Fix circular locking dependency [ Upstream commit 353d9214682e65c55cdffad8c82139a3321c5f13 ] During execution of the worker that's used to register rpmsg devices we are safely locking the channels mutex but, when creating a new endpoint for such devices, we are registering a IPI on the SCP, which then makes the SCP to trigger an interrupt, lock its own mutex and in turn register more subdevices. This creates a circular locking dependency situation, as the mtk_rpmsg channels_lock will then depend on the SCP IPI lock. [ 15.447736] ====================================================== [ 15.460158] WARNING: possible circular locking dependency detected [ 15.460161] 5.17.0-next-20220324+ #399 Not tainted [ 15.460165] ------------------------------------------------------ [ 15.460166] kworker/0:3/155 is trying to acquire lock: [ 15.460170] ffff5b4d0eaf1308 (&scp->ipi_desc[i].lock){+.+.}-{4:4}, at: scp_ipi_lock+0x34/0x50 [mtk_scp_ipi] [ 15.504958] [] but task is already holding lock: [ 15.504960] ffff5b4d0e8f1918 (&mtk_subdev->channels_lock){+.+.}-{4:4}, at: mtk_register_device_work_function+0x50/0x1cc [mtk_rpmsg] [ 15.504978] [] which lock already depends on the new lock. [ 15.504980] [] the existing dependency chain (in reverse order) is: [ 15.504982] [] -> #1 (&mtk_subdev->channels_lock){+.+.}-{4:4}: [ 15.504990] lock_acquire+0x68/0x84 [ 15.504999] __mutex_lock+0xa4/0x3e0 [ 15.505007] mutex_lock_nested+0x40/0x70 [ 15.505012] mtk_rpmsg_ns_cb+0xe4/0x134 [mtk_rpmsg] [ 15.641684] mtk_rpmsg_ipi_handler+0x38/0x64 [mtk_rpmsg] [ 15.641693] scp_ipi_handler+0xbc/0x180 [mtk_scp] [ 15.663905] mt8192_scp_irq_handler+0x44/0xa4 [mtk_scp] [ 15.663915] scp_irq_handler+0x6c/0xa0 [mtk_scp] [ 15.685779] irq_thread_fn+0x34/0xa0 [ 15.685785] irq_thread+0x18c/0x240 [ 15.685789] kthread+0x104/0x110 [ 15.709579] ret_from_fork+0x10/0x20 [ 15.709586] [] -> #0 (&scp->ipi_desc[i].lock){+.+.}-{4:4}: [ 15.731271] __lock_acquire+0x11e4/0x1910 [ 15.740367] lock_acquire.part.0+0xd8/0x220 [ 15.749813] lock_acquire+0x68/0x84 [ 15.757861] __mutex_lock+0xa4/0x3e0 [ 15.766084] mutex_lock_nested+0x40/0x70 [ 15.775006] scp_ipi_lock+0x34/0x50 [mtk_scp_ipi] [ 15.785503] scp_ipi_register+0x40/0xa4 [mtk_scp_ipi] [ 15.796697] scp_register_ipi+0x1c/0x30 [mtk_scp] [ 15.807194] mtk_rpmsg_create_ept+0xa0/0x108 [mtk_rpmsg] [ 15.818912] rpmsg_create_ept+0x44/0x60 [ 15.827660] cros_ec_rpmsg_probe+0x15c/0x1f0 [ 15.837282] rpmsg_dev_probe+0x128/0x1d0 [ 15.846203] really_probe.part.0+0xa4/0x2a0 [ 15.855649] __driver_probe_device+0xa0/0x150 [ 15.865443] driver_probe_device+0x48/0x150 [ 15.877157] __device_attach_driver+0xc0/0x12c [ 15.889359] bus_for_each_drv+0x80/0xe0 [ 15.900330] __device_attach+0xe4/0x190 [ 15.911303] device_initial_probe+0x1c/0x2c [ 15.922969] bus_probe_device+0xa8/0xb0 [ 15.933927] device_add+0x3a8/0x8a0 [ 15.944193] device_register+0x28/0x40 [ 15.954970] rpmsg_register_device+0x5c/0xa0 [ 15.966782] mtk_register_device_work_function+0x148/0x1cc [mtk_rpmsg] [ 15.983146] process_one_work+0x294/0x664 [ 15.994458] worker_thread+0x7c/0x45c [ 16.005069] kthread+0x104/0x110 [ 16.014789] ret_from_fork+0x10/0x20 [ 16.025201] [] other info that might help us debug this: [ 16.047769] Possible unsafe locking scenario: [ 16.063942] CPU0 CPU1 [ 16.075166] ---- ---- [ 16.086376] lock(&mtk_subdev->channels_lock); [ 16.097592] lock(&scp->ipi_desc[i].lock); [ 16.113188] lock(&mtk_subdev->channels_lock); [ 16.129482] lock(&scp->ipi_desc[i].lock); [ 16.140020] [] *** DEADLOCK *** [ 16.158282] 4 locks held by kworker/0:3/155: [ 16.168978] #0: ffff5b4d00008748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1fc/0x664 [ 16.190017] #1: ffff80000953bdc8 ((work_completion)(&mtk_subdev->register_work)){+.+.}-{0:0}, at: process_one_work+0x1fc/0x664 [ 16.215269] #2: ffff5b4d0e8f1918 (&mtk_subdev->channels_lock){+.+.}-{4:4}, at: mtk_register_device_work_function+0x50/0x1cc [mtk_rpmsg] [ 16.242131] #3: ffff5b4d05964190 (&dev->mutex){....}-{4:4}, at: __device_attach+0x44/0x190 To solve this, simply unlock the channels_lock mutex before calling mtk_rpmsg_register_device() and relock it right after, as safety is still ensured by the locking mechanism that happens right after through SCP. Fixes: 7017996951fd ("rpmsg: add rpmsg support for mt8183 SCP.") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Wed May 11 16:07:37 2022 +0400 rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge [ Upstream commit 65382585f067d4256ba087934f30f85c9b6984de ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mathew McBride <[email protected]> Date: Wed Jul 6 07:42:36 2022 +0000 rtc: rx8025: fix 12/24 hour mode detection on RX-8035 commit 71af91565052214ad86f288e0d8ffb165f790995 upstream. The 12/24hr flag in the RX-8035 can be found in the hour register, instead of the CTRL1 on the RX-8025. This was overlooked when support for the RX-8035 was added, and was causing read errors when the hour register 'overflowed'. To deal with the relevant register not always being visible in the relevant functions, determine the 12/24 mode at startup and store it in the driver state. Signed-off-by: Mathew McBride <[email protected]> Fixes: f120e2e33ac8 ("rtc: rx8025: implement RX-8035 support") Cc: [email protected] Signed-off-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Fri Jul 15 12:59:33 2022 +0200 s390/crash: fix incorrect number of bytes to copy to user space [ Upstream commit f6749da17a34eb08c9665f072ce7c812ff68aad2 ] The number of bytes in a chunk is correctly calculated, but instead the total number of bytes is passed to copy_to_user_real() function. Reported-by: Matthew Wilcox <[email protected]> Fixes: df9694c7975f ("s390/dump: streamline oldmem copy functions") Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Sat Jan 29 08:38:56 2022 +0100 s390/dump: fix old lowcore virtual vs physical address confusion [ Upstream commit dc306186a130c6d9feb0aabc1c71b8ed1674a3bf ] Virtual addresses of vmcore_info and os_info members are wrongly passed to copy_oldmem_kernel(), while the function expects physical address of the source. Instead, __pa() macro should have been applied. Yet, use of __pa() macro could be somehow confusing, since copy_oldmem_kernel() may treat the source as an offset, not as a direct physical address (that depens from the oldmem availability and location). Fix the virtual vs physical address confusion and make the way the old lowcore is read consistent across all sources. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Wed Jan 26 13:47:59 2022 +0100 s390/dump: fix os_info virtual vs physical address confusion [ Upstream commit 9de209c7d584d6e06ad92f120d83d4f27c200497 ] Due to historical reasons os_info handling functions misuse the notion of physical vs virtual addresses difference. Note: this does not fix a bug currently, since virtual and physical addresses are identical. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Sat Jan 29 09:24:50 2022 +0100 s390/maccess: fix semantics of memcpy_real() and its callers [ Upstream commit 303fd988ed644c7daa260410f3ac99266573557d ] There is a confusion with regard to the source address of memcpy_real() and calling functions. While the declared type for a source assumes a virtual address, in fact it always called with physical address of the source. This confusion led to bugs in copy_oldmem_kernel() and copy_oldmem_user() functions, where __pa() macro applied mistakenly to physical addresses. It does not lead to a real issue, since virtual and physical addresses are currently the same. Fix both the bugs and memcpy_real() prototype by making type of source address consistent to the function name and the way it actually used. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Thu Mar 17 15:03:03 2022 +0100 s390/maccess: rework absolute lowcore accessors [ Upstream commit ed0192bc644f3553d64a5cb461bdd0b1fbae3fdf ] Macro mem_assign_absolute() is able to access the whole memory, but is only used and makes sense when updating the absolute lowcore. Instead, introduce get_abs_lowcore() and put_abs_lowcore() macros that limit access to absolute lowcore addresses only. Suggested-by: Heiko Carstens <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Thu Mar 17 15:03:02 2022 +0100 s390/smp: cleanup control register update routines [ Upstream commit 9097fc793f74ef9c677f8c4aed0c24f6f07f0133 ] Get rid of duplicate code and redundant data. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Thu Mar 17 15:03:01 2022 +0100 s390/smp: cleanup target CPU callback starting [ Upstream commit dc2ab23b992c9d5dab93b9bf01b10b10465e537e ] Macro mem_assign_absolute() is used to initialize a target CPU lowcore callback parameters. But despite the macro name it writes to the absolute lowcore only if the target CPU is offline. In case the CPU is online the macro does implicitly write to the normal memory. That behaviour is correct, but extremely subtle. Sacrifice few program bits in favour of clarity and distinguish between online vs offline CPUs and normal vs absolute lowcore pointer. Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Wed Jul 20 07:24:03 2022 +0200 s390/smp: enforce lowcore protection on CPU restart [ Upstream commit 6f5c672d17f583b081e283927f5040f726c54598 ] As result of commit 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called") the low-address protection bit gets mistakenly unset in control register 0 save area of the absolute zero memory. That area is used when manual PSW restart happened to hit an offline CPU. In this case the low-address protection for that CPU will be dropped. Reviewed-by: Heiko Carstens <[email protected]> Fixes: 915fea04f932 ("s390/smp: enable DAT before CPU restart callback is called") Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Gordeev <[email protected]> Date: Tue Jul 19 07:16:33 2022 +0200 s390/zcore: fix race when reading from hardware system area [ Upstream commit 9ffed254d938c9e99eb7761c7f739294c84e0367 ] Memory buffer used for reading out data from hardware system area is not protected against concurrent access. Reported-by: Matthew Wilcox <[email protected]> Fixes: 411ed3225733 ("[S390] zfcpdump support.") Acked-by: Heiko Carstens <[email protected]> Tested-by: Alexander Egorenkov <[email protected]> Link: https://lore.kernel.org/r/e68137f0f9a0d2558f37becc20af18e2939934f6.1658206891.git.agordeev@linux.ibm.com Signed-off-by: Alexander Gordeev <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Waiman Long <[email protected]> Date: Tue Aug 2 21:54:51 2022 -0400 sched, cpuset: Fix dl_cpu_busy() panic due to empty cs->cpus_allowed [ Upstream commit b6e8d40d43ae4dec00c8fea2593eeea3114b8f44 ] With cgroup v2, the cpuset's cpus_allowed mask can be empty indicating that the cpuset will just use the effective CPUs of its parent. So cpuset_can_attach() can call task_can_attach() with an empty mask. This can lead to cpumask_any_and() returns nr_cpu_ids causing the call to dl_bw_of() to crash due to percpu value access of an out of bound CPU value. For example: [80468.182258] BUG: unable to handle page fault for address: ffffffff8b6648b0 : [80468.191019] RIP: 0010:dl_cpu_busy+0x30/0x2b0 : [80468.207946] Call Trace: [80468.208947] cpuset_can_attach+0xa0/0x140 [80468.209953] cgroup_migrate_execute+0x8c/0x490 [80468.210931] cgroup_update_dfl_csses+0x254/0x270 [80468.211898] cgroup_subtree_control_write+0x322/0x400 [80468.212854] kernfs_fop_write_iter+0x11c/0x1b0 [80468.213777] new_sync_write+0x11f/0x1b0 [80468.214689] vfs_write+0x1eb/0x280 [80468.215592] ksys_write+0x5f/0xe0 [80468.216463] do_syscall_64+0x5c/0x80 [80468.224287] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix that by using effective_cpus instead. For cgroup v1, effective_cpus is the same as cpus_allowed. For v2, effective_cpus is the real cpumask to be used by tasks within the cpuset anyway. Also update task_can_attach()'s 2nd argument name to cs_effective_cpus to reflect the change. In addition, a check is added to task_can_attach() to guard against the possibility that cpumask_any_and() may return a value >= nr_cpu_ids. Fixes: 7f51412a415d ("sched/deadline: Fix bandwidth check/update when migrating tasks between exclusive cpusets") Signed-off-by: Waiman Long <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Juri Lelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: John Keeping <[email protected]> Date: Fri Jul 8 17:27:02 2022 +0100 sched/core: Always flush pending blk_plug [ Upstream commit 401e4963bf45c800e3e9ea0d3a0289d738005fd4 ] With CONFIG_PREEMPT_RT, it is possible to hit a deadlock between two normal priority tasks (SCHED_OTHER, nice level zero): INFO: task kworker/u8:0:8 blocked for more than 491 seconds. Not tainted 5.15.49-rt46 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack: 0 pid: 8 ppid: 2 flags:0x00000000 Workqueue: writeback wb_workfn (flush-7:0) [<c08a3a10>] (__schedule) from [<c08a3d84>] (schedule+0xdc/0x134) [<c08a3d84>] (schedule) from [<c08a65a0>] (rt_mutex_slowlock_block.constprop.0+0xb8/0x174) [<c08a65a0>] (rt_mutex_slowlock_block.constprop.0) from [<c08a6708>] +(rt_mutex_slowlock.constprop.0+0xac/0x174) [<c08a6708>] (rt_mutex_slowlock.constprop.0) from [<c0374d60>] (fat_write_inode+0x34/0x54) [<c0374d60>] (fat_write_inode) from [<c0297304>] (__writeback_single_inode+0x354/0x3ec) [<c0297304>] (__writeback_single_inode) from [<c0297998>] (writeback_sb_inodes+0x250/0x45c) [<c0297998>] (writeback_sb_inodes) from [<c0297c20>] (__writeback_inodes_wb+0x7c/0xb8) [<c0297c20>] (__writeback_inodes_wb) from [<c0297f24>] (wb_writeback+0x2c8/0x2e4) [<c0297f24>] (wb_writeback) from [<c0298c40>] (wb_workfn+0x1a4/0x3e4) [<c0298c40>] (wb_workfn) from [<c0138ab8>] (process_one_work+0x1fc/0x32c) [<c0138ab8>] (process_one_work) from [<c0139120>] (worker_thread+0x22c/0x2d8) [<c0139120>] (worker_thread) from [<c013e6e0>] (kthread+0x16c/0x178) [<c013e6e0>] (kthread) from [<c01000fc>] (ret_from_fork+0x14/0x38) Exception stack(0xc10e3fb0 to 0xc10e3ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 INFO: task tar:2083 blocked for more than 491 seconds. Not tainted 5.15.49-rt46 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:tar state:D stack: 0 pid: 2083 ppid: 2082 flags:0x00000000 [<c08a3a10>] (__schedule) from [<c08a3d84>] (schedule+0xdc/0x134) [<c08a3d84>] (schedule) from [<c08a41b0>] (io_schedule+0x14/0x24) [<c08a41b0>] (io_schedule) from [<c08a455c>] (bit_wait_io+0xc/0x30) [<c08a455c>] (bit_wait_io) from [<c08a441c>] (__wait_on_bit_lock+0x54/0xa8) [<c08a441c>] (__wait_on_bit_lock) from [<c08a44f4>] (out_of_line_wait_on_bit_lock+0x84/0xb0) [<c08a44f4>] (out_of_line_wait_on_bit_lock) from [<c0371fb0>] (fat_mirror_bhs+0xa0/0x144) [<c0371fb0>] (fat_mirror_bhs) from [<c0372a68>] (fat_alloc_clusters+0x138/0x2a4) [<c0372a68>] (fat_alloc_clusters) from [<c0370b14>] (fat_alloc_new_dir+0x34/0x250) [<c0370b14>] (fat_alloc_new_dir) from [<c03787c0>] (vfat_mkdir+0x58/0x148) [<c03787c0>] (vfat_mkdir) from [<c0277b60>] (vfs_mkdir+0x68/0x98) [<c0277b60>] (vfs_mkdir) from [<c027b484>] (do_mkdirat+0xb0/0xec) [<c027b484>] (do_mkdirat) from [<c0100060>] (ret_fast_syscall+0x0/0x1c) Exception stack(0xc2e1bfa8 to 0xc2e1bff0) bfa0: 01ee42f0 01ee4208 01ee42f0 000041ed 00000000 00004000 bfc0: 01ee42f0 01ee4208 00000000 00000027 01ee4302 00000004 000dcb00 01ee4190 bfe0: 000dc368 bed11924 0006d4b0 b6ebddfc Here the kworker is waiting on msdos_sb_info::s_lock which is held by tar which is in turn waiting for a buffer which is locked waiting to be flushed, but this operation is plugged in the kworker. The lock is a normal struct mutex, so tsk_is_pi_blocked() will always return false on !RT and thus the behaviour changes for RT. It seems that the intent here is to skip blk_flush_plug() in the case where a non-preemptible lock (such as a spinlock) has been converted to a rtmutex on RT, which is the case covered by the SM_RTLOCK_WAIT schedule flag. But sched_submit_work() is only called from schedule() which is never called in this scenario, so the check can simply be deleted. Looking at the history of the -rt patchset, in fact this change was present from v5.9.1-rt20 until being dropped in v5.13-rt1 as it was part of a larger patch [1] most of which was replaced by commit b4bfa3fcfe3b ("sched/core: Rework the __schedule() preempt argument"). As described in [1]: The schedule process must distinguish between blocking on a regular sleeping lock (rwsem and mutex) and a RT-only sleeping lock (spinlock and rwlock): - rwsem and mutex must flush block requests (blk_schedule_flush_plug()) even if blocked on a lock. This can not deadlock because this also happens for non-RT. There should be a warning if the scheduling point is within a RCU read section. - spinlock and rwlock must not flush block requests. This will deadlock if the callback attempts to acquire a lock which is already acquired. Similarly to being preempted, there should be no warning if the scheduling point is within a RCU read section. and with the tsk_is_pi_blocked() in the scheduler path, we hit the first issue. [1] https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/0022-locking-rtmutex-Use-custom-scheduling-function-for-s.patch?h=linux-5.10.y-rt-patches Signed-off-by: John Keeping <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Steven Rostedt (Google) <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mel Gorman <[email protected]> Date: Thu Aug 4 10:21:19 2022 +0100 sched/core: Do not requeue task on CPU excluded from cpus_mask [ Upstream commit 751d4cbc43879229dbc124afefe240b70fd29a85 ] The following warning was triggered on a large machine early in boot on a distribution kernel but the same problem should also affect mainline. WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440 Call Trace: <TASK> rescuer_thread+0x1f6/0x360 kthread+0x156/0x180 ret_from_fork+0x22/0x30 </TASK> Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") optimises ttwu by queueing a task that is descheduling on the wakelist, but does not check if the task descheduling is still allowed to run on that CPU. In this warning, the problematic task is a workqueue rescue thread which checks if the rescue is for a per-cpu workqueue and running on the wrong CPU. While this is early in boot and it should be possible to create workers, the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue thread is being used frequently. Tracing confirmed that the task should have migrated properly using the stopper thread to handle the migration. However, a parallel wakeup from udev running on another CPU that does not share CPU cache observes p->on_cpu and uses task_cpu(p), queues the task on the old CPU and triggers the warning. Check that the wakee task that is descheduling is still allowed to run on its current CPU and if not, wait for the descheduling to complete and select an allowed CPU. Fixes: c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu") Signed-off-by: Mel Gorman <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dietmar Eggemann <[email protected]> Date: Wed Mar 2 19:34:30 2022 +0100 sched/deadline: Merge dl_task_can_attach() and dl_cpu_busy() [ Upstream commit 772b6539fdda31462cc08368e78df60b31a58bab ] Both functions are doing almost the same, that is checking if admission control is still respected. With exclusive cpusets, dl_task_can_attach() checks if the destination cpuset (i.e. its root domain) has enough CPU capacity to accommodate the task. dl_cpu_busy() checks if there is enough CPU capacity in the cpuset in case the CPU is hot-plugged out. dl_task_can_attach() is used to check if a task can be admitted while dl_cpu_busy() is used to check if a CPU can be hotplugged out. Make dl_cpu_busy() able to deal with a task and use it instead of dl_task_can_attach() in task_can_attach(). Signed-off-by: Dietmar Eggemann <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Acked-by: Juri Lelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Yu <[email protected]> Date: Mon Jun 13 00:34:28 2022 +0800 sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg [ Upstream commit 70fb5ccf2ebb09a0c8ebba775041567812d45f86 ] [Problem Statement] select_idle_cpu() might spend too much time searching for an idle CPU, when the system is overloaded. The following histogram is the time spent in select_idle_cpu(), when running 224 instances of netperf on a system with 112 CPUs per LLC domain: @usecs: [0] 533 | | [1] 5495 | | [2, 4) 12008 | | [4, 8) 239252 | | [8, 16) 4041924 |@@@@@@@@@@@@@@ | [16, 32) 12357398 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [32, 64) 14820255 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [64, 128) 13047682 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [128, 256) 8235013 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [256, 512) 4507667 |@@@@@@@@@@@@@@@ | [512, 1K) 2600472 |@@@@@@@@@ | [1K, 2K) 927912 |@@@ | [2K, 4K) 218720 | | [4K, 8K) 98161 | | [8K, 16K) 37722 | | [16K, 32K) 6715 | | [32K, 64K) 477 | | [64K, 128K) 7 | | netperf latency usecs: ======= case load Lat_99th std% TCP_RR thread-224 257.39 ( 0.21) The time spent in select_idle_cpu() is visible to netperf and might have a negative impact. [Symptom analysis] The patch [1] from Mel Gorman has been applied to track the efficiency of select_idle_sibling. Copy the indicators here: SIS Search Efficiency(se_eff%): A ratio expressed as a percentage of runqueues scanned versus idle CPUs found. A 100% efficiency indicates that the target, prev or recent CPU of a task was idle at wakeup. The lower the efficiency, the more runqueues were scanned before an idle CPU was found. SIS Domain Search Efficiency(dom_eff%): Similar, except only for the slower SIS patch. SIS Fast Success Rate(fast_rate%): Percentage of SIS that used target, prev or recent CPUs. SIS Success rate(success_rate%): Percentage of scans that found an idle CPU. The test is based on Aubrey's schedtests tool, including netperf, hackbench, schbench and tbench. Test on vanilla kernel: schedstat_parse.py -f netperf_vanilla.log case load se_eff% dom_eff% fast_rate% success_rate% TCP_RR 28 threads 99.978 18.535 99.995 100.000 TCP_RR 56 threads 99.397 5.671 99.964 100.000 TCP_RR 84 threads 21.721 6.818 73.632 100.000 TCP_RR 112 threads 12.500 5.533 59.000 100.000 TCP_RR 140 threads 8.524 4.535 49.020 100.000 TCP_RR 168 threads 6.438 3.945 40.309 99.999 TCP_RR 196 threads 5.397 3.718 32.320 99.982 TCP_RR 224 threads 4.874 3.661 25.775 99.767 UDP_RR 28 threads 99.988 17.704 99.997 100.000 UDP_RR 56 threads 99.528 5.977 99.970 100.000 UDP_RR 84 threads 24.219 6.992 76.479 100.000 UDP_RR 112 threads 13.907 5.706 62.538 100.000 UDP_RR 140 threads 9.408 4.699 52.519 100.000 UDP_RR 168 threads 7.095 4.077 44.352 100.000 UDP_RR 196 threads 5.757 3.775 35.764 99.991 UDP_RR 224 threads 5.124 3.704 28.748 99.860 schedstat_parse.py -f schbench_vanilla.log (each group has 28 tasks) case load se_eff% dom_eff% fast_rate% success_rate% normal 1 mthread 99.152 6.400 99.941 100.000 normal 2 mthreads 97.844 4.003 99.908 100.000 normal 3 mthreads 96.395 2.118 99.917 99.998 normal 4 mthreads 55.288 1.451 98.615 99.804 normal 5 mthreads 7.004 1.870 45.597 61.036 normal 6 mthreads 3.354 1.346 20.777 34.230 normal 7 mthreads 2.183 1.028 11.257 21.055 normal 8 mthreads 1.653 0.825 7.849 15.549 schedstat_parse.py -f hackbench_vanilla.log (each group has 28 tasks) case load se_eff% dom_eff% fast_rate% success_rate% process-pipe 1 group 99.991 7.692 99.999 100.000 process-pipe 2 groups 99.934 4.615 99.997 100.000 process-pipe 3 groups 99.597 3.198 99.987 100.000 process-pipe 4 groups 98.378 2.464 99.958 100.000 process-pipe 5 groups 27.474 3.653 89.811 99.800 process-pipe 6 groups 20.201 4.098 82.763 99.570 process-pipe 7 groups 16.423 4.156 77.398 99.316 process-pipe 8 groups 13.165 3.920 72.232 98.828 process-sockets 1 group 99.977 5.882 99.999 100.000 process-sockets 2 groups 99.927 5.505 99.996 100.000 process-sockets 3 groups 99.397 3.250 99.980 100.000 process-sockets 4 groups 79.680 4.258 98.864 99.998 process-sockets 5 groups 7.673 2.503 63.659 92.115 process-sockets 6 groups 4.642 1.584 58.946 88.048 process-sockets 7 groups 3.493 1.379 49.816 81.164 process-sockets 8 groups 3.015 1.407 40.845 75.500 threads-pipe 1 group 99.997 0.000 100.000 100.000 threads-pipe 2 groups 99.894 2.932 99.997 100.000 threads-pipe 3 groups 99.611 4.117 99.983 100.000 threads-pipe 4 groups 97.703 2.624 99.937 100.000 threads-pipe 5 groups 22.919 3.623 87.150 99.764 threads-pipe 6 groups 18.016 4.038 80.491 99.557 threads-pipe 7 groups 14.663 3.991 75.239 99.247 threads-pipe 8 groups 12.242 3.808 70.651 98.644 threads-sockets 1 group 99.990 6.667 99.999 100.000 threads-sockets 2 groups 99.940 5.114 99.997 100.000 threads-sockets 3 groups 99.469 4.115 99.977 100.000 threads-sockets 4 groups 87.528 4.038 99.400 100.000 threads-sockets 5 groups 6.942 2.398 59.244 88.337 threads-sockets 6 groups 4.359 1.954 49.448 87.860 threads-sockets 7 groups 2.845 1.345 41.198 77.102 threads-sockets 8 groups 2.871 1.404 38.512 74.312 schedstat_parse.py -f tbench_vanilla.log case load se_eff% dom_eff% fast_rate% success_rate% loopback 28 threads 99.976 18.369 99.995 100.000 loopback 56 threads 99.222 7.799 99.934 100.000 loopback 84 threads 19.723 6.819 70.215 100.000 loopback 112 threads 11.283 5.371 55.371 99.999 loopback 140 threads 0.000 0.000 0.000 0.000 loopback 168 threads 0.000 0.000 0.000 0.000 loopback 196 threads 0.000 0.000 0.000 0.000 loopback 224 threads 0.000 0.000 0.000 0.000 According to the test above, if the system becomes busy, the SIS Search Efficiency(se_eff%) drops significantly. Although some benchmarks would finally find an idle CPU(success_rate% = 100%), it is doubtful whether it is worth it to search the whole LLC domain. [Proposal] It would be ideal to have a crystal ball to answer this question: How many CPUs must a wakeup path walk down, before it can find an idle CPU? Many potential metrics could be used to predict the number. One candidate is the sum of util_avg in this LLC domain. The benefit of choosing util_avg is that it is a metric of accumulated historic activity, which seems to be smoother than instantaneous metrics (such as rq->nr_running). Besides, choosing the sum of util_avg would help predict the load of the LLC domain more precisely, because SIS_PROP uses one CPU's idle time to estimate the total LLC domain idle time. In summary, the lower the util_avg is, the more select_idle_cpu() should scan for idle CPU, and vice versa. When the sum of util_avg in this LLC domain hits 85% or above, the scan stops. The reason to choose 85% as the threshold is that this is the imbalance_pct(117) when a LLC sched group is overloaded. Introduce the quadratic function: y = SCHED_CAPACITY_SCALE - p * x^2 and y'= y / SCHED_CAPACITY_SCALE x is the ratio of sum_util compared to the CPU capacity: x = sum_util / (llc_weight * SCHED_CAPACITY_SCALE) y' is the ratio of CPUs to be scanned in the LLC domain, and the number of CPUs to scan is calculated by: nr_scan = llc_weight * y' Choosing quadratic function is because: [1] Compared to the linear function, it scans more aggressively when the sum_util is low. [2] Compared to the exponential function, it is easier to calculate. [3] It seems that there is no accurate mapping between the sum of util_avg and the number of CPUs to be scanned. Use heuristic scan for now. For a platform with 112 CPUs per LLC, the number of CPUs to scan is: sum_util% 0 5 15 25 35 45 55 65 75 85 86 ... scan_nr 112 111 108 102 93 81 65 47 25 1 0 ... For a platform with 16 CPUs per LLC, the number of CPUs to scan is: sum_util% 0 5 15 25 35 45 55 65 75 85 86 ... scan_nr 16 15 15 14 13 11 9 6 3 0 0 ... Furthermore, to minimize the overhead of calculating the metrics in select_idle_cpu(), borrow the statistics from periodic load balance. As mentioned by Abel, on a platform with 112 CPUs per LLC, the sum_util calculated by periodic load balance after 112 ms would decay to about 0.5 * 0.5 * 0.5 * 0.7 = 8.75%, thus bringing a delay in reflecting the latest utilization. But it is a trade-off. Checking the util_avg in newidle load balance would be more frequent, but it brings overhead - multiple CPUs write/read the per-LLC shared variable and introduces cache contention. Tim also mentioned that, it is allowed to be non-optimal in terms of scheduling for the short-term variations, but if there is a long-term trend in the load behavior, the scheduler can adjust for that. When SIS_UTIL is enabled, the select_idle_cpu() uses the nr_scan calculated by SIS_UTIL instead of the one from SIS_PROP. As Peter and Mel suggested, SIS_UTIL should be enabled by default. This patch is based on the util_avg, which is very sensitive to the CPU frequency invariance. There is an issue that, when the max frequency has been clamp, the util_avg would decay insanely fast when the CPU is idle. Commit addca285120b ("cpufreq: intel_pstate: Handle no_turbo in frequency invariance") could be used to mitigate this symptom, by adjusting the arch_max_freq_ratio when turbo is disabled. But this issue is still not thoroughly fixed, because the current code is unaware of the user-specified max CPU frequency. [Test result] netperf and tbench were launched with 25% 50% 75% 100% 125% 150% 175% 200% of CPU number respectively. Hackbench and schbench were launched by 1, 2 ,4, 8 groups. Each test lasts for 100 seconds and repeats 3 times. The following is the benchmark result comparison between baseline:vanilla v5.19-rc1 and compare:patched kernel. Positive compare% indicates better performance. Each netperf test is a: netperf -4 -H 127.0.1 -t TCP/UDP_RR -c -C -l 100 netperf.throughput ======= case load baseline(std%) compare%( std%) TCP_RR 28 threads 1.00 ( 0.34) -0.16 ( 0.40) TCP_RR 56 threads 1.00 ( 0.19) -0.02 ( 0.20) TCP_RR 84 threads 1.00 ( 0.39) -0.47 ( 0.40) TCP_RR 112 threads 1.00 ( 0.21) -0.66 ( 0.22) TCP_RR 140 threads 1.00 ( 0.19) -0.69 ( 0.19) TCP_RR 168 threads 1.00 ( 0.18) -0.48 ( 0.18) TCP_RR 196 threads 1.00 ( 0.16) +194.70 ( 16.43) TCP_RR 224 threads 1.00 ( 0.16) +197.30 ( 7.85) UDP_RR 28 threads 1.00 ( 0.37) +0.35 ( 0.33) UDP_RR 56 threads 1.00 ( 11.18) -0.32 ( 0.21) UDP_RR 84 threads 1.00 ( 1.46) -0.98 ( 0.32) UDP_RR 112 threads 1.00 ( 28.85) -2.48 ( 19.61) UDP_RR 140 threads 1.00 ( 0.70) -0.71 ( 14.04) UDP_RR 168 threads 1.00 ( 14.33) -0.26 ( 11.16) UDP_RR 196 threads 1.00 ( 12.92) +186.92 ( 20.93) UDP_RR 224 threads 1.00 ( 11.74) +196.79 ( 18.62) Take the 224 threads as an example, the SIS search metrics changes are illustrated below: vanilla patched 4544492 +237.5% 15338634 sched_debug.cpu.sis_domain_search.avg 38539 +39686.8% 15333634 sched_debug.cpu.sis_failed.avg 128300000 -87.9% 15551326 sched_debug.cpu.sis_scanned.avg 5842896 +162.7% 15347978 sched_debug.cpu.sis_search.avg There is -87.9% less CPU scans after patched, which indicates lower overhead. Besides, with this patch applied, there is -13% less rq lock contention in perf-profile.calltrace.cycles-pp._raw_spin_lock.raw_spin_rq_lock_nested .try_to_wake_up.default_wake_function.woken_wake_function. This might help explain the performance improvement - Because this patch allows the waking task to remain on the previous CPU, rather than grabbing other CPUs' lock. Each hackbench test is a: hackbench -g $job --process/threads --pipe/sockets -l 1000000 -s 100 hackbench.throughput ========= case load baseline(std%) compare%( std%) process-pipe 1 group 1.00 ( 1.29) +0.57 ( 0.47) process-pipe 2 groups 1.00 ( 0.27) +0.77 ( 0.81) process-pipe 4 groups 1.00 ( 0.26) +1.17 ( 0.02) process-pipe 8 groups 1.00 ( 0.15) -4.79 ( 0.02) process-sockets 1 group 1.00 ( 0.63) -0.92 ( 0.13) process-sockets 2 groups 1.00 ( 0.03) -0.83 ( 0.14) process-sockets 4 groups 1.00 ( 0.40) +5.20 ( 0.26) process-sockets 8 groups 1.00 ( 0.04) +3.52 ( 0.03) threads-pipe 1 group 1.00 ( 1.28) +0.07 ( 0.14) threads-pipe 2 groups 1.00 ( 0.22) -0.49 ( 0.74) threads-pipe 4 groups 1.00 ( 0.05) +1.88 ( 0.13) threads-pipe 8 groups 1.00 ( 0.09) -4.90 ( 0.06) threads-sockets 1 group 1.00 ( 0.25) -0.70 ( 0.53) threads-sockets 2 groups 1.00 ( 0.10) -0.63 ( 0.26) threads-sockets 4 groups 1.00 ( 0.19) +11.92 ( 0.24) threads-sockets 8 groups 1.00 ( 0.08) +4.31 ( 0.11) Each tbench test is a: tbench -t 100 $job 127.0.0.1 tbench.throughput ====== case load baseline(std%) compare%( std%) loopback 28 threads 1.00 ( 0.06) -0.14 ( 0.09) loopback 56 threads 1.00 ( 0.03) -0.04 ( 0.17) loopback 84 threads 1.00 ( 0.05) +0.36 ( 0.13) loopback 112 threads 1.00 ( 0.03) +0.51 ( 0.03) loopback 140 threads 1.00 ( 0.02) -1.67 ( 0.19) loopback 168 threads 1.00 ( 0.38) +1.27 ( 0.27) loopback 196 threads 1.00 ( 0.11) +1.34 ( 0.17) loopback 224 threads 1.00 ( 0.11) +1.67 ( 0.22) Each schbench test is a: schbench -m $job -t 28 -r 100 -s 30000 -c 30000 schbench.latency_90%_us ======== case load baseline(std%) compare%( std%) normal 1 mthread 1.00 ( 31.22) -7.36 ( 20.25)* normal 2 mthreads 1.00 ( 2.45) -0.48 ( 1.79) normal 4 mthreads 1.00 ( 1.69) +0.45 ( 0.64) normal 8 mthreads 1.00 ( 5.47) +9.81 ( 14.28) *Consider the Standard Deviation, this -7.36% regression might not be valid. Also, a OLTP workload with a commercial RDBMS has been tested, and there is no significant change. There were concerns that unbalanced tasks among CPUs would cause problems. For example, suppose the LLC domain is composed of 8 CPUs, and 7 tasks are bound to CPU0~CPU6, while CPU7 is idle: CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 util_avg 1024 1024 1024 1024 1024 1024 1024 0 Since the util_avg ratio is 87.5%( = 7/8 ), which is higher than 85%, select_idle_cpu() will not scan, thus CPU7 is undetected during scan. But according to Mel, it is unlikely the CPU7 will be idle all the time because CPU7 could pull some tasks via CPU_NEWLY_IDLE. lkp(kernel test robot) has reported a regression on stress-ng.sock on a very busy system. According to the sched_debug statistics, it might be caused by SIS_UTIL terminates the scan and chooses a previous CPU earlier, and this might introduce more context switch, especially involuntary preemption, which impacts a busy stress-ng. This regression has shown that, not all benchmarks in every scenario benefit from idle CPU scan limit, and it needs further investigation. Besides, there is slight regression in hackbench's 16 groups case when the LLC domain has 16 CPUs. Prateek mentioned that we should scan aggressively in an LLC domain with 16 CPUs. Because the cost to search for an idle one among 16 CPUs is negligible. The current patch aims to propose a generic solution and only considers the util_avg. Something like the below could be applied on top of the current patch to fulfill the requirement: if (llc_weight <= 16) nr_scan = nr_scan * 32 / llc_weight; For LLC domain with 16 CPUs, the nr_scan will be expanded to 2 times large. The smaller the CPU number this LLC domain has, the larger nr_scan will be expanded. This needs further investigation. There is also ongoing work[2] from Abel to filter out the busy CPUs during wakeup, to further speed up the idle CPU scan. And it could be a following-up optimization on top of this change. Suggested-by: Tim Chen <[email protected]> Suggested-by: Peter Zijlstra <[email protected]> Signed-off-by: Chen Yu <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Yicong Yang <[email protected]> Tested-by: Mohini Narkhede <[email protected]> Tested-by: K Prateek Nayak <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tianchen Ding <[email protected]> Date: Thu Jun 9 07:34:11 2022 +0800 sched: Fix the check of nr_running at queue wakelist [ Upstream commit 28156108fecb1f808b21d216e8ea8f0d205a530c ] The commit 2ebb17717550 ("sched/core: Offload wakee task activation if it the wakee is descheduling") checked rq->nr_running <= 1 to avoid task stacking when WF_ON_CPU. Per the ordering of writes to p->on_rq and p->on_cpu, observing p->on_cpu (WF_ON_CPU) in ttwu_queue_cond() implies !p->on_rq, IOW p has gone through the deactivate_task() in __schedule(), thus p has been accounted out of rq->nr_running. As such, the task being the only runnable task on the rq implies reading rq->nr_running == 0 at that point. The benchmark result is in [1]. [1] https://lore.kernel.org/all/[email protected]/ Suggested-by: Valentin Schneider <[email protected]> Signed-off-by: Tianchen Ding <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Tianchen Ding <[email protected]> Date: Thu Jun 9 07:34:12 2022 +0800 sched: Remove the limitation of WF_ON_CPU on wakelist if wakee cpu is idle [ Upstream commit f3dd3f674555bd9455c5ae7fafce0696bd9931b3 ] Wakelist can help avoid cache bouncing and offload the overhead of waker cpu. So far, using wakelist within the same llc only happens on WF_ON_CPU, and this limitation could be removed to further improve wakeup performance. The commit 518cd6234178 ("sched: Only queue remote wakeups when crossing cache boundaries") disabled queuing tasks on wakelist when the cpus share llc. This is because, at that time, the scheduler must send IPIs to do ttwu_queue_wakelist. Nowadays, ttwu_queue_wakelist also supports TIF_POLLING, so this is not a problem now when the wakee cpu is in idle polling. Benefits: Queuing the task on idle cpu can help improving performance on waker cpu and utilization on wakee cpu, and further improve locality because the wakee cpu can handle its own rq. This patch helps improving rt on our real java workloads where wakeup happens frequently. Consider the normal condition (CPU0 and CPU1 share same llc) Before this patch: CPU0 CPU1 select_task_rq() idle rq_lock(CPU1->rq) enqueue_task(CPU1->rq) notify CPU1 (by sending IPI or CPU1 polling) resched() After this patch: CPU0 CPU1 select_task_rq() idle add to wakelist of CPU1 notify CPU1 (by sending IPI or CPU1 polling) rq_lock(CPU1->rq) enqueue_task(CPU1->rq) resched() We see CPU0 can finish its work earlier. It only needs to put task to wakelist and return. While CPU1 is idle, so let itself handle its own runqueue data. This patch brings no difference about IPI. This patch only takes effect when the wakee cpu is: 1) idle polling 2) idle not polling For 1), there will be no IPI with or without this patch. For 2), there will always be an IPI before or after this patch. Before this patch: waker cpu will enqueue task and check preempt. Since "idle" will be sure to be preempted, waker cpu must send a resched IPI. After this patch: waker cpu will put the task to the wakelist of wakee cpu, and send an IPI. Benchmark: We've tested schbench, unixbench, and hachbench on both x86 and arm64. On x86 (Intel Xeon Platinum 8269CY): schbench -m 2 -t 8 Latency percentiles (usec) before after 50.0000th: 8 6 75.0000th: 10 7 90.0000th: 11 8 95.0000th: 12 8 *99.0000th: 13 10 99.5000th: 15 11 99.9000th: 18 14 Unixbench with full threads (104) before after Dhrystone 2 using register variables 3011862938 3009935994 -0.06% Double-Precision Whetstone 617119.3 617298.5 0.03% Execl Throughput 27667.3 27627.3 -0.14% File Copy 1024 bufsize 2000 maxblocks 785871.4 784906.2 -0.12% File Copy 256 bufsize 500 maxblocks 210113.6 212635.4 1.20% File Copy 4096 bufsize 8000 maxblocks 2328862.2 2320529.1 -0.36% Pipe Throughput 145535622.8 145323033.2 -0.15% Pipe-based Context Switching 3221686.4 3583975.4 11.25% Process Creation 101347.1 103345.4 1.97% Shell Scripts (1 concurrent) 120193.5 123977.8 3.15% Shell Scripts (8 concurrent) 17233.4 17138.4 -0.55% System Call Overhead 5300604.8 5312213.6 0.22% hackbench -g 1 -l 100000 before after Time 3.246 2.251 On arm64 (Ampere Altra): schbench -m 2 -t 8 Latency percentiles (usec) before after 50.0000th: 14 10 75.0000th: 19 14 90.0000th: 22 16 95.0000th: 23 16 *99.0000th: 24 17 99.5000th: 24 17 99.9000th: 28 25 Unixbench with full threads (80) before after Dhrystone 2 using register variables 3536194249 3537019613 0.02% Double-Precision Whetstone 629383.6 629431.6 0.01% Execl Throughput 65920.5 65846.2 -0.11% File Copy 1024 bufsize 2000 maxblocks 1063722.8 1064026.8 0.03% File Copy 256 bufsize 500 maxblocks 322684.5 318724.5 -1.23% File Copy 4096 bufsize 8000 maxblocks 2348285.3 2328804.8 -0.83% Pipe Throughput 133542875.3 131619389.8 -1.44% Pipe-based Context Switching 3215356.1 3576945.1 11.25% Process Creation 108520.5 120184.6 10.75% Shell Scripts (1 concurrent) 122636.3 121888 -0.61% Shell Scripts (8 concurrent) 17462.1 17381.4 -0.46% System Call Overhead 4429998.9 4435006.7 0.11% hackbench -g 1 -l 100000 before after Time 4.217 2.916 Our patch has improvement on schbench, hackbench and Pipe-based Context Switching of unixbench when there exists idle cpus, and no obvious regression on other tests of unixbench. This can help improve rt in scenes where wakeup happens frequently. Signed-off-by: Tianchen Ding <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Josh Poimboeuf <[email protected]> Date: Thu Jul 21 11:01:23 2022 -0700 scripts/faddr2line: Fix vmlinux detection on arm64 [ Upstream commit b6a5068854cfe372da7dee3224dcf023ed5b00cb ] Since commit dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel"), faddr2line is completely broken on arm64. For some reason, on arm64, the vmlinux ELF object file type is ET_DYN rather than ET_EXEC. Check for both when determining whether the object is vmlinux. Modules and vmlinux.o have type ET_REL on all arches. Fixes: dcea997beed6 ("faddr2line: Fix overlapping text section failures, the sequel") Reported-by: John Garry <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: John Garry <[email protected]> Link: https://lore.kernel.org/r/dad1999737471b06d6188ce4cdb11329aa41682c.1658426357.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin <[email protected]>
Author: Antonio Borneo <[email protected]> Date: Tue Jul 19 14:28:31 2022 +0200 scripts/gdb: fix 'lx-dmesg' on 32 bits arch [ Upstream commit e3c8d33e0d62175c31ca7ab7ab01b18f0b6318d3 ] The type atomic_long_t can have size 4 or 8 bytes, depending on CONFIG_64BIT; it's only content, the field 'counter', is either an int or a s64 value. Current code incorrectly uses the fixed size utils.read_u64() to read the field 'counter' inside atomic_long_t. On 32 bits architectures reading the last element 'tail_id' of the struct prb_desc_ring: struct prb_desc_ring { ... atomic_long_t tail_id; }; causes the utils.read_u64() to access outside the boundary of the struct and the gdb command 'lx-dmesg' exits with error: Python Exception <class 'IndexError'>: index out of range Error occurred in Python: index out of range Query the really used atomic_long_t counter type size. Link: https://lore.kernel.org/r/[email protected] Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer") Signed-off-by: Antonio Borneo <[email protected]> [[email protected]: Query the really used atomic_long_t counter type size] Tested-by: Antonio Borneo <[email protected]> Reviewed-by: John Ogness <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: John Ogness <[email protected]> Date: Wed Dec 15 16:16:22 2021 +0106 scripts/gdb: lx-dmesg: read records individually [ Upstream commit deaee2704a157dfcca77301ddaa10c62a9840952 ] For the gdb command lx-dmesg, the entire descriptor, info, and text data regions are read into memory before printing any records. For large kernel log buffers, this not only causes a huge delay before seeing any records, but it may also lead to python errors of too much memory allocation. Rather than reading in all these regions in advance, read them as needed and only read the regions for the particular record that is being printed. The gdb macro "dmesg" in Documentation/admin-guide/kdump/gdbmacros.txt already prints out the kernel log buffer like this. Signed-off-by: John Ogness <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Xiang Chen <[email protected]> Date: Tue Aug 24 18:00:56 2021 +0800 scsi: hisi_sas: Use managed PCI functions [ Upstream commit 4f6094f1663e2ed26a940f1842cdaa15c1dd649a ] Use managed PCI functions such as pcim_enable_device() and pcim_iomap_regions() to simplify exception handling code. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xiang Chen <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Christie <[email protected]> Date: Thu Jun 16 17:27:36 2022 -0500 scsi: iscsi: Add helper to remove a session from the kernel [ Upstream commit bb42856bfd54fda1cbc7c470fcf5db1596938f4f ] During qedi shutdown we need to stop the iSCSI layer from sending new nops as pings and from responding to target ones and make sure there is no running connection cleanups. Commit d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions") converted the driver to use the libicsi helper to drive session removal, so the above issues could be handled. The problem is that during system shutdown iscsid will not be running so when we try to remove the root session we will hang waiting for userspace to reply. Add a helper that will drive the destruction of sessions like these during system shutdown. Link: https://lore.kernel.org/r/[email protected] Tested-by: Nilesh Javali <[email protected]> Reviewed-by: Nilesh Javali <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Christie <[email protected]> Date: Thu Jun 16 17:27:34 2022 -0500 scsi: iscsi: Allow iscsi_if_stop_conn() to be called from kernel [ Upstream commit 3328333b47f4163504267440ec0a36087a407a5f ] iscsi_if_stop_conn() is only called from the userspace interface but in a subsequent commit we will want to call it from the kernel interface to allow drivers like qedi to remove sessions from inside the kernel during shutdown. This removes the iscsi_uevent code from iscsi_if_stop_conn() so we can call it in a new helper. Link: https://lore.kernel.org/r/[email protected] Tested-by: Nilesh Javali <[email protected]> Reviewed-by: Nilesh Javali <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mike Christie <[email protected]> Date: Thu Jun 16 17:27:38 2022 -0500 scsi: iscsi: Fix session removal on shutdown [ Upstream commit 31500e902759322ba3c64b60dabae2704e738df8 ] When the system is shutting down, iscsid is not running so we will not get a response to the ISCSI_ERR_INVALID_HOST error event. The system shutdown will then hang waiting on userspace to remove the session. This has libiscsi force the destruction of the session from the kernel when iscsi_host_remove() is called from a driver's shutdown callout. This fixes a regression added in qedi boot with commit d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions") which made qedi use the common session removal function that waits on userspace instead of rolling its own kernel based removal. Link: https://lore.kernel.org/r/[email protected] Fixes: d1f2ce77638d ("scsi: qedi: Fix host removal with running sessions") Tested-by: Nilesh Javali <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Reviewed-by: Nilesh Javali <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Smart <[email protected]> Date: Fri Sep 10 16:31:54 2021 -0700 scsi: lpfc: Fix EEH support for NVMe I/O [ Upstream commit 25ac2c970be32993f1dff607f8354f3c053d42bc ] Injecting errors on the PCI slot while the driver is handling NVMe I/O will cause crashes and hangs. There are several rather difficult scenarios occurring. The main issue is that the adapter can report a PCI error before or simultaneously to the PCI subsystem reporting the error. Both paths have different entry points and currently there is no interlock between them. Thus multiple teardown paths are competing and all heck breaks loose. Complicating things is the NVMs path. To a large degree, I/O was able to be shutdown for a full FC port on the SCSI stack. But on NVMe, there isn't a similar call. At best, it works on a per-controller basis, but even at the controller level, it's a controller "reset" call. All of which means I/O is still flowing on different CPUs with reset paths expecting hw access (mailbox commands) to execute properly. The following modifications are made: - A new flag is set in PCI error entrypoints so the driver can track being called by that path. - An interlock is added in the SLI hw error path and the PCI error path such that only one of the paths proceeds with the teardown logic. - RPI cleanup is patched such that RPIs are marked unregistered w/o mbx cmds in cases of hw error. - If entering the SLI port re-init calls, a case where SLI error teardown was quick and beat the PCI calls now reporting error, check whether the SLI port is still live on the PCI bus. - In the PCI reset code to bring the adapter back, recheck the IRQ settings. Different checks for SLI3 vs SLI4. - In I/O completions, that may be called as part of the cleanup or underway just before the hw error, check the state of the adapter. If in error, shortcut handling that would expect further adapter completions as the hw error won't be sending them. - In routines waiting on I/O completions, which may have been in progress prior to the hw error, detect the device is being torn down and abort from their waits and just give up. This points to a larger issue in the driver on ref-counting for data structures, as it doesn't have ref-counting on q and port structures. We'll do this fix for now as it would be a major rework to be done differently. - Fix the NVMe cleanup to simulate NVMe I/O completions if I/O is being failed back due to hw error. - In I/O buf allocation, done at the start of new I/Os, check hw state and fail if hw error. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Smart <[email protected]> Date: Thu May 5 20:55:08 2022 -0700 scsi: lpfc: Fix element offset in __lpfc_sli_release_iocbq_s4() commit 84c6f99e39074d45f75986e42ca28e27c140fd0d upstream. The prior commit that moved from iocb elements to explicit wqe elements missed a name change. Correct __lpfc_sli_release_iocbq_s4() to reference wqe rather than iocb. Link: https://lore.kernel.org/r/[email protected] Fixes: a680a9298e7b ("scsi: lpfc: SLI path split: Refactor lpfc_iocbq") Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: James Smart <[email protected]> Date: Wed Mar 23 13:55:45 2022 -0700 scsi: lpfc: Fix locking for lpfc_sli_iocbq_lookup() commit c26bd6602e1d348bfa754dc55e5608c922dd2801 upstream. The rules changed for lpfc_sli_iocbq_lookup() vs locking. Prior, the routine properly took out the lock. In newly refactored code, the locks must be held when calling the routine. Fix lpfc_sli_process_sol_iocb() to take the locks before calling the routine. Fix lpfc_sli_handle_fast_ring_event() to not release the locks to call the routine. Link: https://lore.kernel.org/r/[email protected] Fixes: 1b64aa9eae28 ("scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4") Co-developed-by: Dick Kennedy <[email protected]> Signed-off-by: Dick Kennedy <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: James Smart <[email protected]> Date: Fri Jul 1 14:14:17 2022 -0700 scsi: lpfc: Remove extra atomic_inc on cmd_pending in queuecommand after VMID [ Upstream commit 0948a9c5386095baae4012190a6b65aba684a907 ] VMID introduced an extra increment of cmd_pending, causing double-counting of the I/O. The normal increment ios performed in lpfc_get_scsi_buf. Link: https://lore.kernel.org/r/[email protected] Fixes: 33c79741deaf ("scsi: lpfc: vmid: Introduce VMID in I/O path") Cc: <[email protected]> # v5.14+ Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Smart <[email protected]> Date: Fri Jun 3 10:43:23 2022 -0700 scsi: lpfc: Resolve some cleanup issues following SLI path refactoring commit e27f05147bff21408c1b8410ad8e90cd286e7952 upstream. Following refactoring and consolidation in SLI processing, fix up some minor issues related to SLI path: - Correct the setting of LPFC_EXCHANGE_BUSY flag in response IOCB. - Fix some typographical errors. - Fix duplicate log messages. Link: https://lore.kernel.org/r/[email protected] Fixes: 1b64aa9eae28 ("scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4") Cc: <[email protected]> # v5.18 Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: James Smart <[email protected]> Date: Thu Feb 24 18:22:53 2022 -0800 scsi: lpfc: SLI path split: Refactor fast and slow paths to native SLI4 [ Upstream commit 1b64aa9eae28ac598a03ed3d62a63ac5e5b295fc ] Convert the SLI4 fast and slow paths to use native SLI4 wqe constructs instead of iocb SLI3-isms. Includes the following: - Create simple get_xxx and set_xxx routines to wrapper access to common elements in both SLI3 and SLI4 commands - allowing calling routines to avoid sli-rev-specific structures to access the elements. - using the wqe in the job structure as the primary element - use defines from SLI-4, not SLI-3 - Removal of iocb to wqe conversion from fast and slow path - Add below routines to handle fast path lpfc_prep_embed_io - prepares the wqe for fast path lpfc_wqe_bpl2sgl - manages bpl to sgl conversion lpfc_sli_wqe2iocb - converts a WQE to IOCB for SLI-3 path - Add lpfc_sli3_iocb2wcqecmpl in completion path to convert an SLI-3 iocb completion to wcqe completion - Refactor some of the code that works on both revs for clarity Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Smart <[email protected]> Date: Thu Feb 24 18:22:52 2022 -0800 scsi: lpfc: SLI path split: Refactor lpfc_iocbq [ Upstream commit a680a9298e7b4ff344aca3456177356b276e5038 ] Currently, SLI3 and SLI4 data paths use the same lpfc_iocbq structure. This is a "common" structure but many of the components refer to sli-rev specific entities which can lead the developer astray as to what they actually mean, should be set to, or when they should be used. This first patch prepares the lpfc_iocbq structure so that elements common to both SLI3 and SLI4 data paths are more appropriately named, making it clear they apply generically. Fieldnames based on 'iocb' (sli3) or 'wqe' (sli4) which are actually generic to the paths are renamed to 'cmd': - iocb_flag is renamed to cmd_flag - lpfc_vmid_iocb_tag is renamed to lpfc_vmid_tag - fabric_iocb_cmpl is renamed to fabric_cmd_cmpl - wait_iocb_cmpl is renamed to wait_cmd_cmpl - iocb_cmpl and wqe_cmpl are combined and renamed to cmd_cmpl - rsvd2 member is renamed to num_bdes due to pre-existing usage The structure name itself will retain the iocb reference as changing to a more relevant "job" or "cmd" title induces many hundreds of line changes for only a name change. lpfc_post_buffer is also renamed to lpfc_sli3_post_buffer to indicate use in the SLI3 path only. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: James Smart <[email protected]> Date: Thu Feb 24 18:23:04 2022 -0800 scsi: lpfc: SLI path split: Refactor SCSI paths [ Upstream commit 3512ac0942938d6977e7999ee69765d948d2faf1 ] This patch refactors the SCSI paths to use SLI-4 as the primary interface. - Conversion away from using SLI-3 iocb structures to set/access fields in common routines. Use the new generic get/set routines that were added. This move changes code from indirect structure references to using local variables with the generic routines. - Refactor routines when setting non-generic fields, to have both SLI3 and SLI4 specific sections. This replaces the set-as-SLI3 then translate to SLI4 behavior of the past. Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Justin Tee <[email protected]> Signed-off-by: Justin Tee <[email protected]> Signed-off-by: James Smart <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Wed Jun 22 09:21:55 2022 +0300 scsi: qla2xxx: Check correct variable in qla24xx_async_gffid() [ Upstream commit 7c33e477bd883f79cccec418980cb8f7f2d50347 ] There is a copy and paste bug here. It should check ".rsp" instead of ".req". The error message is copy and pasted as well so update that too. Link: https://lore.kernel.org/r/YrK1A/t3L6HKnswO@kili Fixes: 9c40c36e75ff ("scsi: qla2xxx: edif: Reduce Initiator-Initiator thrashing") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Jun 6 21:46:23 2022 -0700 scsi: qla2xxx: edif: Add retry for ELS passthrough [ Upstream commit 0b3f3143d473b489a7aa0779c43bcdb344bd3014 ] Relating to EDIF, when sending IKE message, updating key or deleting key, driver can encounter IOCB queue full. Add additional retries to reduce higher level recovery. Link: https://lore.kernel.org/r/[email protected] Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Tue Oct 26 04:54:10 2021 -0700 scsi: qla2xxx: edif: Fix inconsistent check of db_flags [ Upstream commit 36f468bfe98c7de7916ab3391ee5dd6fd2549979 ] db_flags field is a bit field. Replace value check with bit flag check. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Jun 6 21:46:25 2022 -0700 scsi: qla2xxx: edif: Fix n2n discovery issue with secure target [ Upstream commit 789d54a4178634850e441f60c0326124138e7269 ] User failed to see disk via n2n topology. Driver used up all login retries before authentication application started. When authentication application started, driver did not have enough login retries to connect securely. On app_start, driver will reset the login retry attempt count. Link: https://lore.kernel.org/r/[email protected] Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Jun 6 21:46:26 2022 -0700 scsi: qla2xxx: edif: Fix n2n login retry for secure device [ Upstream commit aec55325ddec975216119da000092cb8664a3399 ] After initiator has burned up all login retries, target authentication application begins to run. This triggers a link bounce on target side. Initiator will attempt another login. Due to N2N, the PRLI [nvme | fcp] can fail because of the mode mismatch with target. This patch add a few more login retries to revive the connection. Link: https://lore.kernel.org/r/[email protected] Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 8 04:58:43 2022 -0700 scsi: qla2xxx: edif: Fix no login after app start [ Upstream commit 24c796098f5395477f7f7ebf8e24f3f08a139f71 ] The scenario is this: User loaded driver but has not started authentication app. All sessions to secure device will exhaust all login attempts, fail, and in stay in deleted state. Then some time later the app is started. The driver will replenish the login retry count, trigger delete to prepare for secure login. After deletion, relogin is triggered. For the session that is already deleted, the delete trigger is a no-op. If none of the sessions trigger a relogin, no progress is made. Add a relogin trigger. Link: https://lore.kernel.org/r/[email protected] Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs") Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 8 04:58:46 2022 -0700 scsi: qla2xxx: edif: Fix no logout on delete for N2N [ Upstream commit ec538eb838f334453b10e7e9b260f0c358018a37 ] The driver failed to send implicit logout on session delete. For edif, this failed to flush any lingering SA index in FW. Set a flag to turn on implicit logout early in the session recovery to make sure the logout will go out in case of error. Link: https://lore.kernel.org/r/[email protected] Fixes: 4de067e5df12 ("scsi: qla2xxx: edif: Add N2N support for EDIF") Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Jun 6 21:46:21 2022 -0700 scsi: qla2xxx: edif: Fix potential stuck session in sa update [ Upstream commit e0fb8ce2bb9e52c846e54ad2c58b5b7beb13eb09 ] When a thread is in the process of reestablish a session, a flag is set to prevent multiple threads/triggers from doing the same task. This flag was left on, and any attempt to relogin was locked out. Clear this flag if the attempt has failed. Link: https://lore.kernel.org/r/[email protected] Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 8 04:58:45 2022 -0700 scsi: qla2xxx: edif: Fix session thrash [ Upstream commit a8fdfb0b39c2b31722c70bdf2272b949d5af4b7b ] Current code prematurely sends out PRLI before authentication application has given the OK to do so. This causes PRLI failure and session teardown. Prevents PRLI from going out before authentication app gives the OK. Link: https://lore.kernel.org/r/[email protected] Fixes: 91f6f5fbe87b ("scsi: qla2xxx: edif: Reduce connection thrash") Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Tue Oct 26 04:54:08 2021 -0700 scsi: qla2xxx: edif: Reduce connection thrash [ Upstream commit 91f6f5fbe87ba834133fcc61d34881cb8ec9e518 ] On ipsec start by remote port, target port may use RSCN to trigger initiator to relogin. If driver is already in the process of a relogin, then ignore the RSCN and allow the current relogin to continue. This reduces thrashing of the connection. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 8 04:58:42 2022 -0700 scsi: qla2xxx: edif: Reduce disruption due to multiple app start [ Upstream commit 0dbfce5255fe8d069a1a3b712a25b263264cfa58 ] Multiple app start can trigger a session bounce. Make driver skip over session teardown if app start is seen more than once. Link: https://lore.kernel.org/r/[email protected] Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs") Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Jun 6 21:46:17 2022 -0700 scsi: qla2xxx: edif: Reduce Initiator-Initiator thrashing [ Upstream commit 9c40c36e75ffd49952cd4ead0672defc4b4dbdf7 ] This patch uses GFFID switch command to scan whether remote device is Target or Initiator mode. Based on that info, driver will not pass up Initiator info to authentication application. This helps reduce unnecessary stress for authentication application to deal with unused connections. Link: https://lore.kernel.org/r/[email protected] Fixes: 7ebb336e45ef ("scsi: qla2xxx: edif: Add start + stop bsgs") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 8 04:58:41 2022 -0700 scsi: qla2xxx: edif: Send LOGO for unexpected IKE message [ Upstream commit 2b659ed67a12f39f56d8dcad9b5d5a74d67c01b3 ] If the session is down and the local port continues to receive AUTH ELS messages, the driver needs to send back LOGO so that the remote device knows to tear down its session. Terminate and clean up the AUTH ELS exchange followed by a passthrough LOGO. Link: https://lore.kernel.org/r/[email protected] Fixes: 225479296c4f ("scsi: qla2xxx: edif: Reject AUTH ELS on session down") Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Jun 6 21:46:22 2022 -0700 scsi: qla2xxx: edif: Synchronize NPIV deletion with authentication application [ Upstream commit cf79716e6636400ae38c37bc8a652b1e522abbba ] Notify authentication application of a NPIV deletion event is about to occur. This allows app to perform cleanup. Link: https://lore.kernel.org/r/[email protected] Fixes: 9efea843a906 ("scsi: qla2xxx: edif: Add detection of secure device") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 8 04:58:44 2022 -0700 scsi: qla2xxx: edif: Tear down session if keys have been removed [ Upstream commit d7e2e4a68fc047a025afcd200e6b7e1fbc8b1999 ] If all keys for a session have been deleted, trigger a session teardown. Link: https://lore.kernel.org/r/[email protected] Fixes: dd30706e73b7 ("scsi: qla2xxx: edif: Add key update") Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:02 2022 -0700 scsi: qla2xxx: Fix crash due to stale SRB access around I/O timeouts commit c39587bc0abaf16593f7abcdf8aeec3c038c7d52 upstream. Ensure SRB is returned during I/O timeout error escalation. If that is not possible fail the escalation path. Following crash stack was seen: BUG: unable to handle kernel paging request at 0000002f56aa90f8 IP: qla_chk_edif_rx_sa_delete_pending+0x14/0x30 [qla2xxx] Call Trace: ? qla2x00_status_entry+0x19f/0x1c50 [qla2xxx] ? qla2x00_start_sp+0x116/0x1170 [qla2xxx] ? dma_pool_alloc+0x1d6/0x210 ? mempool_alloc+0x54/0x130 ? qla24xx_process_response_queue+0x548/0x12b0 [qla2xxx] ? qla_do_work+0x2d/0x40 [qla2xxx] ? process_one_work+0x14c/0x390 Link: https://lore.kernel.org/r/[email protected] Fixes: d74595278f4a ("scsi: qla2xxx: Add multiple queue pair functionality.") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arun Easi <[email protected]> Date: Tue Jul 12 22:20:42 2022 -0700 scsi: qla2xxx: Fix discovery issues in FC-AL topology commit 47ccb113cead905bdc236571bf8ac6fed90321b3 upstream. A direct attach tape device, when gets swapped with another, was not discovered. Fix this by looking at loop map and reinitialize link if there are devices present. Link: https://lore.kernel.org/linux-scsi/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Reported-by: Tony Battersby <[email protected]> Tested-by: Tony Battersby <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 15 22:35:07 2022 -0700 scsi: qla2xxx: Fix erroneous mailbox timeout after PCI error injection commit f260694e6463b63ae550aad25ddefe94cb1904da upstream. Clear wait for mailbox interrupt flag to prevent stale mailbox: Feb 22 05:22:56 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-500a:4: LOOP UP detected (16 Gbps). Feb 22 05:22:59 ltcden4-lp7 kernel: qla2xxx [0135:90:00.1]-d04c:4: MBX Command timeout for cmd 69, ... To fix the issue, driver needs to clear the MBX_INTR_WAIT flag on purging the mailbox. When the stale mailbox completion does arrive, it will be dropped. Link: https://lore.kernel.org/r/[email protected] Fixes: b6faaaf796d7 ("scsi: qla2xxx: Serialize mailbox request") Cc: Naresh Bannoth <[email protected]> Cc: Kyle Mahlkuch <[email protected]> Cc: [email protected] Reported-by: Naresh Bannoth <[email protected]> Tested-by: Naresh Bannoth <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:34:58 2022 -0700 scsi: qla2xxx: Fix excessive I/O error messages by default commit bff4873c709085e09d0ffae0c25b8e65256e3205 upstream. Disable printing I/O error messages by default. The messages will be printed only when logging was enabled. Link: https://lore.kernel.org/r/[email protected] Fixes: 8e2d81c6b5be ("scsi: qla2xxx: Fix excessive messages during device logout") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Tue Jul 12 22:20:41 2022 -0700 scsi: qla2xxx: Fix imbalance vha->vref_count commit 63fa7f2644b4b48e1913af33092c044bf48e9321 upstream. vref_count took an extra decrement in the task management path. Add an extra ref count to compensate the imbalance. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bikash Hazarika <[email protected]> Date: Tue Jul 12 22:20:37 2022 -0700 scsi: qla2xxx: Fix incorrect display of max frame size commit cf3b4fb655796674e605268bd4bfb47a47c8bce6 upstream. Replace display field with the correct field. Link: https://lore.kernel.org/r/[email protected] Fixes: 8777e4314d39 ("scsi: qla2xxx: Migrate NVME N2N handling into state machine") Cc: [email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Bikash Hazarika <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:03 2022 -0700 scsi: qla2xxx: Fix losing FCP-2 targets during port perturbation tests commit 58d1c124cd79ea686b512043c5bd515590b2ed95 upstream. When a mix of FCP-2 (tape) and non-FCP-2 targets are present, FCP-2 target state was incorrectly transitioned when both of the targets were gone. Fix this by ignoring state transition for FCP-2 targets. Link: https://lore.kernel.org/r/[email protected] Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:06 2022 -0700 scsi: qla2xxx: Fix losing FCP-2 targets on long port disable with I/Os commit 2416ccd3815ba1613e10a6da0a24ef21acfe5633 upstream. FCP-2 devices were not coming back online once they were lost, login retries exhausted, and then came back up. Fix this by accepting RSCN when the device is not online. Link: https://lore.kernel.org/r/[email protected] Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arun Easi <[email protected]> Date: Wed Jun 15 22:35:04 2022 -0700 scsi: qla2xxx: Fix losing target when it reappears during delete commit 118b0c863c8f5629cc5271fc24d72d926e0715d9 upstream. FC target disappeared during port perturbation tests due to a race that tramples target state. Fix the issue by adding state checks before proceeding. Link: https://lore.kernel.org/r/[email protected] Fixes: 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") Cc: [email protected] Signed-off-by: Arun Easi <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 15 22:35:01 2022 -0700 scsi: qla2xxx: Turn off multi-queue for 8G adapters commit 5304673bdb1635e27555bd636fd5d6956f1cd552 upstream. For 8G adapters, multi-queue was enabled accidentally. Make sure multi-queue is not enabled. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Wed Jun 15 22:35:00 2022 -0700 scsi: qla2xxx: Wind down adapter after PCIe error commit d3117c83ba316b3200d9f2fe900f2b9a5525a25c upstream. Put adapter into a wind down state if OS does not make any attempt to recover the adapter after PCIe error. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bikash Hazarika <[email protected]> Date: Tue Jul 12 22:20:38 2022 -0700 scsi: qla2xxx: Zero undefined mailbox IN registers commit 6c96a3c7d49593ef15805f5e497601c87695abc9 upstream. While requesting a new mailbox command, driver does not write any data to unused registers. Initialize the unused register value to zero while requesting a new mailbox command to prevent stale entry access by firmware. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Bikash Hazarika <[email protected]> Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nilesh Javali <[email protected]> Date: Tue Jul 12 22:20:36 2022 -0700 scsi: Revert "scsi: qla2xxx: Fix disk failure to rediscover" commit 5bc7b01c513a4a9b4cfe306e8d1720cfcfd3b8a3 upstream. This fixes the regression of NVMe discovery failure during driver load time. This reverts commit 6a45c8e137d4e2c72eecf1ac7cf64f2fdfcead99. Link: https://lore.kernel.org/r/[email protected] Cc: [email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tony Battersby <[email protected]> Date: Mon Jul 11 10:51:32 2022 -0400 scsi: sg: Allow waiting for commands to complete on removed device commit 3455607fd7be10b449f5135c00dc306b85dc0d21 upstream. When a SCSI device is removed while in active use, currently sg will immediately return -ENODEV on any attempt to wait for active commands that were sent before the removal. This is problematic for commands that use SG_FLAG_DIRECT_IO since the data buffer may still be in use by the kernel when userspace frees or reuses it after getting ENODEV, leading to corrupted userspace memory (in the case of READ-type commands) or corrupted data being sent to the device (in the case of WRITE-type commands). This has been seen in practice when logging out of a iscsi_tcp session, where the iSCSI driver may still be processing commands after the device has been marked for removal. Change the policy to allow userspace to wait for active sg commands even when the device is being removed. Return -ENODEV only when there are no more responses to read. Link: https://lore.kernel.org/r/[email protected] Cc: <[email protected]> Acked-by: Douglas Gilbert <[email protected]> Signed-off-by: Tony Battersby <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mahesh Rajashekhara <[email protected]> Date: Fri Jul 8 13:47:36 2022 -0500 scsi: smartpqi: Fix DMA direction for RAID requests [ Upstream commit 69695aeaa6621bc49cdd7a8e5a8d1042461e496e ] Correct a SOP READ and WRITE DMA flags for some requests. This update corrects DMA direction issues with SCSI commands removed from the controller's internal lookup table. Currently, SCSI READ BLOCK LIMITS (0x5) was removed from the controller lookup table and exposed a DMA direction flag issue. SCSI READ BLOCK LIMITS was recently removed from our controller lookup table so the controller uses the respective IU flag field to set the DMA data direction. Since the DMA direction is incorrect the FW never completes the request causing a hang. Some SCSI commands which use SCSI READ BLOCK LIMITS * sg_map * mt -f /dev/stX status After updating controller firmware, users may notice their tape units failing. This patch resolves the issue. Also, the AIO path DMA direction is correct. The DMA direction flag is a day-one bug with no reported BZ. Fixes: 6c223761eb54 ("smartpqi: initial commit of Microsemi smartpqi driver") Link: https://lore.kernel.org/r/165730605618.177165.9054223644512926624.stgit@brunhilda Reviewed-by: Scott Benesh <[email protected]> Reviewed-by: Scott Teel <[email protected]> Reviewed-by: Mike McGowen <[email protected]> Reviewed-by: Kevin Barnett <[email protected]> Signed-off-by: Mahesh Rajashekhara <[email protected]> Signed-off-by: Don Brace <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Wang <[email protected]> Date: Wed Jul 27 11:05:26 2022 +0800 scsi: ufs: core: Correct ufshcd_shutdown() flow commit 00511d2abf5708ad05dd5d1c36adb2468d274698 upstream. After ufshcd_wl_shutdown() set device power off and link off, ufshcd_shutdown() could turn off clock/power. Also remove pm_runtime_get_sync. The reason why it is safe to remove pm_runtime_get_sync() is because: - ufshcd_wl_shutdown() -> pm_runtime_get_sync() will resume hba->dev too. - device resume(turn on clk/power) is not required, even if device is in RPM_SUSPENDED. Link: https://lore.kernel.org/r/[email protected] Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun") Cc: <[email protected]> # 5.15.x Reviewed-by: Stanley Chu <[email protected]> Signed-off-by: Peter Wang <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Steffen Maier <[email protected]> Date: Fri Jul 29 18:25:29 2022 +0200 scsi: zfcp: Fix missing auto port scan and thus missing target ports commit 4da8c5f76825269f28d6a89fa752934a4bcb6dfa upstream. Case (1): The only waiter on wka_port->completion_wq is zfcp_fc_wka_port_get() trying to open a WKA port. As such it should only be woken up by WKA port *open* responses, not by WKA port close responses. Case (2): A close WKA port response coming in just after having sent a new open WKA port request and before blocking for the open response with wait_event() in zfcp_fc_wka_port_get() erroneously renders the wait_event a NOP because the close handler overwrites wka_port->status. Hence the wait_event condition is erroneously true and it does not enter blocking state. With non-negligible probability, the following time space sequence happens depending on timing without this fix: user process ERP thread zfcp work queue tasklet system work queue ============ ========== =============== ======= ================= $ echo 1 > online zfcp_ccw_set_online zfcp_ccw_activate zfcp_erp_adapter_reopen msleep scan backoff zfcp_erp_strategy | ... | zfcp_erp_action_cleanup | ... | queue delayed scan_work | queue ns_up_work | ns_up_work: | zfcp_fc_wka_port_get | open wka request | open response | GSPN FC-GS | RSPN FC-GS [NPIV-only] | zfcp_fc_wka_port_put | (--wka->refcount==0) | sched delayed wka->work | ~~~Case (1)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ zfcp_erp_wait flush scan_work | wka->work: | wka->status=CLOSING | close wka request | scan_work: | zfcp_fc_wka_port_get | (wka->status==CLOSING) | wka->status=OPENING | open wka request | wait_event | | close response | | wka->status=OFFLINE | | wake_up /*WRONG*/ ~~~Case (2)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | wka->work: | wka->status=CLOSING | close wka request zfcp_erp_wait flush scan_work | scan_work: | zfcp_fc_wka_port_get | (wka->status==CLOSING) | wka->status=OPENING | open wka request | close response | wka->status=OFFLINE | wake_up /*WRONG&NOP*/ | wait_event /*NOP*/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | (wka->status!=ONLINE) | return -EIO | return early open response wka->status=ONLINE wake_up /*NOP*/ So we erroneously end up with no automatic port scan. This is a big problem when it happens during boot. The timing is influenced by v3.19 commit 18f87a67e6d6 ("zfcp: auto port scan resiliency"). Fix it by fully mutually excluding zfcp_fc_wka_port_get() and zfcp_fc_wka_port_offline(). For that to work, we make the latter block until we got the response for a close WKA port. In order not to penalize the system workqueue, we move wka_port->work to our own adapter workqueue. Note that before v2.6.30 commit 828bc1212a68 ("[SCSI] zfcp: Set WKA-port to offline on adapter deactivation"), zfcp did block in zfcp_fc_wka_port_offline() as well, but with a different condition. While at it, make non-functional cleanups to improve code reading in zfcp_fc_wka_port_get(). If we cannot send the WKA port open request, don't rely on the subsequent wait_event condition to immediately let this case pass without blocking. Also don't want to rely on the additional condition handling the refcount to be skipped just to finally return with -EIO. Link: https://lore.kernel.org/r/[email protected] Fixes: 5ab944f97e09 ("[SCSI] zfcp: attach and release SAN nameserver port on demand") Cc: <[email protected]> #v2.6.28+ Reviewed-by: Benjamin Block <[email protected]> Signed-off-by: Steffen Maier <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 19 12:50:32 2022 +0300 selftests/bpf: fix a test for snprintf() overflow [ Upstream commit c5d22f4cfe8dfb93f1db0a1e7e2e7ebc41395d98 ] The snprintf() function returns the number of bytes which *would* have been copied if there were space. In other words, it can be > sizeof(pin_path). Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Martin KaFai Lau <[email protected]> Link: https://lore.kernel.org/r/YtZ+aD/tZMkgOUw+@kili Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joe Lawrence <[email protected]> Date: Thu Jun 2 16:32:33 2022 -0400 selftests/livepatch: better synchronize test_klp_callbacks_busy [ Upstream commit 55eb9a6c8bf3e2099863118ef53e02d9f44f85a8 ] The test_klp_callbacks_busy module conditionally blocks a future livepatch transition by busy waiting inside its workqueue function, busymod_work_func(). After scheduling this work, a test livepatch is loaded, introducing the transition under test. Both events are marked in the kernel log for later verification, but there is no synchronization to ensure that busymod_work_func() logs its function entry message before subsequent selftest commands log their own messages. This can lead to a rare test failure due to unexpected ordering like: # --- expected # +++ result # @@ -1,7 +1,7 @@ # % modprobe test_klp_callbacks_busy block_transition=Y # test_klp_callbacks_busy: test_klp_callbacks_busy_init # -test_klp_callbacks_busy: busymod_work_func enter # % modprobe test_klp_callbacks_demo # +test_klp_callbacks_busy: busymod_work_func enter # livepatch: enabling patch 'test_klp_callbacks_demo' # livepatch: 'test_klp_callbacks_demo': initializing patching transition # test_klp_callbacks_demo: pre_patch_callback: vmlinux Force the module init function to wait until busymod_work_func() has started (and logged its message), before exiting to the next selftest steps. Fixes: 547840bd5ae5 ("selftests/livepatch: simplify test-klp-callbacks busy target tests") Signed-off-by: Joe Lawrence <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: YiFei Zhu <[email protected]> Date: Thu May 26 22:34:07 2022 +0000 selftests/seccomp: Fix compile warning when CC=clang [ Upstream commit 3ce4b78f73e8e00fb86bad67ee7f6fe12019707e ] clang has -Wconstant-conversion by default, and the constant 0xAAAAAAAAA (9 As) being converted to an int, which is generally 32 bits, results in the compile warning: clang -Wl,-no-as-needed -Wall -isystem ../../../../usr/include/ -lpthread seccomp_bpf.c -lcap -o seccomp_bpf seccomp_bpf.c:812:67: warning: implicit conversion from 'long' to 'int' changes value from 45812984490 to -1431655766 [-Wconstant-conversion] int kill = kill_how == KILL_PROCESS ? SECCOMP_RET_KILL_PROCESS : 0xAAAAAAAAA; ~~~~ ^~~~~~~~~~~ 1 warning generated. -1431655766 is the expected truncation, 0xAAAAAAAA (8 As), so use this directly in the code to avoid the warning. Fixes: 3932fcecd962 ("selftests/seccomp: Add test for unknown SECCOMP_RET kill behavior") Signed-off-by: YiFei Zhu <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej Fijalkowski <[email protected]> Date: Wed Jun 29 16:34:58 2022 +0200 selftests/xsk: Destroy BPF resources only when ctx refcount drops to 0 [ Upstream commit 39e940d4abfabb08b6937a315546b24d10be67e3 ] Currently, xsk_socket__delete frees BPF resources regardless of ctx refcount. Xdpxceiver has a test to verify whether underlying BPF resources would not be wiped out after closing XSK socket that was bound to interface with other active sockets. From library's xsk part perspective it also means that the internal xsk context is shared and its refcount is bumped accordingly. After a switch to loading XDP prog based on previously opened XSK socket, mentioned xdpxceiver test fails with: not ok 16 [xdpxceiver.c:swap_xsk_resources:1334]: ERROR: 9/"Bad file descriptor which means that in swap_xsk_resources(), xsk_socket__delete() released xskmap which in turn caused a failure of xsk_socket__update_xskmap(). To fix this, when deleting socket, decrement ctx refcount before releasing BPF resources and do so only when refcount dropped to 0 which means there are no more active sockets for this ctx so BPF resources can be freed safely. Fixes: 2f6324a3937f ("libbpf: Support shared umems between queues and devices") Signed-off-by: Maciej Fijalkowski <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Magnus Karlsson <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andrei Vagin <[email protected]> Date: Fri Jul 22 16:02:40 2022 -0700 selftests: kvm: set rax before vmcall [ Upstream commit 281106f938d3daaea6f8b6723a8217a2a1ef6936 ] kvm_hypercall has to place the hypercall number in rax. Trace events show that kvm_pv_test doesn't work properly: kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-53132: kvm_hypercall: nr 0x0 a0 0x0 a1 0x0 a2 0x0 a3 0x0 With this change, it starts working as expected: kvm_pv_test-54285: kvm_hypercall: nr 0x5 a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-54285: kvm_hypercall: nr 0xa a0 0x0 a1 0x0 a2 0x0 a3 0x0 kvm_pv_test-54285: kvm_hypercall: nr 0xb a0 0x0 a1 0x0 a2 0x0 a3 0x0 Signed-off-by: Andrei Vagin <[email protected]> Message-Id: <[email protected]> Fixes: ac4a4d6de22e ("selftests: kvm: test enforcement of paravirtual cpuid features") Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wolfram Sang <[email protected]> Date: Wed Jul 13 22:46:17 2022 +0200 selftests: timers: clocksource-switch: fix passing errors from child [ Upstream commit 4d8f52ac5fa9eede7b7aa2f2d67c841d9eeb655f ] The return value from system() is a waitpid-style integer. Do not return it directly because with the implicit masking in exit() it will always return 0. Access it with appropriate macros to really pass on errors. Fixes: 7290ce1423c3 ("selftests/timers: Add clocksource-switch test from timetest suite") Signed-off-by: Wolfram Sang <[email protected]> Acked-by: John Stultz <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wolfram Sang <[email protected]> Date: Wed Jul 13 22:46:13 2022 +0200 selftests: timers: valid-adjtimex: build fix for newer toolchains [ Upstream commit 9a162977d20436be5678a8e21a8e58eb4616d86a ] Toolchains with an include file 'sys/timex.h' based on 3.18 will have a 'clock_adjtime' definition added, so it can't be static in the code: valid-adjtimex.c:43:12: error: static declaration of ‘clock_adjtime’ follows non-static declaration Fixes: e03a58c320e1 ("kselftests: timers: Add adjtimex SETOFFSET validity tests") Signed-off-by: Wolfram Sang <[email protected]> Acked-by: John Stultz <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiu Jianfeng <[email protected]> Date: Tue Jun 14 10:14:49 2022 +0800 selinux: Add boundary check in put_entry() [ Upstream commit 15ec76fb29be31df2bccb30fc09875274cba2776 ] Just like next_entry(), boundary check is necessary to prevent memory out-of-bound access. Signed-off-by: Xiu Jianfeng <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiu Jianfeng <[email protected]> Date: Mon Jun 13 21:59:53 2022 +0800 selinux: fix memleak in security_read_state_kernel() [ Upstream commit 73de1befcc53a7c68b0c5e76b9b5ac41c517760f ] In this function, it directly returns the result of __security_read_policy without freeing the allocated memory in *data, cause memory leak issue, so free the memory if __security_read_policy failed. Signed-off-by: Xiu Jianfeng <[email protected]> [PM: subject line tweak] Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej W. Rozycki <[email protected]> Date: Mon Apr 18 16:27:33 2022 +0100 serial: 8250: Add proper clock handling for OxSemi PCIe devices [ Upstream commit 366f6c955d4d1a5125ffcd6875ead26a3c7a2a1c ] Oxford Semiconductor PCIe (Tornado) 950 serial port devices are driven by a fixed 62.5MHz clock input derived from the 100MHz PCI Express clock. We currently drive the device using its default oversampling rate of 16 and the clock prescaler disabled, consequently yielding the baud base of 3906250. This base is inadequate for some of the high-speed baud rates such as 460800bps, for which the closest rate possible can be obtained by dividing the baud base by 8, yielding the baud rate of 488281.25bps, which is off by 5.9638%. This is enough for data communication to break with the remote end talking actual 460800bps, where missed stop bits have been observed. We can do better however, by taking advantage of a reduced oversampling rate, which can be set to any integer value from 4 to 16 inclusive by programming the TCR register, and by using the clock prescaler, which can be set to any value from 1 to 63.875 in increments of 0.125 in the CPR/CPR2 register pair. The prescaler has to be explicitly enabled though by setting bit 7 in the MCR or otherwise it is bypassed (in the enhanced mode that we enable) as if the value of 1 was used. Make use of these features then as follows: - Set the baud base to 15625000, reflecting the minimum oversampling rate of 4 with the clock prescaler and divisor both set to 1. - Override the `set_mctrl' and set the MCR shadow there so as to have MCR[7] always set and have the 8250 core propagate these settings. - Override the `get_divisor' handler and determine a good combination of parameters by using a lookup table with predetermined value pairs of the oversampling rate and the clock prescaler and finding a pair that divides the input clock such that the quotient, when rounded to the nearest integer, deviates the least from the exact result. Calculate the clock divisor accordingly. Scale the resulting oversampling rate (only by powers of two) if possible so as to maximise it, reducing the divisor accordingly, and avoid a divisor overflow for very low baud rates by scaling the oversampling rate and/or the prescaler even if that causes some accuracy loss. Also handle the historic spd_cust feature so as to allow one to set all the three parameters manually to arbitrary values, by keeping the low 16 bits for the divisor and then putting TCR in bits 19:16 and CPR/CPR2 in bits 28:20, sanitising the bit pattern supplied such as to clamp CPR/CPR2 values between 0.000 and 0.875 inclusive to 33.875. This preserves compatibility with any existing setups, that is where requesting a custom divisor that only has any bits set among the low 16 the oversampling rate of 16 and the clock prescaler of 33.875 will be used as with the original 8250. Finally abuse the `frac' argument to store the determined bit patterns for the TCR, CPR and CPR2 registers. - Override the `set_divisor' handler so as to set the TCR, CPR and CPR2 registers from the `frac' value supplied. Set the divisor as usual. With the baud base set to 15625000 and the unsigned 16-bit UART_DIV_MAX limitation imposed by `serial8250_get_baud_rate' standard baud rates below 300bps become unavailable in the regular way, e.g. the rate of 200bps requires the baud base to be divided by 78125 and that is beyond the unsigned 16-bit range. The historic spd_cust feature can still be used to obtain such rates if so required. See Documentation/tty/device_drivers/oxsemi-tornado.rst for more details. Signed-off-by: Maciej W. Rozycki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miquel Raynal <[email protected]> Date: Fri Apr 22 20:06:11 2022 +0200 serial: 8250: dma: Allow driver operations before starting DMA transfers [ Upstream commit e4fb03fe10c5e7a5d9aef7cefe815253274fb9ee ] One situation where this could be used is when configuring the UART controller to be the DMA flow controller. This is a typical case where the driver might need to program a few more registers before starting a DMA transfer. Provide the necessary infrastructure to support this case. Suggested-by: Andy Shevchenko <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej W. Rozycki <[email protected]> Date: Mon Apr 18 16:27:27 2022 +0100 serial: 8250: Export ICR access helpers for internal use [ Upstream commit cb5a40e3143bc64437858b337273fd63cc42e9c2 ] Make ICR access helpers available outside 8250_port.c, however retain them as ordinary static functions so as not to regress code generation. This is because `serial_icr_write' is currently automatically inlined by GCC, however `serial_icr_read' is not. Making them both static inline would grow code produced, e.g.: $ i386-linux-gnu-size --format=gnu 8250_port-{old,new}.o text data bss total filename 15065 3378 0 18443 8250_port-old.o 15289 3378 0 18667 8250_port-new.o and: $ riscv64-linux-gnu-size --format=gnu 8250_port-{old,new}.o text data bss total filename 16980 5306 0 22286 8250_port-old.o 17124 5306 0 22430 8250_port-new.o while making them external would needlessly add a new module interface and lose the benefit from `serial_icr_write' getting inlined outside 8250_port.o. Signed-off-by: Maciej W. Rozycki <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maciej W. Rozycki <[email protected]> Date: Mon Apr 18 16:27:22 2022 +0100 serial: 8250: Fold EndRun device support into OxSemi Tornado code [ Upstream commit 1f32c65bad24b9787d3e52843de375430e3df822 ] The EndRun PTP/1588 dual serial port device is based on the Oxford Semiconductor OXPCIe952 UART device with the PCI vendor:device ID set for EndRun Technologies and uses the same sequence to determine the number of ports available. Despite that we have duplicate code specific to the EndRun device. Remove redundant code then and factor out OxSemi Tornado device detection. Signed-off-by: Maciej W. Rozycki <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Doug Berger <[email protected]> Date: Wed Jul 13 20:13:15 2022 -0700 serial: 8250_bcm7271: Save/restore RTS in suspend/resume [ Upstream commit 3182efd036c1b955403d131258234896cbd9fbeb ] Commit 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming from S2") prevented an early enabling of RTS during resume, but it did not actively restore the RTS state after resume. Fixes: 9cabe26e65a8 ("serial: 8250_bcm7271: UART errors after resuming from S2") Signed-off-by: Doug Berger <[email protected]> Signed-off-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Wed Jun 8 12:54:31 2022 +0300 serial: 8250_dw: Store LSR into lsr_saved_flags in dw8250_tx_wait_empty() [ Upstream commit af14f3007e2dca0d112f10f6717ba43093f74e81 ] Make sure LSR flags are preserved in dw8250_tx_wait_empty(). This function is called from a low-level out function and therefore cannot call serial_lsr_in() as it would lead to infinite recursion. It is borderline if the flags need to be saved here at all since this code relates to writing LCR register which usually implies no important characters should be arriving. Fixes: 914eaf935ec7 ("serial: 8250_dw: Allow TX FIFO to drain before writing to UART_LCR") Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 4 10:51:19 2022 +0200 serial: 8250_fsl: Don't report FE, PE and OE twice [ Upstream commit 9d3aaceb73acadf134596a2f8db9c451c1332d3d ] Some Freescale 8250 implementations have the problem that a single long break results in one irq per character frame time. The code in fsl8250_handle_irq() that is supposed to handle that uses the BI bit in lsr_saved_flags to detect such a situation and then skip the second received character. However it also stores other error bits and so after a single frame error the character received in the next irq handling is passed to the upper layer with a frame error, too. So after a spike on the data line (which is correctly recognized as a frame error) the following valid character is thrown away, because the driver reports a frame error for that one, too. To weaken this problem restrict saving LSR to only the BI bit. Note however that the handling is still broken: - lsr_saved_flags is updated using orig_lsr which is the LSR content for the first received char, but there might be more in the FIFO, so a character is thrown away that is received later and not necessarily the one following the break. - The doubled break might be the 2nd and 3rd char in the FIFO, so the workaround doesn't catch these, because serial8250_rx_chars() doesn't handle the workaround. - lsr_saved_flags might have set UART_LSR_BI at the entry of fsl8250_handle_irq() which doesn't originate from fsl8250_handle_irq()'s "up->lsr_saved_flags |= orig_lsr & UART_LSR_BI;" but from e.g. from serial8250_tx_empty(). - For a long or a short break this isn't about two characters, but more or only a single one. Fixes: 9deaa53ac7fa ("serial: add irq handler for Freescale 16550 errata.") Acked-by: Ilpo Järvinen <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Fri Oct 22 16:51:45 2021 +0300 serial: 8250_pci: Refactor the loop in pci_ite887x_init() [ Upstream commit 35b4f17231923e2f64521bdf7a2793ce2c3c74a6 ] The loop can be refactored by using ARRAY_SIZE() instead of NULL terminator. This reduces code base and makes it easier to read and understand. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Fri Oct 22 16:51:47 2021 +0300 serial: 8250_pci: Replace dev_*() by pci_*() macros [ Upstream commit 1177384179416c7136e1348f07609e0da1ae6b91 ] PCI subsystem provides convenient shortcut macros for message printing. Use those macros instead of dev_*(). Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Narendra Hadke <[email protected]> Date: Tue Jul 26 11:12:21 2022 +0200 serial: mvebu-uart: uart2 error bits clearing commit a7209541239e5dd44d981289e5f9059222d40fd1 upstream. For mvebu uart2, error bits are not cleared on buffer read. This causes interrupt loop and system hang. Cc: [email protected] Reviewed-by: Yi Guo <[email protected]> Reviewed-by: Nadav Haklai <[email protected]> Signed-off-by: Narendra Hadke <[email protected]> Signed-off-by: Pali Rohár <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liu Jian <[email protected]> Date: Tue Jun 28 20:36:16 2022 +0800 skmsg: Fix invalid last sg check in sk_msg_recvmsg() [ Upstream commit 9974d37ea75f01b47d16072b5dad305bd8d23fcc ] In sk_psock_skb_ingress_enqueue function, if the linear area + nr_frags + frag_list of the SKB has NR_MSG_FRAG_IDS blocks in total, skb_to_sgvec will return NR_MSG_FRAG_IDS, then msg->sg.end will be set to NR_MSG_FRAG_IDS, and in addition, (NR_MSG_FRAG_IDS - 1) is set to the last SG of msg. Recv the msg in sk_msg_recvmsg, when i is (NR_MSG_FRAG_IDS - 1), the sk_msg_iter_var_next(i) will change i to 0 (not NR_MSG_FRAG_IDS), the judgment condition "msg_rx->sg.start==msg_rx->sg.end" and "i != msg_rx->sg.end" can not work. As a result, the processed msg cannot be deleted from ingress_msg list. But the length of all the sge of the msg has changed to 0. Then the next recvmsg syscall will process the msg repeatedly, because the length of sge is 0, the -EFAULT error is always returned. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Liu Jian <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bharath SM <[email protected]> Date: Thu Aug 11 19:46:11 2022 +0000 SMB3: fix lease break timeout when multiple deferred close handles for the same file. commit 9e31678fb403eae0f4fe37c6374be098835c73cd upstream. Solution is to send lease break ack immediately even in case of deferred close handles to avoid lease break request timing out and let deferred closed handle gets closed as scheduled. Later patches could optimize cases where we then close some of these handles sooner for the cases where lease break is to 'none' Cc: [email protected] Signed-off-by: Bharath SM <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liang He <[email protected]> Date: Thu Jun 16 22:49:15 2022 +0800 soc: amlogic: Fix refcount leak in meson-secure-pwrc.c [ Upstream commit d18529a4c12f66d83daac78045ea54063bd43257 ] In meson_secure_pwrc_probe(), there is a refcount leak in one fail path. Signed-off-by: Liang He <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Fixes: b3dde5013e13 ("soc: amlogic: Add support for Secure power domains controller") Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Walle <[email protected]> Date: Mon Apr 4 11:56:03 2022 +0200 soc: fsl: guts: machine variable might be unset [ Upstream commit ab3f045774f704c4e7b6a878102f4e9d4ae7bc74 ] If both the model and the compatible properties are missing, then machine will not be set. Initialize it with NULL. Fixes: 34c1c21e94ac ("soc: fsl: fix section mismatch build warnings") Signed-off-by: Michael Walle <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Mon Jun 6 10:42:52 2022 +0400 soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register [ Upstream commit e6e0951414a314e7db3e9e24fd924b3e15515288 ] Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. When breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node. Add missing of_node_put() to avoid refcount leak. Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Signed-off-by: Miaoqian Lin <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Jul 7 23:21:58 2022 +0200 soc: qcom: Make QCOM_RPMPD depend on PM [ Upstream commit a6232f2aa99ce470799992e99e0012945bb5308f ] QCOM_RPMPD requires PM_GENERIC_DOMAINS/_OF, which in turns requires CONFIG_PM. I forgot about the latter in my earlier patch (it's still in -next as of the time of committing, hence no Fixes: tag). Fix it. Reported-by: kernel test robot <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu Jun 2 08:24:30 2022 +0400 soc: qcom: ocmem: Fix refcount leak in of_get_ocmem [ Upstream commit 92a563fcf14b3093226fb36f12e9b5cf630c5a5d ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer. Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Signed-off-by: Miaoqian Lin <[email protected]> Reviewed-by: Brian Masney <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Wed Jun 8 15:51:35 2022 +0200 soc: renesas: r8a779a0-sysc: Fix A2DP1 and A2CV[2357] PDR values [ Upstream commit bccceabb92ce8eb78bbf2de08308e2cc2761a2e5 ] The PDR values for the A2DP1 and A2CV[2357] power areas on R-Car V3U are incorrect (copied-and-pasted from A2DP0 and A2CV[0146]). Fix them. Reported-by: Renesas Vietnam via Yoshihiro Shimoda <[email protected]> Fixes: 1b4298f000064cc2 ("soc: renesas: r8a779a0-sysc: Add r8a779a0 support") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/87bc2e70ba4082970cf8c65871beae4be3503189.1654696188.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <[email protected]>
Author: Pierre-Louis Bossart <[email protected]> Date: Fri Jun 10 09:51:05 2022 +0800 soundwire: bus_type: fix remove and shutdown support [ Upstream commit df6407782964dc7e35ad84230abb38f46314b245 ] The bus sdw_drv_remove() and sdw_drv_shutdown() helpers are used conditionally, if the driver provides these routines. These helpers already test if the driver provides a .remove or .shutdown callback, so there's no harm in invoking the sdw_drv_remove() and sdw_drv_shutdown() unconditionally. In addition, the current code is imbalanced with dev_pm_domain_attach() called from sdw_drv_probe(), but dev_pm_domain_detach() called from sdw_drv_remove() only if the driver provides a .remove callback. Fixes: 9251345dca24b ("soundwire: Add SoundWire bus type") Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Rander Wang <[email protected]> Signed-off-by: Bard Liao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivas Kandagatla <[email protected]> Date: Wed Jul 6 10:56:44 2022 +0100 soundwire: qcom: Check device status before reading devid commit aa1262ca66957183ea1fb32a067e145b995f3744 upstream. As per hardware datasheet its recommended that we check the device status before reading devid assigned by auto-enumeration. Without this patch we see SoundWire devices with invalid enumeration addresses on the bus. Cc: [email protected] Fixes: a6e6581942ca ("soundwire: qcom: add auto enumeration support") Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pierre-Louis Bossart <[email protected]> Date: Tue Jun 21 17:56:38 2022 -0500 soundwire: revisit driver bind/unbind and callbacks [ Upstream commit bd29c00edd0a5dac8b6e7332bb470cd50f92e893 ] In the SoundWire probe, we store a pointer from the driver ops into the 'slave' structure. This can lead to kernel oopses when unbinding codec drivers, e.g. with the following sequence to remove machine driver and codec driver. /sbin/modprobe -r snd_soc_sof_sdw /sbin/modprobe -r snd_soc_rt711 The full details can be found in the BugLink below, for reference the two following examples show different cases of driver ops/callbacks being invoked after the driver .remove(). kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150 kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence] kernel: RIP: 0010:mutex_lock+0x19/0x30 kernel: Call Trace: kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae] kernel: ? newidle_balance+0x26a/0x400 kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: BUG: unable to handle page fault for address: ffffffffc07654c8 kernel: Workqueue: pm pm_runtime_work kernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus] kernel: Call Trace: kernel: <TASK> kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82] kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd] kernel: ? dpm_sysfs_remove+0x60/0x60 This was not detected earlier in Intel tests since the tests first remove the parent PCI device and shut down the bus. The sequence above is a corner case which keeps the bus operational but without a driver bound. While trying to solve this kernel oopses, it became clear that the existing SoundWire bus does not deal well with the unbind case. Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields") added a 'probed' status variable and a 'probe_complete' struct completion. This status is however not reset on remove and likewise the 'probe complete' is not re-initialized, so the bind/unbind/bind test cases would fail. The timeout used before the 'update_status' callback was also a bad idea in hindsight, there should really be no timing assumption as to if and when a driver is bound to a device. An initial draft was based on device_lock() and device_unlock() was tested. This proved too complicated, with deadlocks created during the suspend-resume sequences, which also use the same device_lock/unlock() as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOS caused spurious resumes and the use of device_lock() caused hangs during suspend. After multiple weeks or testing and painful reverse-engineering of deadlocks on different devices, we looked for alternatives that did not interfere with the device core. A bus notifier was used successfully to keep track of DRIVER_BOUND and DRIVER_UNBIND events. This solved the bind-unbind-bind case in tests, but it can still be defeated with a theoretical corner case where the memory is freed by a .remove while the callback is in use. The notifier only helps make sure the driver callbacks are valid, but not that the memory allocated in probe remains valid while the callbacks are invoked. This patch suggests the introduction of a new 'sdw_dev_lock' mutex protecting probe/remove and all driver callbacks. Since this mutex is 'local' to SoundWire only, it does not interfere with existing locks and does not create deadlocks. In addition, this patch removes the 'probe_complete' completion, instead we directly invoke the 'update_status' from the probe routine. That removes any sort of timing dependency and a much better support for the device/driver model, the driver could be bound before the bus started, or eons after the bus started and the hardware would be properly initialized in all cases. BugLink: https://github.com/thesofproject/linux/issues/3531 Fixes: 56d4fe31af77 ("soundwire: Add MIPI DisCo property helpers") Fixes: 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields") Signed-off-by: Pierre-Louis Bossart <[email protected]> Reviewed-by: Rander Wang <[email protected]> Reviewed-by: Ranjani Sridharan <[email protected]> Reviewed-by: Bard Liao <[email protected]> Reviewed-by: Péter Ujfalusi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Yingliang <[email protected]> Date: Tue Jul 12 21:55:04 2022 +0800 spi: Fix simplification of devm_spi_register_controller [ Upstream commit 43cc5a0afe4184a7fafe1eba32b5a11bb69c9ce0 ] This reverts commit 59ebbe40fb51 ("spi: simplify devm_spi_register_controller"). If devm_add_action() fails in devm_add_action_or_reset(), devm_spi_unregister() will be called, it decreases the refcount of 'ctlr->dev' to 0, then it will cause uaf in the drivers that calling spi_put_controller() in error path. Fixes: 59ebbe40fb51 ("spi: simplify devm_spi_register_controller") Signed-off-by: Yang Yingliang <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sun May 29 08:31:53 2022 +0200 spi: spi-altera-dfl: Fix an error handling path [ Upstream commit 8e3ca32f46994e74b7f43c57731150b2aedb2630 ] The spi_alloc_master() call is not undone in all error handling paths. Moreover, there is no .remove function to release the allocated memory. In order to fix both this issues, switch to devm_spi_alloc_master(). This allows further simplification of the probe. Fixes: ba2fc167e944 ("spi: altera: Add DFL bus driver for Altera API Controller") Signed-off-by: Christophe JAILLET <[email protected]> Link: https://lore.kernel.org/r/0607bb59f4073f86abe5c585d35245aef0b045c6.1653805901.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Biju Das <[email protected]> Date: Thu Jul 21 15:34:49 2022 +0100 spi: spi-rspi: Fix PIO fallback on RZ platforms [ Upstream commit b620aa3a7be346f04ae7789b165937615c6ee8d3 ] RSPI IP on RZ/{A, G2L} SoC's has the same signal for both interrupt and DMA transfer request. Setting DMARS register for DMA transfer makes the signal to work as a DMA transfer request signal and subsequent interrupt requests to the interrupt controller are masked. PIO fallback does not work as interrupt signal is disabled. This patch fixes this issue by re-enabling the interrupts by calling dmaengine_synchronize(). Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guo Mengqi <[email protected]> Date: Fri Jun 24 08:56:14 2022 +0800 spi: synquacer: Add missing clk_disable_unprepare() [ Upstream commit 917e43de2a56d9b82576f1cc94748261f1988458 ] Add missing clk_disable_unprepare() in synquacer_spi_resume(). Reported-by: Hulk Robot <[email protected]> Signed-off-by: Guo Mengqi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Yingliang <[email protected]> Date: Wed Jul 13 17:40:23 2022 +0800 spi: tegra20-slink: fix UAF in tegra_slink_remove() [ Upstream commit 7e9984d183bb1e99e766c5c2b950ff21f7f7b6c0 ] After calling spi_unregister_master(), the refcount of master will be decrease to 0, and it will be freed in spi_controller_release(), the device data also will be freed, so it will lead a UAF when using 'tspi'. To fix this, get the master before unregister and put it when finish using it. Fixes: 26c863418221 ("spi: tegra20-slink: Don't use resource-managed spi_register helper") Signed-off-by: Yang Yingliang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Collins <[email protected]> Date: Mon Jun 27 16:55:12 2022 -0700 spmi: trace: fix stack-out-of-bound access in SPMI tracing functions commit 2af28b241eea816e6f7668d1954f15894b45d7e3 upstream. trace_spmi_write_begin() and trace_spmi_read_end() both call memcpy() with a length of "len + 1". This leads to one extra byte being read beyond the end of the specified buffer. Fix this out-of-bound memory access by using a length of "len" instead. Here is a KASAN log showing the issue: BUG: KASAN: stack-out-of-bounds in trace_event_raw_event_spmi_read_end+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task [email protected]/1314 ... Call trace: dump_backtrace+0x0/0x3e8 show_stack+0x2c/0x3c dump_stack_lvl+0xdc/0x11c print_address_description+0x74/0x384 kasan_report+0x188/0x268 kasan_check_range+0x270/0x2b0 memcpy+0x90/0xe8 trace_event_raw_event_spmi_read_end+0x1d0/0x234 spmi_read_cmd+0x294/0x3ac spmi_ext_register_readl+0x84/0x9c regmap_spmi_ext_read+0x144/0x1b0 [regmap_spmi] _regmap_raw_read+0x40c/0x754 regmap_raw_read+0x3a0/0x514 regmap_bulk_read+0x418/0x494 adc5_gen3_poll_wait_hs+0xe8/0x1e0 [qcom_spmi_adc5_gen3] ... __arm64_sys_read+0x4c/0x60 invoke_syscall+0x80/0x218 el0_svc_common+0xec/0x1c8 ... addr ffffffc0265b7540 is located in stack of task [email protected]/1314 at offset 32 in frame: adc5_gen3_poll_wait_hs+0x0/0x1e0 [qcom_spmi_adc5_gen3] this frame has 1 object: [32, 33) 'status' Memory state around the buggy address: ffffffc0265b7400: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 ffffffc0265b7480: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffc0265b7500: 00 00 00 00 f1 f1 f1 f1 01 f3 f3 f3 00 00 00 00 ^ ffffffc0265b7580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffc0265b7600: f1 f1 f1 f1 01 f2 07 f2 f2 f2 01 f3 00 00 00 00 ================================================================== Fixes: a9fce374815d ("spmi: add command tracepoints for SPMI") Cc: [email protected] Reviewed-by: Stephen Boyd <[email protected]> Acked-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: David Collins <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: GONG, Ruiqi <[email protected]> Date: Wed Jun 29 14:04:23 2022 +0800 stack: Declare {randomize_,}kstack_offset to fix Sparse warnings [ Upstream commit 375561bd6195a31bf4c109732bd538cb97a941f4 ] Fix the following Sparse warnings that got noticed when the PPC-dev patchwork was checking another patch (see the link below): init/main.c:862:1: warning: symbol 'randomize_kstack_offset' was not declared. Should it be static? init/main.c:864:1: warning: symbol 'kstack_offset' was not declared. Should it be static? Which in fact are triggered on all architectures that have HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET support (for instances x86, arm64 etc). Link: https://lore.kernel.org/lkml/[email protected]/T/#m49b2d4490121445ce4bf7653500aba59eefcb67f Cc: Christophe Leroy <[email protected]> Cc: Xiu Jianfeng <[email protected]> Signed-off-by: GONG, Ruiqi <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall") Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Duoming Zhou <[email protected]> Date: Sun Jul 10 18:30:02 2022 +0800 staging: rtl8192u: Fix sleep in atomic context bug in dm_fsync_timer_callback [ Upstream commit 6a0c054930d554ad8f8044ef1fc856d9da391c81 ] There are sleep in atomic context bugs when dm_fsync_timer_callback is executing. The root cause is that the memory allocation functions with GFP_KERNEL or GFP_NOIO parameters are called in dm_fsync_timer_callback which is a timer handler. The call paths that could trigger bugs are shown below: (interrupt context) dm_fsync_timer_callback write_nic_byte kzalloc(sizeof(data), GFP_KERNEL); //may sleep usb_control_msg kmalloc(.., GFP_NOIO); //may sleep write_nic_dword kzalloc(sizeof(data), GFP_KERNEL); //may sleep usb_control_msg kmalloc(.., GFP_NOIO); //may sleep This patch uses delayed work to replace timer and moves the operations that may sleep into the delayed work in order to mitigate bugs. Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Duoming Zhou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Robin Murphy <[email protected]> Date: Tue Jul 12 08:46:45 2022 +0200 swiotlb: fail map correctly with failed io_tlb_default_mem [ Upstream commit c51ba246cb172c9e947dc6fb8868a1eaf0b2a913 ] In the failure case of trying to use a buffer which we'd previously failed to allocate, the "!mem" condition is no longer sufficient since io_tlb_default_mem became static and assigned by default. Update the condition to work as intended per the rest of that conversion. Fixes: 463e862ac63e ("swiotlb: Convert io_default_tlb_mem to static allocation") Signed-off-by: Robin Murphy <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Jun 14 10:17:33 2022 -0700 tcp: fix over estimation in sk_forced_mem_schedule() commit c4ee118561a0f74442439b7b5b486db1ac1ddfeb upstream. sk_forced_mem_schedule() has a bug similar to ones fixed in commit 7c80b038d23e ("net: fix sk_wmem_schedule() and sk_rmem_schedule() errors") While this bug has little chance to trigger in old kernels, we need to fix it before the following patch. Fixes: d83769a580f1 ("tcp: fix possible deadlock in tcp_send_fin()") Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Reviewed-by: Shakeel Butt <[email protected]> Reviewed-by: Wei Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yonglong Li <[email protected]> Date: Mon Jul 11 17:47:18 2022 +0800 tcp: make retransmitted SKB fit into the send window [ Upstream commit 536a6c8e05f95e3d1118c40ae8b3022ee2d05d52 ] current code of __tcp_retransmit_skb only check TCP_SKB_CB(skb)->seq in send window, and TCP_SKB_CB(skb)->seq_end maybe out of send window. If receiver has shrunk his window, and skb is out of new window, it should retransmit a smaller portion of the payload. test packetdrill script: 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 fcntl(3, F_GETFL) = 0x2 (flags O_RDWR) +0 fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress) +0 > S 0:0(0) win 65535 <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 8> +.05 < S. 0:0(0) ack 1 win 6000 <mss 1000,nop,nop,sackOK> +0 > . 1:1(0) ack 1 +0 write(3, ..., 10000) = 10000 +0 > . 1:2001(2000) ack 1 win 65535 +0 > . 2001:4001(2000) ack 1 win 65535 +0 > . 4001:6001(2000) ack 1 win 65535 +.05 < . 1:1(0) ack 4001 win 1001 and tcpdump show: 192.168.226.67.55 > 192.0.2.1.8080: Flags [.], seq 1:2001, ack 1, win 65535, length 2000 192.168.226.67.55 > 192.0.2.1.8080: Flags [.], seq 2001:4001, ack 1, win 65535, length 2000 192.168.226.67.55 > 192.0.2.1.8080: Flags [P.], seq 4001:5001, ack 1, win 65535, length 1000 192.168.226.67.55 > 192.0.2.1.8080: Flags [.], seq 5001:6001, ack 1, win 65535, length 1000 192.0.2.1.8080 > 192.168.226.67.55: Flags [.], ack 4001, win 1001, length 0 192.168.226.67.55 > 192.0.2.1.8080: Flags [.], seq 5001:6001, ack 1, win 65535, length 1000 192.168.226.67.55 > 192.0.2.1.8080: Flags [P.], seq 4001:5001, ack 1, win 65535, length 1000 when cient retract window to 1001, send window is [4001,5002], but TLP send 5001-6001 packet which is out of send window. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yonglong Li <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Shen <[email protected]> Date: Wed Jun 22 21:50:02 2022 +0800 test_bpf: fix incorrect netdev features [ Upstream commit 9676feccacdb0571791c88b23e3b7ac4e7c9c457 ] The prototype of .features is netdev_features_t, it should use NETIF_F_LLTX and NETIF_F_HW_VLAN_STAG_TX, not NETIF_F_LLTX_BIT and NETIF_F_HW_VLAN_STAG_TX_BIT. Fixes: cf204a718357 ("bpf, testing: Introduce 'gso_linear_no_head_frag' skb_segment test") Signed-off-by: Jian Shen <[email protected]> Acked-by: John Fastabend <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Markus Mayer <[email protected]> Date: Sun Jul 17 20:10:39 2022 -0700 thermal/tools/tmon: Include pthread and time headers in tmon.h [ Upstream commit 0cf51bfe999524377fbb71becb583b4ca6d07cfc ] Include sys/time.h and pthread.h in tmon.h, so that types "pthread_mutex_t" and "struct timeval tv" are known when tmon.h references them. Without these headers, compiling tmon against musl-libc will fail with these errors: In file included from sysfs.c:31:0: tmon.h:47:8: error: unknown type name 'pthread_mutex_t' extern pthread_mutex_t input_lock; ^~~~~~~~~~~~~~~ make[3]: *** [<builtin>: sysfs.o] Error 1 make[3]: *** Waiting for unfinished jobs.... In file included from tui.c:31:0: tmon.h:54:17: error: field 'tv' has incomplete type struct timeval tv; ^~ make[3]: *** [<builtin>: tui.o] Error 1 make[2]: *** [Makefile:83: tmon] Error 2 Signed-off-by: Markus Mayer <[email protected]> Acked-by: Florian Fainelli <[email protected]> Reviewed-by: Sumeet Pawnikar <[email protected]> Acked-by: Alejandro González <[email protected]> Tested-by: Alejandro González <[email protected]> Fixes: 94f69966faf8 ("tools/thermal: Introduce tmon, a tool for thermal subsystem") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Lezcano <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Fri Jul 29 17:39:07 2022 +0200 thermal: sysfs: Fix cooling_device_stats_setup() error code path commit d5a8aa5d7d80d21ab6b266f1bed4194b61746199 upstream. If cooling_device_stats_setup() fails to create the stats object, it must clear the last slot in cooling_device_attr_groups that was initially empty (so as to make it possible to add stats attributes to the cooling device attribute groups). Failing to do so may cause the stats attributes to be created by mistake for a device that doesn't have a stats object, because the slot in question might be populated previously during the registration of another cooling device. Fixes: 8ea229511e06 ("thermal: Add cooling device's statistics in sysfs") Reported-by: Di Shen <[email protected]> Tested-by: Di Shen <[email protected]> Cc: 4.17+ <[email protected]> # 4.17+ Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Sun Jul 17 23:53:34 2022 +0200 timekeeping: contribute wall clock to rng on time change [ Upstream commit b8ac29b40183a6038919768b5d189c9bd91ce9b4 ] The rng's random_init() function contributes the real time to the rng at boot time, so that events can at least start in relation to something particular in the real world. But this clock might not yet be set that point in boot, so nothing is contributed. In addition, the relation between minor clock changes from, say, NTP, and the cycle counter is potentially useful entropic data. This commit addresses this by mixing in a time stamp on calls to settimeofday and adjtimex. No entropy is credited in doing so, so it doesn't make initialization faster, but it is still useful input to have. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: [email protected] Reviewed-by: Thomas Gleixner <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Mon Jul 25 10:37:54 2022 -0700 tools/thermal: Fix possible path truncations [ Upstream commit 6c58cf40e3a1d2f47c09d3489857e9476316788a ] A build with -D_FORTIFY_SOURCE=2 enabled will produce the following warnings: sysfs.c:63:30: warning: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 255 [-Wformat-truncation=] snprintf(filepath, 256, "%s/%s", path, filename); ^~ Bump up the buffer to PATH_MAX which is the limit and account for all of the possible NUL and separators that could lead to exceeding the allocated buffer sizes. Fixes: 94f69966faf8 ("tools/thermal: Introduce tmon, a tool for thermal subsystem") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Huacai Chen <[email protected]> Date: Mon Jul 11 09:17:38 2022 +0800 tpm: eventlog: Fix section mismatch for DEBUG_SECTION_MISMATCH [ Upstream commit bed4593645366ad7362a3aa7bc0d100d8d8236a8 ] If DEBUG_SECTION_MISMATCH enabled, __calc_tpm2_event_size() will not be inlined, this cause section mismatch like this: WARNING: modpost: vmlinux.o(.text.unlikely+0xe30c): Section mismatch in reference from the variable L0 to the function .init.text:early_ioremap() The function L0() references the function __init early_memremap(). This is often because L0 lacks a __init annotation or the annotation of early_ioremap is wrong. Fix it by using __always_inline instead of inline for the called-once function __calc_tpm2_event_size(). Fixes: 44038bc514a2 ("tpm: Abstract crypto agile event size calculations") Cc: [email protected] # v5.3 Reported-by: WANG Xuerui <[email protected]> Signed-off-by: Huacai Chen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Tue Jan 25 14:00:37 2022 -0800 tracing/perf: Avoid -Warray-bounds warning for __rel_loc macro commit c6d777acdf8f62d4ebaef0e5c6cd8fedbd6e8546 upstream. As done for trace_events.h, also fix the __rel_loc macro in perf.h, which silences the -Warray-bounds warning: In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:11, from ./include/linux/cpumask.h:12, from ./include/linux/mm_types_task.h:14, from ./include/linux/mm_types.h:5, from ./include/linux/buildid.h:5, from ./include/linux/module.h:14, from samples/trace_events/trace-events-sample.c:2: In function '__fortify_strcpy', inlined from 'perf_trace_foo_rel_loc' at samples/trace_events/./trace-events-sample.h:519:1: ./include/linux/fortify-string.h:47:33: warning: '__builtin_strcpy' offset 12 is out of the bounds [ 0, 4] [-Warray-bounds] 47 | #define __underlying_strcpy __builtin_strcpy | ^ ./include/linux/fortify-string.h:445:24: note: in expansion of macro '__underlying_strcpy' 445 | return __underlying_strcpy(p, q); | ^~~~~~~~~~~~~~~~~~~ Also make __data struct member a proper flexible array to avoid future problems. Link: https://lkml.kernel.org/r/[email protected] Cc: Steven Rostedt <[email protected]> Cc: Masami Hiramatsu <[email protected]> Fixes: 55de2c0b5610c ("tracing: Add '__rel_loc' using trace event macros") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Masami Hiramatsu <[email protected]> Date: Mon Nov 22 18:30:21 2021 +0900 tracing: Add '__rel_loc' using trace event macros [ Upstream commit 55de2c0b5610cba5a5a93c0788031133c457e689 ] Add '__rel_loc' using trace event macros. These macros are usually not used in the kernel, except for testing purpose. This also add "rel_" variant of macros for dynamic_array string, and bitmask. Link: https://lkml.kernel.org/r/163757342119.510314.816029622439099016.stgit@devnote2 Cc: Beau Belgrave <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Tom Zanussi <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu <[email protected]> Date: Tue Jan 25 23:19:30 2022 +0900 tracing: Avoid -Warray-bounds warning for __rel_loc macro [ Upstream commit 58c5724ec2cdd72b22107ec5de00d90cc4797796 ] Since -Warray-bounds checks the destination size from the type of given pointer, __assign_rel_str() macro gets warned because it passes the pointer to the 'u32' field instead of 'trace_event_raw_*' data structure. Pass the data address calculated from the 'trace_event_raw_*' instead of 'u32' __rel_loc field. Link: https://lkml.kernel.org/r/[email protected] Cc: Stephen Rothwell <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> [ This did not fix the warning, but is still a nice clean up ] Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Steven Rostedt (Google) <[email protected]> Date: Sun Jul 31 01:59:28 2022 -0400 tracing: Use a struct alignof to determine trace event field alignment commit 4c3d2f9388d36eb28640a220a6f908328442d873 upstream. alignof() gives an alignment of types as they would be as standalone variables. But alignment in structures might be different, and when building the fields of events, the alignment must be the actual alignment otherwise the field offsets may not match what they actually are. This caused trace-cmd to crash, as libtraceevent did not check if the field offset was bigger than the event. The write_msr and read_msr events on 32 bit had their fields incorrect, because it had a u64 field between two ints. alignof(u64) would give 8, but the u64 field was at a 4 byte alignment. Define a macro as: ALIGN_STRUCTFIELD(type) ((int)(offsetof(struct {char a; type b;}, b))) which gives the actual alignment of types in a structure. Link: https://lkml.kernel.org/r/[email protected] Cc: Ingo Molnar <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Masami Hiramatsu <[email protected]> Cc: [email protected] Fixes: 04ae87a52074e ("ftrace: Rework event_create_dir()") Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Cameron Williams <[email protected]> Date: Mon Jul 11 16:35:10 2022 +0100 tty: 8250: Add support for Brainboxes PX cards. [ Upstream commit ef5a03a26c87a760bc3d86b5af7b773e82f8b1b7 ] Add support for some of the Brainboxes PCIe (PX) range of serial cards, including the PX-101, PX-235/PX-246, PX-203/PX-257, PX-260/PX-701, PX-310, PX-313, PX-320/PX-324/PX-376/PX-387, PX-335/PX-346, PX-368, PX-420, PX-803 and PX-846. Signed-off-by: Cameron Williams <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/AM5PR0202MB2564669252BDC59BF55A6E87C4879@AM5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhenguo Zhao <[email protected]> Date: Fri Aug 20 20:17:50 2021 +0800 tty: n_gsm: Delete gsmtty open SABM frame when config requester [ Upstream commit cbff2b32516881bef30bbebf413d1b49495bab1d ] When n_gsm config "initiator=0",as requester ,it doesn't need to send SABM frame data during gsmtty open. Example,when gsmtty open,it will send SABM frame.for initiator,it maybe not want to receive the frame. [ 88.410426] c1 gsmld_output: 00000000: f9 07 3f 01 de f9 [ 88.420839] c1 --> 1) R: SABM(F) Signed-off-by: Zhenguo Zhao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:21 2022 +0200 tty: n_gsm: fix DM command [ Upstream commit 18a948c7d90995d127785e308fa7b701df4c499f ] n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.3.3 defines the DM response. There exists no DM command. However, the current implementation incorrectly sends DM as command in case of unexpected UIH frames in gsm_queue(). Correct this behavior by always sending DM as response. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:23 2022 +0200 tty: n_gsm: fix missing corner cases in gsmld_poll() [ Upstream commit 7e5b4322cde067e1d0f1bf8f490e93f664a7c843 ] gsmld_poll() currently fails to handle the following corner cases correctly: - remote party closed the associated tty Add the missing checks and map those to EPOLLHUP. Reorder the checks to group them by their reaction. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:47 2022 +0200 tty: n_gsm: fix missing timer to handle stalled links [ Upstream commit c568f7086c6e771c77aad13d727c70ef70e07243 ] The current implementation does not handle the situation that no data is in the internal queue and needs to be sent out while the user tty fifo is full. Add a timer that moves more data from user tty down to the internal queue which is then serialized on the ldisc. This timer is triggered if no data was moved from a user tty to the internal queue within 10 * T1. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:48 2022 +0200 tty: n_gsm: fix non flow control frames during mux flow off [ Upstream commit bec0224816d19abe4fe503586d16d51890540615 ] n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.4.6.3.6 states that FCoff stops the transmission on all channels except the control channel. This is already implemented in gsm_data_kick(). However, chapter 5.4.8.1 explains that this shall result in the same behavior as software flow control on the ldisc in advanced option mode. That means only flow control frames shall be sent during flow off. The current implementation does not consider this case. Change gsm_data_kick() to send only flow control frames if constipated to abide the standard. gsm_read_ea_val() and gsm_is_flow_ctrl_msg() are introduced as helper functions for this. It is planned to use gsm_read_ea_val() in later code cleanups for other functions, too. Fixes: c01af4fec2c8 ("n_gsm : Flow control handling in Mux driver") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:50 2022 +0200 tty: n_gsm: fix packet re-transmission without open control channel [ Upstream commit 4fae831b3a71fc5a44cc5c7d0b8c1267ee7659f5 ] In the current implementation control packets are re-transmitted even if the control channel closed down during T2. This is wrong. Check whether the control channel is open before re-transmitting any packets. Note that control channel open/close is handled by T1 and not T2 and remains unaffected by this. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:52 2022 +0200 tty: n_gsm: fix race condition in gsmld_write() [ Upstream commit 32dd59f96924f45e33bc79854f7a00679c0fa28e ] The function may be used by the user directly and also by the n_gsm internal functions. They can lead into a race condition which results in interleaved frames if both are writing at the same time. The receiving side is not able to decode those interleaved frames correctly. Add a lock around the low side tty write to avoid race conditions and frame interleaving between user originated writes and n_gsm writes. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 14:23:32 2022 +0200 tty: n_gsm: fix resource allocation order in gsm_activate_mux() [ Upstream commit 7349660438603ed19282e75949561406531785a5 ] Within gsm_activate_mux() all timers and locks are initiated before the actual resource for the control channel is allocated. This can lead to race conditions. Allocate the control channel DLCI object first to avoid race conditions. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:45 2022 +0200 tty: n_gsm: fix tty registration before control channel open [ Upstream commit 01aecd917114577c423f07cec0d186ad007d76fc ] The current implementation registers/deregisters the user ttys at mux attach/detach. That means that the user devices are available before any control channel is open. However, user channel initialization requires an open control channel. Furthermore, the user is not informed if the mux restarts due to configuration changes. Put the registration/deregistration procedure into separate function to improve readability. Move registration to mux activation and deregistration to mux cleanup to keep the user devices only open as long as a control channel exists. The user will be informed via the device driver if the mux was reconfigured in a way that required a mux re-activation. This makes it necessary to add T2 initialization to gsmld_open() for the ldisc open code path (not the reconfiguration code path) to avoid deletion of an uninitialized T2 at mux cleanup. Fixes: d50f6dcaf22a ("tty: n_gsm: expose gsmtty device nodes at ldisc open time") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:44 2022 +0200 tty: n_gsm: fix user open not possible at responder until initiator open [ Upstream commit ac77f0077c3265197d378158c85a55eee6d21508 ] After setting up the control channel on both sides the responder side may want to open a virtual tty to listen on until the initiator starts an application on a user channel. The current implementation allows the open() but no other operation, like termios. These fail with EINVAL. The responder sided application has no means to detect an open by the initiator sided application this way. And the initiator sided applications usually expect the responder sided application to listen on the user channel upon open. Set the user channel into half-open state on responder side once a user application opens the virtual tty to allow IO operations on it. Furthermore, keep the user channel constipated until the initiator side opens it to give the responder sided application the chance to detect the new connection and to avoid data loss if the responder sided application starts sending before the user channel is open. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Fri Jul 1 08:16:46 2022 +0200 tty: n_gsm: fix wrong queuing behavior in gsm_dlci_data_output() [ Upstream commit 556fc8ac06513cced381588d6d58c184d95cc4fe ] 1) The function drains the fifo for the given user tty/DLCI without considering 'TX_THRESH_HI' and different to gsm_dlci_data_output_framed(), which moves only one packet from the user side to the internal transmission queue. We can only handle one packet at a time here if we want to allow DLCI priority handling in gsm_dlci_data_sweep() to avoid link starvation. 2) Furthermore, the additional header octet from convergence layer type 2 is not counted against MTU. It is part of the UI/UIH frame message which needs to be limited to MTU. Hence, it is wrong not to consider this octet. 3) Finally, the waiting user tty is not informed about freed space in its send queue. Take at most one packet worth of data out of the DLCI fifo to fix 1). Limit the max user data size per packet to MTU - 1 in case of convergence layer type 2 to leave space for the control signal octet which is added in the later part of the function. This fixes 2). Add tty_port_tty_wakeup() to wake up the user tty if new write space has been made available to fix 3). Fixes: 268e526b935e ("tty/n_gsm: avoid fifo overflow in gsm_dlci_data_output") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Starke <[email protected]> Date: Thu Jul 7 13:32:20 2022 +0200 tty: n_gsm: fix wrong T1 retry count handling [ Upstream commit f30e10caa80aa1f35508bc17fc302dbbde9a833c ] n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.7.3 states that the valid range for the maximum number of retransmissions (N2) is from 0 to 255 (both including). gsm_dlci_t1() handles this number incorrectly by performing N2 - 1 retransmission attempts. Setting N2 to zero results in more than 255 retransmission attempts. Fix gsm_dlci_t1() to comply with 3GPP 27.010. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Daniel Starke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sherry Sun <[email protected]> Date: Mon Jul 25 13:01:15 2022 +0800 tty: serial: fsl_lpuart: correct the count of break characters [ Upstream commit 707f816f25590c20e056b3bd4a17ce69b03fe856 ] The LPUART can't distinguish between a break signal and a framing error, so need to count the break characters if there is a framing error and received data is zero instead of the parity error. Fixes: 5541a9bacfe5 ("serial: fsl_lpuart: handle break and make sysrq work") Reviewed-by: Michael Walle <[email protected]> Signed-off-by: Sherry Sun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tetsuo Handa <[email protected]> Date: Tue Jul 19 14:49:39 2022 +0900 tty: vt: initialize unicode screen buffer commit af77c56aa35325daa2bc2bed5c2ebf169be61b86 upstream. syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read immediately after resize operation. Initialize buffer using kzalloc(). ---------- #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/fb.h> int main(int argc, char *argv[]) { struct fb_var_screeninfo var = { }; const int fb_fd = open("/dev/fb0", 3); ioctl(fb_fd, FBIOGET_VSCREENINFO, &var); var.yres = 0x21; ioctl(fb_fd, FBIOPUT_VSCREENINFO, &var); return read(open("/dev/vcsu", O_RDONLY), &var, sizeof(var)) == -1; } ---------- Link: https://syzkaller.appspot.com/bug?extid=31a641689d43387f05d3 [1] Cc: stable <[email protected]> Reported-by: syzbot <[email protected]> Reviewed-by: Jiri Slaby <[email protected]> Signed-off-by: Tetsuo Handa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christopher Obbard <[email protected]> Date: Thu Jun 23 09:58:42 2022 +0100 um: random: Don't initialise hwrng struct with zero [ Upstream commit 9e70cbd11b03889c92462cf52edb2bd023c798fa ] Initialising the hwrng struct with zeros causes a compile-time sparse warning: $ ARCH=um make -j10 W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ... CHECK arch/um/drivers/random.c arch/um/drivers/random.c:31:31: sparse: warning: Using plain integer as NULL pointer Fix the warning by not initialising the hwrng struct with zeros as it is initialised anyway during module init. Fixes: 72d3e093afae ("um: random: Register random as hwrng-core device") Reported-by: kernel test robot <[email protected]> Signed-off-by: Christopher Obbard <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Beichler <[email protected]> Date: Tue May 31 11:17:39 2022 +0000 um: Remove straying parenthesis commit c6496e0a4a90d8149203c16323cff3fa46e422e7 upstream. Commit e3a33af812c6 ("um: fix and optimize xor select template for CONFIG64 and timetravel mode") caused a build regression when CONFIG_XOR_BLOCKS and CONFIG_UML_TIME_TRAVEL_SUPPORT are selected. Fix it by removing the straying parenthesis. Cc: [email protected] Fixes: e3a33af812c6 ("um: fix and optimize xor select template for CONFIG64 and timetravel mode") Signed-off-by: Benjamin Beichler <[email protected]> [rw: Added commit message] Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Wed Jul 13 01:12:21 2022 +0200 um: seed rng using host OS rng commit 0b9ba6135d7f18b82f3d8bebb55ded725ba88e0e upstream. UML generally does not provide access to special CPU instructions like RDRAND, and execution tends to be rather deterministic, with no real hardware interrupts, making good randomness really very hard, if not all together impossible. Not only is this a security eyebrow raiser, but it's also quite annoying when trying to do various pieces of UML-based automation that takes a long time to boot, if ever. Fix this by trivially calling getrandom() in the host and using that seed as "bootloader randomness", which initializes the rng immediately at UML boot. The old behavior can be restored the same way as on any other arch, by way of CONFIG_TRUST_BOOTLOADER_RANDOMNESS=n or random.trust_bootloader=0. So seen from that perspective, this just makes UML act like other archs, which is positive in its own right. Additionally, wire up arch_get_random_{int,long}() in the same way, so that reseeds can also make use of the host RNG, controllable by CONFIG_TRUST_CPU_RANDOMNESS and random.trust_cpu, per usual. Cc: [email protected] Acked-by: Johannes Berg <[email protected]> Acked-By: Anton Ivanov <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liang He <[email protected]> Date: Wed Jul 13 20:05:28 2022 +0800 usb: aspeed-vhub: Fix refcount leak bug in ast_vhub_init_desc() [ Upstream commit 220fafb4ed04187e9c17be4152da5a7f2ffbdd8c ] We should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. Fixes: 30d2617fd7ed ("usb: gadget: aspeed: allow to set usb strings in device tree") Signed-off-by: Liang He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrey Strachuk <[email protected]> Date: Mon Jul 18 19:00:52 2022 +0300 usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable() [ Upstream commit c3ffc9c4ca44bfe9562166793d133e1fb0630ea6 ] If 'ep' is NULL, result of ep_to_cdns3_ep(ep) is invalid pointer and its dereference with priv_ep->cdns3_dev may cause panic. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Acked-by: Peter Chen <[email protected]> Signed-off-by: Andrey Strachuk <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Wed Aug 3 09:24:22 2022 -0700 usb: cdns3: Don't use priv_dev uninitialized in cdns3_gadget_ep_enable() [ Upstream commit 78acd4ca433425e6dd4032cfc2156c60e34931f2 ] Clang warns: drivers/usb/cdns3/cdns3-gadget.c:2290:11: error: variable 'priv_dev' is uninitialized when used here [-Werror,-Wuninitialized] dev_dbg(priv_dev->dev, "usbss: invalid parameters\n"); ^~~~~~~~ include/linux/dev_printk.h:155:18: note: expanded from macro 'dev_dbg' dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~ include/linux/dynamic_debug.h:167:7: note: expanded from macro 'dynamic_dev_dbg' dev, fmt, ##__VA_ARGS__) ^~~ include/linux/dynamic_debug.h:152:56: note: expanded from macro '_dynamic_func_call' __dynamic_func_call(__UNIQUE_ID(ddebug), fmt, func, ##__VA_ARGS__) ^~~~~~~~~~~ include/linux/dynamic_debug.h:134:15: note: expanded from macro '__dynamic_func_call' func(&id, ##__VA_ARGS__); \ ^~~~~~~~~~~ drivers/usb/cdns3/cdns3-gadget.c:2278:31: note: initialize the variable 'priv_dev' to silence this warning struct cdns3_device *priv_dev; ^ = NULL 1 error generated. The priv_dev assignment was moved below the if statement to avoid potentially dereferencing ep before it was checked but priv_dev is used in the dev_dbg() call. To fix this, move the priv_dev and comp_desc assignments back to their original spot and hoist the ep check above those assignments with a call to pr_debug() instead of dev_dbg(). Fixes: c3ffc9c4ca44 ("usb: cdns3: change place of 'priv_ep' assignment in cdns3_gadget_ep_dequeue(), cdns3_gadget_ep_enable()") Link: https://github.com/ClangBuiltLinux/linux/issues/1680 Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thinh Nguyen <[email protected]> Date: Wed Jun 15 17:24:32 2022 -0700 usb: dwc3: core: Deprecate GCTL.CORESOFTRESET [ Upstream commit afbd04e66e5d16ca3c7ea2e3c56eca25558eacf3 ] Synopsys IP DWC_usb32 and DWC_usb31 version 1.90a and above deprecated GCTL.CORESOFTRESET. The DRD mode switching flow is updated to remove the GCTL soft reset. Add version checks to prevent using deprecated setting in mode switching flow. Signed-off-by: Thinh Nguyen <[email protected]> Link: https://lore.kernel.org/r/9df529fde6e55f5508321b6bc26e92848044ef2b.1655338967.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rohith Kollalsi <[email protected]> Date: Thu Jul 14 10:26:25 2022 +0530 usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during bootup [ Upstream commit 07903626d98853e605fe63e5ce149f1b7314bbea ] According to the programming guide, it is recommended to perform a GCTL_CORE_SOFTRESET only when switching the mode from device to host or host to device. However, it is found that during bootup when __dwc3_set_mode() is called for the first time, GCTL_CORESOFTRESET is done with suspendable bit(BIT 17) of DWC3_GUSB3PIPECTL set. This some times leads to issues like controller going into bad state and controller registers reading value zero. Until GCTL_CORESOFTRESET is done and run/stop bit is set core initialization is not complete. Setting suspendable bit of DWC3_GUSB3PIPECTL and then performing GCTL_CORESOFTRESET is therefore not recommended. Avoid this by only performing the reset if current_dr_role is set, that is, when doing subsequent role switching. Fixes: f88359e1588b ("usb: dwc3: core: Do core softreset when switch mode") Signed-off-by: Rohith Kollalsi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Grzeschik <[email protected]> Date: Mon Jul 4 16:18:12 2022 +0200 usb: dwc3: gadget: fix high speed multiplier setting commit 8affe37c525d800a2628c4ecfaed13b77dc5634a upstream. For High-Speed Transfers the prepare_one_trb function is calculating the multiplier setting for the trb based on the length parameter of the trb currently prepared. This assumption is wrong. For trbs with a sg list, the length of the actual request has to be taken instead. Fixes: 40d829fb2ec6 ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets") Cc: stable <[email protected]> Signed-off-by: Michael Grzeschik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Michael Grzeschik <[email protected]> Date: Mon Jul 4 16:18:11 2022 +0200 usb: dwc3: gadget: refactor dwc3_repare_one_trb commit 23385cec5f354794dadced7f28c31da7ae3eb54c upstream. The function __dwc3_prepare_one_trb has many parameters. Since it is only used in dwc3_prepare_one_trb there is no point in keeping the function. We merge both functions and get rid of the big list of parameters. Fixes: 40d829fb2ec6 ("usb: dwc3: gadget: Correct ISOC DATA PIDs for short packets") Cc: stable <[email protected]> Signed-off-by: Michael Grzeschik <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Wed Jul 13 15:13:36 2022 +0200 usb: dwc3: qcom: fix missing optional irq warnings [ Upstream commit 69bb3520db7cecbccc9e497fc568fa5465c9d43f ] Not all platforms have all of the four currently supported wakeup interrupts so use the optional irq helpers when looking up interrupts to avoid printing error messages when an optional interrupt is not found: dwc3-qcom a6f8800.usb: error -ENXIO: IRQ hs_phy_irq not found Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Reviewed-by: Andrew Halaney <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tang Bin <[email protected]> Date: Wed May 25 21:53:32 2022 +0800 usb: gadget: tegra-xudc: Fix error check in tegra_xudc_powerdomain_init() [ Upstream commit f08aa7c80dac27ee00fa6827f447597d2fba5465 ] dev_pm_domain_attach_by_name() may return NULL in some cases, so IS_ERR() doesn't meet the requirements. Thus fix it. Fixes: 49db427232fe ("usb: gadget: Add UDC driver for tegra XUSB device mode controller") Signed-off-by: Tang Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Fri Jul 8 18:36:01 2022 -0700 usb: gadget: udc: amd5536 depends on HAS_DMA [ Upstream commit 8097cf2fb3b2205257f1c76f4808e3398d66b6d9 ] USB_AMD5536UDC should depend on HAS_DMA since it selects USB_SNP_CORE, which depends on HAS_DMA and since 'select' does not follow any dependency chains. Fixes this kconfig warning: WARNING: unmet direct dependencies detected for USB_SNP_CORE Depends on [n]: USB_SUPPORT [=y] && USB_GADGET [=y] && (USB_AMD5536UDC [=y] || USB_SNP_UDC_PLAT [=n]) && HAS_DMA [=n] Selected by [y]: - USB_AMD5536UDC [=y] && USB_SUPPORT [=y] && USB_GADGET [=y] && USB_PCI [=y] Fixes: 97b3ffa233b9 ("usb: gadget: udc: amd5536: split core and PCI layer") Cc: Raviteja Garimella <[email protected]> Cc: Felipe Balbi <[email protected]> Cc: [email protected] Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Weitao Wang <[email protected]> Date: Tue Jul 26 15:49:18 2022 +0800 USB: HCD: Fix URB giveback issue in tasklet function commit 26c6c2f8a907c9e3a2f24990552a4d77235791e6 upstream. Usb core introduce the mechanism of giveback of URB in tasklet context to reduce hardware interrupt handling time. On some test situation(such as FIO with 4KB block size), when tasklet callback function called to giveback URB, interrupt handler add URB node to the bh->head list also. If check bh->head list again after finish all URB giveback of local_list, then it may introduce a "dynamic balance" between giveback URB and add URB to bh->head list. This tasklet callback function may not exit for a long time, which will cause other tasklet function calls to be delayed. Some real-time applications(such as KB and Mouse) will see noticeable lag. In order to prevent the tasklet function from occupying the cpu for a long time at a time, new URBS will not be added to the local_list even though the bh->head list is not empty. But also need to ensure the left URB giveback to be processed in time, so add a member high_prio for structure giveback_urb_bh to prioritize tasklet and schelule this tasklet again if bh->head list is not empty. At the same time, we are able to prioritize tasklet through structure member high_prio. So, replace the local high_prio_bh variable with this structure member in usb_hcd_giveback_urb. Fixes: 94dfd7edfd5c ("USB: HCD: support giveback of URB in tasklet context") Cc: stable <[email protected]> Reviewed-by: Alan Stern <[email protected]> Signed-off-by: Weitao Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Thu Jun 2 15:08:49 2022 +0400 usb: host: Fix refcount leak in ehci_hcd_ppc_of_probe [ Upstream commit b5c5b13cb45e2c88181308186b0001992cb41954 ] of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: 796bcae7361c ("USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]") Acked-by: Alan Stern <[email protected]> Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sergey Shtylyov <[email protected]> Date: Thu Jun 30 15:46:45 2022 +0300 usb: host: xhci: use snprintf() in xhci_decode_trb() [ Upstream commit 1ce69c35b86038dd11d3a6115a04501c5b89a940 ] Commit cbf286e8ef83 ("xhci: fix unsafe memory usage in xhci tracing") apparently missed one sprintf() call in xhci_decode_trb() -- replace it with the snprintf() call as well... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: cbf286e8ef83 ("xhci: fix unsafe memory usage in xhci tracing") Signed-off-by: Sergey Shtylyov <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Miaoqian Lin <[email protected]> Date: Fri Jun 3 18:12:30 2022 +0400 usb: ohci-nxp: Fix refcount leak in ohci_hcd_nxp_probe [ Upstream commit 302970b4cad3ebfda2c05ce06c322ccdc447d17e ] of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 73108aa90cbf ("USB: ohci-nxp: Use isp1301 driver") Acked-by: Alan Stern <[email protected]> Signed-off-by: Miaoqian Lin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Mon Jul 25 10:44:57 2022 +0200 USB: serial: fix tty-port initialized comments [ Upstream commit 688ee1d1785c1359f9040f615dd8e6054962bce2 ] Fix up the tty-port initialized comments which got truncated and obfuscated when replacing the old ASYNCB_INITIALIZED flag. Fixes: d41861ca19c9 ("tty: Replace ASYNC_INITIALIZED bit and update atomically") Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Linyu Yuan <[email protected]> Date: Tue Jul 26 14:45:49 2022 +0800 usb: typec: ucsi: Acknowledge the GET_ERROR_STATUS command completion commit a7dc438b5e446afcd1b3b6651da28271400722f2 upstream. We found PPM will not send any notification after it report error status and OPM issue GET_ERROR_STATUS command to read the details about error. According UCSI spec, PPM may clear the Error Status Data after the OPM has acknowledged the command completion. This change add operation to acknowledge the command completion from PPM. Fixes: bdc62f2bae8f (usb: typec: ucsi: Simplified registration and I/O API) Cc: <[email protected]> # 5.10 Signed-off-by: Jack Pham <[email protected]> Signed-off-by: Linyu Yuan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tang Bin <[email protected]> Date: Tue May 24 20:14:04 2022 +0800 usb: xhci: tegra: Fix error check [ Upstream commit 18fc7c435be3f17ea26a21b2e2312fcb9088e01f ] In the function tegra_xusb_powerdomain_init(), dev_pm_domain_attach_by_name() may return NULL in some cases, so IS_ERR() doesn't meet the requirements. Thus fix it. Fixes: 6494a9ad86de ("usb: xhci: tegra: Add genpd support") Signed-off-by: Tang Bin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Thu Jun 23 14:50:59 2022 +0200 usbnet: Fix linkwatch use-after-free on disconnect commit a69e617e533edddf3fa3123149900f36e0a6dc74 upstream. usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last. Reported-by: Jann Horn <[email protected]> Link: https://lore.kernel.org/netdev/CAG48ez0MHBbENX5gCdHAUXZ7h7s20LnepBF-pa5M=7Bi-jZrEA@mail.gmail.com/ Reported-by: Oleksij Rempel <[email protected]> Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Lukas Wunner <[email protected]> Cc: [email protected] Acked-by: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/d1c87ebe9fc502bffcd1576e238d685ad08321e4.1655987888.git.lukas@wunner.de Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Thu May 12 10:42:04 2022 +0200 usbnet: smsc95xx: Avoid link settings race on interrupt reception [ Upstream commit 8960f878e39fadc03d74292a6731f1e914cf2019 ] When a PHY interrupt is signaled, the SMSC LAN95xx driver updates the MAC full duplex mode and PHY flow control registers based on cached data in struct phy_device: smsc95xx_status() # raises EVENT_LINK_RESET usbnet_deferred_kevent() smsc95xx_link_reset() # uses cached data in phydev Simultaneously, phylib polls link status once per second and updates that cached data: phy_state_machine() phy_check_link_status() phy_read_status() lan87xx_read_status() genphy_read_status() # updates cached data in phydev If smsc95xx_link_reset() wins the race against genphy_read_status(), the registers may be updated based on stale data. E.g. if the link was previously down, phydev->duplex is set to DUPLEX_UNKNOWN and that's what smsc95xx_link_reset() will use, even though genphy_read_status() may update it to DUPLEX_FULL afterwards. PHY interrupts are currently only enabled on suspend to trigger wakeup, so the impact of the race is limited, but we're about to enable them perpetually. Avoid the race by delaying execution of smsc95xx_link_reset() until phy_state_machine() has done its job and calls back via smsc95xx_handle_link_change(). Signaling EVENT_LINK_RESET on wakeup is not necessary because phylib picks up link status changes through polling. So drop the declaration of a ->link_reset() callback. Note that the semicolon on a line by itself added in smsc95xx_status() is a placeholder for a function call which will be added in a subsequent commit. That function call will actually handle the INT_ENP_PHY_INT_ interrupt. Tested-by: Oleksij Rempel <[email protected]> # LAN9514/9512/9500 Tested-by: Ferry Toth <[email protected]> # LAN9514 Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Thu May 12 10:42:02 2022 +0200 usbnet: smsc95xx: Don't clear read-only PHY interrupt [ Upstream commit 3108871f19221372b251f7da1ac38736928b5b3a ] Upon receiving data from the Interrupt Endpoint, the SMSC LAN95xx driver attempts to clear the signaled interrupts by writing "all ones" to the Interrupt Status Register. However the driver only ever enables a single type of interrupt, namely the PHY Interrupt. And according to page 119 of the LAN950x datasheet, its bit in the Interrupt Status Register is read-only. There's no other way to clear it than in a separate PHY register: https://www.microchip.com/content/dam/mchp/documents/UNG/ProductDocuments/DataSheets/LAN950x-Data-Sheet-DS00001875D.pdf Consequently, writing "all ones" to the Interrupt Status Register is pointless and can be dropped. Tested-by: Oleksij Rempel <[email protected]> # LAN9514/9512/9500 Tested-by: Ferry Toth <[email protected]> # LAN9514 Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Fri Jul 1 22:47:51 2022 +0200 usbnet: smsc95xx: Fix deadlock on runtime resume [ Upstream commit 7b960c967f2aa01ab8f45c5a0bd78e754cffdeee ] Commit 05b35e7eb9a1 ("smsc95xx: add phylib support") amended smsc95xx_resume() to call phy_init_hw(). That function waits for the device to runtime resume even though it is placed in the runtime resume path, causing a deadlock. The problem is that phy_init_hw() calls down to smsc95xx_mdiobus_read(), which never uses the _nopm variant of usbnet_read_cmd(). Commit b4df480f68ae ("usbnet: smsc95xx: add reset_resume function with reset operation") causes a similar deadlock on resume if the device was already runtime suspended when entering system sleep: That's because the commit introduced smsc95xx_reset_resume(), which calls down to smsc95xx_reset(), which neglects to use _nopm accessors. Fix by auto-detecting whether a device access is performed by the suspend/resume task_struct and use the _nopm variant if so. This works because the PM core guarantees that suspend/resume callbacks are run in task context. Stacktrace for posterity: INFO: task kworker/2:1:49 blocked for more than 122 seconds. Workqueue: usb_hub_wq hub_event schedule rpm_resume __pm_runtime_resume usb_autopm_get_interface usbnet_read_cmd __smsc95xx_read_reg __smsc95xx_phy_wait_not_busy __smsc95xx_mdio_read smsc95xx_mdiobus_read __mdiobus_read mdiobus_read smsc_phy_reset phy_init_hw smsc95xx_resume usb_resume_interface usb_resume_both usb_runtime_resume __rpm_callback rpm_callback rpm_resume __pm_runtime_resume usb_autoresume_device hub_event process_one_work Fixes: b4df480f68ae ("usbnet: smsc95xx: add reset_resume function with reset operation") Signed-off-by: Lukas Wunner <[email protected]> Cc: [email protected] # v3.16+ Cc: Andre Edich <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lukas Wunner <[email protected]> Date: Thu May 12 10:42:05 2022 +0200 usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling [ Upstream commit 1ce8b37241ed291af56f7a49bbdbf20c08728e88 ] Link status of SMSC LAN95xx chips is polled once per second, even though they're capable of signaling PHY interrupts through the MAC layer. Forward those interrupts to the PHY driver to avoid polling. Benefits are reduced bus traffic, reduced CPU overhead and quicker interface bringup. Polling was introduced in 2016 by commit d69d16949346 ("usbnet: smsc95xx: fix link detection for disabled autonegotiation"). Back then, the LAN95xx driver neglected to enable the ENERGYON interrupt, hence couldn't detect link-up events when auto-negotiation was disabled. The proper solution would have been to enable the ENERGYON interrupt instead of polling. Since then, PHY handling was moved from the LAN95xx driver to the SMSC PHY driver with commit 05b35e7eb9a1 ("smsc95xx: add phylib support"). That PHY driver is capable of link detection with auto-negotiation disabled because it enables the ENERGYON interrupt. Note that signaling interrupts through the MAC layer not only works with the integrated PHY, but also with an external PHY, provided its interrupt pin is attached to LAN95xx's nPHY_INT pin. In the unlikely event that the interrupt pin of an external PHY is attached to a GPIO of the SoC (or not connected at all), the driver can be amended to retrieve the irq from the PHY's of_node. To forward PHY interrupts to phylib, it is not sufficient to call phy_mac_interrupt(). Instead, the PHY's interrupt handler needs to run so that PHY interrupts are cleared. That's because according to page 119 of the LAN950x datasheet, "The source of this interrupt is a level. The interrupt persists until it is cleared in the PHY." https://www.microchip.com/content/dam/mchp/documents/UNG/ProductDocuments/DataSheets/LAN950x-Data-Sheet-DS00001875D.pdf Therefore, create an IRQ domain with a single IRQ for the PHY. In the future, the IRQ domain may be extended to support the 11 GPIOs on the LAN95xx. Normally the PHY interrupt should be masked until the PHY driver has cleared it. However masking requires a (sleeping) USB transaction and interrupts are received in (non-sleepable) softirq context. I decided not to mask the interrupt at all (by using the dummy_irq_chip's noop ->irq_mask() callback): The USB interrupt endpoint is polled in 1 msec intervals and normally that's sufficient to wake the PHY driver's IRQ thread and have it clear the interrupt. If it does take longer, worst thing that can happen is the IRQ thread is woken again. No big deal. Because PHY interrupts are now perpetually enabled, there's no need to selectively enable them on suspend. So remove all invocations of smsc95xx_enable_phy_wakeup_interrupts(). In smsc95xx_resume(), move the call of phy_init_hw() before usbnet_resume() (which restarts the status URB) to ensure that the PHY is fully initialized when an interrupt is handled. Tested-by: Oleksij Rempel <[email protected]> # LAN9514/9512/9500 Tested-by: Ferry Toth <[email protected]> # LAN9514 Signed-off-by: Lukas Wunner <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> # from a PHY perspective Cc: Andre Edich <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Farman <[email protected]> Date: Thu Jul 7 15:57:29 2022 +0200 vfio/ccw: Do not change FSM state in subchannel event [ Upstream commit cffcc109fd682075dee79bade3d60a07152a8fd1 ] The routine vfio_ccw_sch_event() is tasked with handling subchannel events, specifically machine checks, on behalf of vfio-ccw. It correctly calls cio_update_schib(), and if that fails (meaning the subchannel is gone) it makes an FSM event call to mark the subchannel Not Operational. If that worked, however, then it decides that if the FSM state was already Not Operational (implying the subchannel just came back), then it should simply change the FSM to partially- or fully-open. Remove this trickery, since a subchannel returning will require more probing than simply "oh all is well again" to ensure it works correctly. Fixes: bbe37e4cb8970 ("vfio: ccw: introduce a finite state machine") Signed-off-by: Eric Farman <[email protected]> Reviewed-by: Matthew Rosato <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Howells <[email protected]> Date: Mon Aug 8 09:52:35 2022 +0100 vfs: Check the truncate maximum size in inode_newsize_ok() commit e2ebff9c57fe4eb104ce4768f6ebcccf76bef849 upstream. If something manages to set the maximum file size to MAX_OFFSET+1, this can cause the xfs and ext4 filesystems at least to become corrupt. Ordinarily, the kernel protects against userspace trying this by checking the value early in the truncate() and ftruncate() system calls calls - but there are at least two places that this check is bypassed: (1) Cachefiles will round up the EOF of the backing file to DIO block size so as to allow DIO on the final block - but this might push the offset negative. It then calls notify_change(), but this inadvertently bypasses the checking. This can be triggered if someone puts an 8EiB-1 file on a server for someone else to try and access by, say, nfs. (2) ksmbd doesn't check the value it is given in set_end_of_file_info() and then calls vfs_truncate() directly - which also bypasses the check. In both cases, it is potentially possible for a network filesystem to cause a disk filesystem to be corrupted: cachefiles in the client's cache filesystem; ksmbd in the server's filesystem. nfsd is okay as it checks the value, but we can then remove this check too. Fix this by adding a check to inode_newsize_ok(), as called from setattr_prepare(), thereby catching the issue as filesystems set up to perform the truncate with minimal opportunity for bypassing the new check. Fixes: 1f08c925e7a3 ("cachefiles: Implement backing file wrangling") Fixes: f44158485826 ("cifsd: add file operations") Signed-off-by: David Howells <[email protected]> Reported-by: Jeff Layton <[email protected]> Tested-by: Jeff Layton <[email protected]> Reviewed-by: Namjae Jeon <[email protected]> Cc: [email protected] Acked-by: Alexander Viro <[email protected]> cc: Steve French <[email protected]> cc: Hyunchul Lee <[email protected]> cc: Chuck Lever <[email protected]> cc: Dave Wysochanski <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liang He <[email protected]> Date: Tue Jul 19 16:25:46 2022 +0800 video: fbdev: amba-clcd: Fix refcount leak bugs [ Upstream commit 26c2b7d9fac42eb8317f3ceefa4c1a9a9170ca69 ] In clcdfb_of_init_display(), we should call of_node_put() for the references returned by of_graph_get_next_endpoint() and of_graph_get_remote_port_parent() which have increased the refcount. Besides, we should call of_node_put() both in fail path or when the references are not used anymore. Fixes: d10715be03bd ("video: ARM CLCD: Add DT support") Signed-off-by: Liang He <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Thu Aug 4 20:41:24 2022 +0800 video: fbdev: arkfb: Check the size of screen before memset_io() [ Upstream commit 96b550971c65d54d64728d8ba973487878a06454 ] In the function arkfb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000 [ 659.399077] #PF: supervisor write access in kernel mode [ 659.399079] #PF: error_code(0x0002) - not-present page [ 659.399094] RIP: 0010:memset_orig+0x33/0xb0 [ 659.399116] Call Trace: [ 659.399122] arkfb_set_par+0x143f/0x24c0 [ 659.399130] fb_set_var+0x604/0xeb0 [ 659.399161] do_fb_ioctl+0x234/0x670 [ 659.399189] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io(). Fixes: 681e14730c73 ("arkfb: new framebuffer driver for ARK Logic cards") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Wed Aug 3 17:23:12 2022 +0800 video: fbdev: arkfb: Fix a divide-by-zero bug in ark_set_pixclock() [ Upstream commit 2f1c4523f7a3aaabe7e53d3ebd378292947e95c8 ] Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug in: drivers/video/fbdev/arkfb.c:784: ark_set_pixclock(info, (hdiv * info->var.pixclock) / hmul); with hdiv=1, pixclock=1 and hmul=2 you end up with (1*1)/2 = (int) 0. and then in: drivers/video/fbdev/arkfb.c:504: rv = dac_set_freq(par->dac, 0, 1000000000 / pixclock); we'll get a division-by-zero. The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:ark_set_pixclock drivers/video/fbdev/arkfb.c:504 [inline] RIP: 0010:arkfb_set_par+0x10fc/0x24c0 drivers/video/fbdev/arkfb.c:784 Call Trace: fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Fix this by checking the argument of ark_set_pixclock() first. Fixes: 681e14730c73 ("arkfb: new framebuffer driver for ARK Logic cards") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Thu Aug 4 20:41:25 2022 +0800 video: fbdev: s3fb: Check the size of screen before memset_io() [ Upstream commit 6ba592fa014f21f35a8ee8da4ca7b95a018f13e8 ] In the function s3fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 54.083733] BUG: unable to handle page fault for address: ffffc90003000000 [ 54.083742] #PF: supervisor write access in kernel mode [ 54.083744] #PF: error_code(0x0002) - not-present page [ 54.083760] RIP: 0010:memset_orig+0x33/0xb0 [ 54.083782] Call Trace: [ 54.083788] s3fb_set_par+0x1ec6/0x4040 [ 54.083806] fb_set_var+0x604/0xeb0 [ 54.083836] do_fb_ioctl+0x234/0x670 Fix the this by checking the value of 'screen_size' before memset_io(). Fixes: a268422de8bf ("fbdev driver for S3 Trio/Virge") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rustam Subkhankulov <[email protected]> Date: Mon Jul 18 15:43:43 2022 +0300 video: fbdev: sis: fix typos in SiS_GetModeID() [ Upstream commit 3eb8fccc244bfb41a7961969e4db280d44911226 ] The second operand of a '&&' operator has no impact on expression result for cases 400 and 512 in SiS_GetModeID(). Judging by the logic and the names of the variables, in both cases a typo was made. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rustam Subkhankulov <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheyu Ma <[email protected]> Date: Thu Aug 4 20:41:23 2022 +0800 video: fbdev: vt8623fb: Check the size of screen before memset_io() [ Upstream commit ec0754c60217248fa77cc9005d66b2b55200ac06 ] In the function vt8623fb_set_par(), the value of 'screen_size' is calculated by the user input. If the user provides the improper value, the value of 'screen_size' may larger than 'info->screen_size', which may cause the following bug: [ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000 [ 583.339049] #PF: supervisor write access in kernel mode [ 583.339052] #PF: error_code(0x0002) - not-present page [ 583.339074] RIP: 0010:memset_orig+0x33/0xb0 [ 583.339110] Call Trace: [ 583.339118] vt8623fb_set_par+0x11cd/0x21e0 [ 583.339146] fb_set_var+0x604/0xeb0 [ 583.339181] do_fb_ioctl+0x234/0x670 [ 583.339209] fb_ioctl+0xdd/0x130 Fix the this by checking the value of 'screen_size' before memset_io(). Fixes: 558b7bd86c32 ("vt8623fb: new framebuffer driver for VIA VT8623") Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Helge Deller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xiaomeng Tong <[email protected]> Date: Sun Mar 27 13:09:45 2022 +0800 virtio-gpu: fix a missing check to avoid NULL dereference [ Upstream commit bd63f11f4c3c46afec07d821f74736161ff6e526 ] 'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. Fixes: 62fb7a5e10962 ("virtio-gpu: add 3d/virgl support") Signed-off-by: Xiaomeng Tong <[email protected]> Reviewed-by: Chia-I Wu <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] [ kraxel: minor codestyle fixup ] Signed-off-by: Gerd Hoffmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Juri Lelli <[email protected]> Date: Mon Jun 27 11:50:51 2022 +0200 wait: Fix __wait_event_hrtimeout for RT/DL tasks [ Upstream commit cceeeb6a6d02e7b9a74ddd27a3225013b34174aa ] Changes to hrtimer mode (potentially made by __hrtimer_init_sleeper on PREEMPT_RT) are not visible to hrtimer_start_range_ns, thus not accounted for by hrtimer_start_expires call paths. In particular, __wait_event_hrtimeout suffers from this problem as we have, for example: fs/aio.c::read_events wait_event_interruptible_hrtimeout __wait_event_hrtimeout hrtimer_init_sleeper_on_stack <- this might "mode |= HRTIMER_MODE_HARD" on RT if task runs at RT/DL priority hrtimer_start_range_ns WARN_ON_ONCE(!(mode & HRTIMER_MODE_HARD) ^ !timer->is_hard) fires since the latter doesn't see the change of mode done by init_sleeper Fix it by making __wait_event_hrtimeout call hrtimer_sleeper_start_expires, which is aware of the special RT/DL case, instead of hrtimer_start_range_ns. Reported-by: Bruno Goncalves <[email protected]> Signed-off-by: Juri Lelli <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Daniel Bristot de Oliveira <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: William Dean <[email protected]> Date: Fri Jul 22 11:09:38 2022 +0800 watchdog: armada_37xx_wdt: check the return value of devm_ioremap() in armada_37xx_wdt_probe() [ Upstream commit 2d27e52841092e5831dd41f313028c668d816eb0 ] The function devm_ioremap() in armada_37xx_wdt_probe() can fail, so its return value should be checked. Fixes: 54e3d9b518c8a ("watchdog: Add support for Armada 37xx CPU watchdog") Reported-by: Hacash Robot <[email protected]> Signed-off-by: William Dean <[email protected]> Reviewed-by: Marek Beh=C3=BAn <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jean Delvare <[email protected]> Date: Tue Jun 21 15:28:40 2022 +0200 watchdog: sp5100_tco: Fix a memory leak of EFCH MMIO resource [ Upstream commit c6d9c0798ed366a09a9e53d71edcd2266e34a6eb ] Unlike release_mem_region(), a call to release_resource() does not free the resource, so it has to be freed explicitly to avoid a memory leak. Signed-off-by: Jean Delvare <[email protected]> Fixes: 0578fff4aae5 ("Watchdog: sp5100_tco: Add initialization using EFCH MMIO") Cc: Terry Bowman <[email protected]> Cc: Wim Van Sebroeck <[email protected]> Cc: Guenter Roeck <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexey Kodanev <[email protected]> Date: Wed Jun 8 20:16:14 2022 +0300 wifi: iwlegacy: 4965: fix potential off-by-one overflow in il4965_rs_fill_link_cmd() [ Upstream commit a8eb8e6f7159c7c20c0ddac428bde3d110890aa7 ] As a result of the execution of the inner while loop, the value of 'idx' can be equal to LINK_QUAL_MAX_RETRY_NUM. However, this is not checked after the loop and 'idx' is used to write the LINK_QUAL_MAX_RETRY_NUM size array 'lq_cmd->rs_table[idx]' below in the outer loop. The fix is to check the new value of 'idx' inside the nested loop, and break both loops if index equals the size. Checking it at the start is now pointless, so let's remove it. Detected using the static analysis tool - Svace. Fixes: be663ab67077 ("iwlwifi: split the drivers for agn and legacy devices 3945/4965") Signed-off-by: Alexey Kodanev <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jose Ignacio Tornos Martinez <[email protected]> Date: Tue Jul 19 17:35:42 2022 +0200 wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queue [ Upstream commit 14a3aacf517a9de725dd3219dbbcf741e31763c4 ] After successfull station association, if station queues are disabled for some reason, the related lists are not emptied. So if some new element is added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old one and produce a BUG like this: [ 46.535263] list_add corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388). [ 46.535283] ------------[ cut here ]------------ [ 46.535284] kernel BUG at lib/list_debug.c:26! [ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1 [ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012 [ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f [ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1 [ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286 [ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000 [ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff [ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666 [ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388 [ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0 [ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000 [ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0 [ 46.687422] Call Trace: [ 46.689906] <TASK> [ 46.691950] iwl_mvm_mac_wake_tx_queue+0xec/0x15c [iwlmvm] [ 46.697601] ieee80211_queue_skb+0x4b3/0x720 [mac80211] [ 46.702973] ? sta_info_get+0x46/0x60 [mac80211] [ 46.707703] ieee80211_tx+0xad/0x110 [mac80211] [ 46.712355] __ieee80211_tx_skb_tid_band+0x71/0x90 [mac80211] ... In order to avoid this problem, we must also remove the related lists when station queues are disabled. Fixes: cfbc6c4c5b91c ("iwlwifi: mvm: support mac80211 TXQs model") Reported-by: Takayuki Nagata <[email protected]> Reported-by: Petr Stourac <[email protected]> Tested-by: Petr Stourac <[email protected]> Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hangyu Hua <[email protected]> Date: Mon Jun 20 17:23:50 2022 +0800 wifi: libertas: Fix possible refcount leak in if_usb_probe() [ Upstream commit 6fd57e1d120bf13d4dc6c200a7cf914e6347a316 ] usb_get_dev will be called before lbs_get_firmware_async which means that usb_put_dev need to be called when lbs_get_firmware_async fails. Fixes: ce84bb69f50e ("libertas USB: convert to asynchronous firmware loading") Signed-off-by: Hangyu Hua <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Johannes Berg <[email protected]> Date: Mon Jul 11 13:14:24 2022 +0200 wifi: mac80211_hwsim: add back erroneously removed cast commit 58b6259d820d63c2adf1c7541b54cce5a2ae6073 upstream. The robots report that we're now casting to a differently sized integer, which is correct, and the previous patch had erroneously removed it. Reported-by: kernel test robot <[email protected]> Fixes: 4ee186fa7e40 ("wifi: mac80211_hwsim: fix race condition in pending packet") Signed-off-by: Johannes Berg <[email protected]> Cc: Jeongik Cha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jeongik Cha <[email protected]> Date: Mon Jul 4 17:43:54 2022 +0900 wifi: mac80211_hwsim: fix race condition in pending packet commit 4ee186fa7e40ae06ebbfbad77e249e3746e14114 upstream. A pending packet uses a cookie as an unique key, but it can be duplicated because it didn't use atomic operators. And also, a pending packet can be null in hwsim_tx_info_frame_received_nl due to race condition with mac80211_hwsim_stop. For this, * Use an atomic type and operator for a cookie * Add a lock around the loop for pending packets Signed-off-by: Jeongik Cha <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johannes Berg <[email protected]> Date: Wed Jul 13 21:16:45 2022 +0200 wifi: mac80211_hwsim: use 32-bit skb cookie commit cc5250cdb43d444061412df7fae72d2b4acbdf97 upstream. We won't really have enough skbs to need a 64-bit cookie, and on 32-bit platforms storing the 64-bit cookie into the void *rate_driver_data doesn't work anyway. Switch back to using just a 32-bit cookie and uintptr_t for the type to avoid compiler warnings about all this. Fixes: 4ee186fa7e40 ("wifi: mac80211_hwsim: fix race condition in pending packet") Signed-off-by: Johannes Berg <[email protected]> Cc: Jeongik Cha <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rustam Subkhankulov <[email protected]> Date: Thu Jul 14 16:48:31 2022 +0300 wifi: p54: add missing parentheses in p54_flush() [ Upstream commit bcfd9d7f6840b06d5988c7141127795cf405805e ] The assignment of the value to the variable total in the loop condition must be enclosed in additional parentheses, since otherwise, in accordance with the precedence of the operators, the conjunction will be performed first, and only then the assignment. Due to this error, a warning later in the function after the loop may not occur in the situation when it should. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rustam Subkhankulov <[email protected]> Fixes: 0d4171e2153b ("p54: implement flush callback") Acked-by: Christian Lamparter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Sun Jun 12 23:12:20 2022 +0200 wifi: p54: Fix an error handling path in p54spi_probe() [ Upstream commit 83781f0162d080fec7dcb911afd1bc2f5ad04471 ] If an error occurs after a successful call to p54spi_request_firmware(), it must be undone by a corresponding release_firmware() as already done in the error handling path of p54spi_request_firmware() and in the .remove() function. Add the missing call in the error handling path and remove it from p54spi_request_firmware() now that it is the responsibility of the caller to release the firmware Fixes: cd8d3d321285 ("p54spi: p54spi driver") Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Christian Lamparter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/297d2547ff2ee627731662abceeab9dbdaf23231.1655068321.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue May 17 14:48:44 2022 +0300 wifi: rtlwifi: fix error codes in rtl_debugfs_set_write_h2c() [ Upstream commit b88d28146c30a8e14f0f012d56ebf19b68a348f4 ] If the copy_from_user() fails or the user gives invalid date then the correct thing to do is to return a negative error code. (Currently it returns success). I made a copy additional related cleanups: 1) There is no need to check "buffer" for NULL. That's handled by copy_from_user(). 2) The "h2c_len" variable cannot be negative because it is unsigned and because sscanf() does not return negative error codes. Fixes: 610247f46feb ("rtlwifi: Improve debugging by using debugfs") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/YoOLnDkHgVltyXK7@kili Signed-off-by: Sasha Levin <[email protected]>
Author: William Dean <[email protected]> Date: Sat Jul 23 14:37:56 2022 +0800 wifi: rtw88: check the return value of alloc_workqueue() [ Upstream commit 42bbf810e155efc6129a3a648ae5300f00b79d7b ] The function alloc_workqueue() in rtw_core_init() can fail, but there is no check of its return value. To fix this bug, its return value should be checked with new error handling code. Fixes: fe101716c7c9d ("rtw88: replace tx tasklet with work queue") Reported-by: Hacash Robot <[email protected]> Signed-off-by: William Dean <[email protected]> Reviewed-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jul 15 13:35:18 2022 +0300 wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi() [ Upstream commit 7a4836560a6198d245d5732e26f94898b12eb760 ] The simple_write_to_buffer() function will succeed if even a single byte is initialized. However, we need to initialize the whole buffer to prevent information leaks. Just use memdup_user(). Fixes: ff974e408334 ("wil6210: debugfs interface to send raw WMI command") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/Ysg14NdKAZF/hcNG@kili Signed-off-by: Sasha Levin <[email protected]>
Author: Ammar Faizi <[email protected]> Date: Mon Jul 25 20:49:11 2022 +0300 wifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()` [ Upstream commit d578e0af3a003736f6c440188b156483d451b329 ] Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user() but it forgets to change the value to be returned that came from simple_write_to_buffer() call. It results in the following warning: warning: variable 'rc' is uninitialized when used here [-Wuninitialized] return rc; ^~ Remove rc variable and just return the passed in length if the memdup_user() succeeds. Cc: Dan Carpenter <[email protected]> Reported-by: kernel test robot <[email protected]> Fixes: 7a4836560a6198d245d5732e26f94898b12eb760 ("wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi()") Fixes: ff974e4083341383d3dd4079e52ed30f57f376f0 ("wil6210: debugfs interface to send raw WMI command") Signed-off-by: Ammar Faizi <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Tue Aug 2 14:56:12 2022 +0200 wireguard: allowedips: don't corrupt stack when detecting overflow [ Upstream commit c31b14d86dfe7174361e8c6e5df6c2c3a4d5918c ] In case push_rcu() and related functions are buggy, there's a WARN_ON(len >= 128), which the selftest tries to hit by being tricky. In case it is hit, we shouldn't corrupt the kernel's stack, though; otherwise it may be hard to even receive the report that it's buggy. So conditionalize the stack write based on that WARN_ON()'s return value. Note that this never *actually* happens anyway. The WARN_ON() in the first place is bounded by IS_ENABLED(DEBUG), and isn't expected to ever actually hit. This is just a debugging sanity check. Additionally, hoist the constant 128 into a named enum, MAX_ALLOWEDIPS_BITS, so that it's clear why this value is chosen. Suggested-by: Linus Torvalds <[email protected]> Link: https://lore.kernel.org/all/CAHk-=wjJZGA6w_DxA+k7Ejbqsq+uGK==koPai3sqdsfJqemvag@mail.gmail.com/ Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason A. Donenfeld <[email protected]> Date: Tue Aug 2 14:56:10 2022 +0200 wireguard: ratelimiter: use hrtimer in selftest [ Upstream commit 151c8e499f4705010780189377f85b57400ccbf5 ] Using msleep() is problematic because it's compared against ratelimiter.c's ktime_get_coarse_boottime_ns(), which means on systems with slow jiffies (such as UML's forced HZ=100), the result is inaccurate. So switch to using schedule_hrtimeout(). However, hrtimer gives us access only to the traditional posix timers, and none of the _COARSE variants. So now, rather than being too imprecise like jiffies, it's too precise. One solution would be to give it a large "range" value, but this will still fire early on a loaded system. A better solution is to align the timeout to the actual coarse timer, and then round up to the nearest tick, plus change. So add the timeout to the current coarse time, and then schedule_hrtimer() until the absolute computed time. This should hopefully reduce flakes in CI as well. Note that we keep the retry loop in case the entire function is running behind, because the test could still be scheduled out, by either the kernel or by the hypervisor's kernel, in which case restarting the test and hoping to not be scheduled out still helps. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Suggested-by: Thomas Gleixner <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kim Phillips <[email protected]> Date: Mon Aug 8 09:32:33 2022 -0500 x86/bugs: Enable STIBP for IBPB mitigated RETBleed commit e6cfcdda8cbe81eaf821c897369a65fec987b404 upstream. AMD's "Technical Guidance for Mitigating Branch Type Confusion, Rev. 1.0 2022-07-12" whitepaper, under section 6.1.2 "IBPB On Privileged Mode Entry / SMT Safety" says: Similar to the Jmp2Ret mitigation, if the code on the sibling thread cannot be trusted, software should set STIBP to 1 or disable SMT to ensure SMT safety when using this mitigation. So, like already being done for retbleed=unret, and now also for retbleed=ibpb, force STIBP on machines that have it, and report its SMT vulnerability status accordingly. [ bp: Remove the "we" and remove "[AMD]" applicability parameter which doesn't work here. ] Fixes: 3ebc17006888 ("x86/bugs: Add retbleed=ibpb") Signed-off-by: Kim Phillips <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Cc: [email protected] # 5.10, 5.15, 5.19 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chenyi Qiang <[email protected]> Date: Tue Aug 2 11:32:06 2022 +0800 x86/bus_lock: Don't assume the init value of DEBUGCTLMSR.BUS_LOCK_DETECT to be zero [ Upstream commit ffa6482e461ff550325356ae705b79e256702ea9 ] It's possible that this kernel has been kexec'd from a kernel that enabled bus lock detection, or (hypothetically) BIOS/firmware has set DEBUGCTLMSR_BUS_LOCK_DETECT. Disable bus lock detection explicitly if not wanted. Fixes: ebb1064e7c2e ("x86/traps: Handle #DB for bus lock") Signed-off-by: Chenyi Qiang <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Andrea Righi <[email protected]> Date: Thu Jul 14 09:49:15 2022 +0200 x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y [ Upstream commit de979c83574abf6e78f3fa65b716515c91b2613d ] With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_$(BITS).o becomes an empty object file. With some old versions of binutils (i.e., 2.35.90.20210113-1ubuntu1) the GNU assembler doesn't generate a symbol table for empty object files and objtool fails with the following error when a valid symbol table cannot be found: arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table To prevent this from happening, build thunk_$(BITS).o only if CONFIG_PREEMPTION is enabled. BugLink: https://bugs.launchpad.net/bugs/1911359 Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft") Signed-off-by: Andrea Righi <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/Ys/Ke7EWjcX+ZlXO@arighi-desktop Signed-off-by: Sasha Levin <[email protected]>
Author: Peter Zijlstra <[email protected]> Date: Fri Jun 17 16:52:06 2022 +0200 x86/extable: Fix ex_handler_msr() print condition [ Upstream commit a1a5482a2c6e38a3ebed32e571625c56a8cc41a6 ] On Fri, Jun 17, 2022 at 02:08:52PM +0300, Stephane Eranian wrote: > Some changes to the way invalid MSR accesses are reported by the > kernel is causing some problems with messages printed on the > console. > > We have seen several cases of ex_handler_msr() printing invalid MSR > accesses once but the callstack multiple times causing confusion on > the console. > The problem here is that another earlier commit (5.13): > > a358f40600b3 ("once: implement DO_ONCE_LITE for non-fast-path "do once" functionality") > > Modifies all the pr_*_once() calls to always return true claiming > that no caller is ever checking the return value of the functions. > > This is why we are seeing the callstack printed without the > associated printk() msg. Extract the ONCE_IF(cond) part into __ONCE_LTE_IF() and use that to implement DO_ONCE_LITE_IF() and fix the extable code. Fixes: a358f40600b3 ("once: implement DO_ONCE_LITE for non-fast-path "do once" functionality") Reported-by: Stephane Eranian <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Stephane Eranian <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Aug 2 15:04:16 2022 +0900 x86/kprobes: Update kcb status flag after singlestepping commit dec8784c9088b131a1523f582c2194cfc8107dc0 upstream. Fix kprobes to update kcb (kprobes control block) status flag to KPROBE_HIT_SSDONE even if the kp->post_handler is not set. This bug may cause a kernel panic if another INT3 user runs right after kprobes because kprobe_int3_handler() misunderstands the INT3 is kprobe's single stepping INT3. Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step") Reported-by: Daniel Müller <[email protected]> Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Daniel Müller <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/all/20220727210136.jjgc3lpqeq42yr3m@muellerd-fedora-PC2BDTX9 Link: https://lore.kernel.org/r/165942025658.342061.12452378391879093249.stgit@devnote2 Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Siddh Raman Pant <[email protected]> Date: Sun Jul 31 21:39:13 2022 +0530 x86/numa: Use cpumask_available instead of hardcoded NULL check [ Upstream commit 625395c4a0f4775e0fe00f616888d2e6c1ba49db ] GCC-12 started triggering a new warning: arch/x86/mm/numa.c: In function ‘cpumask_of_node’: arch/x86/mm/numa.c:916:39: warning: the comparison will always evaluate as ‘false’ for the address of ‘node_to_cpumask_map’ will never be NULL [-Waddress] 916 | if (node_to_cpumask_map[node] == NULL) { | ^~ node_to_cpumask_map is of type cpumask_var_t[]. When CONFIG_CPUMASK_OFFSTACK is set, cpumask_var_t is typedef'd to a pointer for dynamic allocation, else to an array of one element. The "wicked game" can be checked on line 700 of include/linux/cpumask.h. The original code in debug_cpumask_set_cpu() and cpumask_of_node() were probably written by the original authors with CONFIG_CPUMASK_OFFSTACK=y (i.e. dynamic allocation) in mind, checking if the cpumask was available via a direct NULL check. When CONFIG_CPUMASK_OFFSTACK is not set, GCC gives the above warning while compiling the kernel. Fix that by using cpumask_available(), which does the NULL check when CONFIG_CPUMASK_OFFSTACK is set, otherwise returns true. Use it wherever such checks are made. Conditional definitions of cpumask_available() can be found along with the definition of cpumask_var_t. Check the cpumask.h reference mentioned above. Fixes: c032ef60d1aa ("cpumask: convert node_to_cpumask_map[] to cpumask_var_t") Fixes: de2d9445f162 ("x86: Unify node_to_cpumask_map handling between 32 and 64bit") Signed-off-by: Siddh Raman Pant <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Fri Jul 15 17:15:36 2022 +0200 x86/olpc: fix 'logical not is only applied to the left hand side' commit 3a2ba42cbd0b669ce3837ba400905f93dd06c79f upstream. The bitops compile-time optimization series revealed one more problem in olpc-xo1-sci.c:send_ebook_state(), resulted in GCC warnings: arch/x86/platform/olpc/olpc-xo1-sci.c: In function 'send_ebook_state': arch/x86/platform/olpc/olpc-xo1-sci.c:83:63: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 83 | if (!!test_bit(SW_TABLET_MODE, ebook_switch_idev->sw) == state) | ^~ arch/x86/platform/olpc/olpc-xo1-sci.c:83:13: note: add parentheses around left hand side expression to silence this warning Despite this code working as intended, this redundant double negation of boolean value, together with comparing to `char` with no explicit conversion to bool, makes compilers think the author made some unintentional logical mistakes here. Make it the other way around and negate the char instead to silence the warnings. Fixes: d2aa37411b8e ("x86/olpc/xo1/sci: Produce wakeup events for buttons and switches") Cc: [email protected] # 3.5+ Reported-by: Guenter Roeck <[email protected]> Reported-by: kernel test robot <[email protected]> Reviewed-and-tested-by: Guenter Roeck <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Yury Norov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Mon Jun 20 16:07:23 2022 +0200 x86/pmem: Fix platform-device leak in error path [ Upstream commit 229e73d46994f15314f58b2d39bf952111d89193 ] Make sure to free the platform device in the unlikely event that registration fails. Fixes: 7a67832c7e44 ("libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option") Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Wyes Karny <[email protected]> Date: Mon Jun 6 23:33:34 2022 +0530 x86: Handle idle=nomwait cmdline properly for x86_idle [ Upstream commit 8bcedb4ce04750e1ccc9a6b6433387f6a9166a56 ] When kernel is booted with idle=nomwait do not use MWAIT as the default idle state. If the user boots the kernel with idle=nomwait, it is a clear direction to not use mwait as the default idle state. However, the current code does not take this into consideration while selecting the default idle state on x86. Fix it by checking for the idle=nomwait boot option in prefer_mwait_c1_over_halt(). Also update the documentation around idle=nomwait appropriately. [ dhansen: tweak commit message ] Signed-off-by: Wyes Karny <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Tested-by: Zhang Rui <[email protected]> Link: https://lkml.kernel.org/r/fdc2dc2d0a1bc21c2f53d989ea2d2ee3ccbc0dbe.1654538381.git-series.wyes.karny@amd.com Signed-off-by: Sasha Levin <[email protected]>
Author: Nick Desaulniers <[email protected]> Date: Wed Aug 10 15:24:41 2022 -0700 x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments commit ffcf9c5700e49c0aee42dcba9a12ba21338e8136 upstream. Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form: ld: warning: arch/x86/boot/pmjump.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: arch/x86/boot/compressed/vmlinux has a LOAD segment with RWX permissions Generally, we would like to avoid the stack being executable. Because there could be a need for the stack to be executable, assembler sources have to opt-in to this security feature via explicit creation of the .note.GNU-stack feature (which compilers create by default) or command line flag --noexecstack. Or we can simply tell the linker the production of such sections is irrelevant and to link the stack as --noexecstack. LLVM's LLD linker defaults to -z noexecstack, so this flag isn't strictly necessary when linking with LLD, only BFD, but it doesn't hurt to be explicit here for all linkers IMO. --no-warn-rwx-segments is currently BFD specific and only available in the current latest release, so it's wrapped in an ld-option check. While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments. Link: https://lore.kernel.org/linux-block/[email protected]/ Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Link: https://github.com/llvm/llvm-project/issues/57009 Reported-and-tested-by: Jens Axboe <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maximilian Heyne <[email protected]> Date: Fri Jul 15 22:51:07 2022 +0000 xen-blkback: Apply 'feature_persistent' parameter when connect commit e94c6101e151b019b8babc518ac2a6ada644a5a1 upstream. In some use cases[1], the backend is created while the frontend doesn't support the persistent grants feature, but later the frontend can be changed to support the feature and reconnect. In the past, 'blkback' enabled the persistent grants feature since it unconditionally checked if frontend supports the persistent grants feature for every connect ('connect_ring()') and decided whether it should use persistent grans or not. However, commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") has mistakenly changed the behavior. It made the frontend feature support check to not be repeated once it shown the 'feature_persistent' as 'false', or the frontend doesn't support persistent grants. This commit changes the behavior of the parameter to make effect for every connect, so that the previous workflow can work again as expected. [1] https://lore.kernel.org/xen-devel/CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com/ Reported-by: Andrii Chepurnyi <[email protected]> Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <[email protected]> # 5.10.x Signed-off-by: Maximilian Heyne <[email protected]> Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Fri Jul 15 22:51:06 2022 +0000 xen-blkback: fix persistent grants negotiation commit fc9be616bb8f3ed9cf560308f86904f5c06be205 upstream. Persistent grants feature can be used only when both backend and the frontend supports the feature. The feature was always supported by 'blkback', but commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") has introduced a parameter for disabling it runtime. To avoid the parameter be updated while being used by 'blkback', the commit caches the parameter into 'vbd->feature_gnt_persistent' in 'xen_vbd_create()', and then check if the guest also supports the feature and finally updates the field in 'connect_ring()'. However, 'connect_ring()' could be called before 'xen_vbd_create()', so later execution of 'xen_vbd_create()' can wrongly overwrite 'true' to 'vbd->feature_gnt_persistent'. As a result, 'blkback' could try to use 'persistent grants' feature even if the guest doesn't support the feature. This commit fixes the issue by moving the parameter value caching to 'xen_blkif_alloc()', which allocates the 'blkif'. Because the struct embeds 'vbd' object, which will be used by 'connect_ring()' later, this should be called before 'connect_ring()' and therefore this should be the right and safe place to do the caching. Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <[email protected]> # 5.10.x Signed-off-by: Maximilian Heyne <[email protected]> Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: SeongJae Park <[email protected]> Date: Fri Jul 15 22:51:08 2022 +0000 xen-blkfront: Apply 'feature_persistent' parameter when connect commit 402c43ea6b34a1b371ffeed9adf907402569eaf5 upstream. In some use cases[1], the backend is created while the frontend doesn't support the persistent grants feature, but later the frontend can be changed to support the feature and reconnect. In the past, 'blkback' enabled the persistent grants feature since it unconditionally checked if frontend supports the persistent grants feature for every connect ('connect_ring()') and decided whether it should use persistent grans or not. However, commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") has mistakenly changed the behavior. It made the frontend feature support check to not be repeated once it shown the 'feature_persistent' as 'false', or the frontend doesn't support persistent grants. Similar behavioral change has made on 'blkfront' by commit 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants"). This commit changes the behavior of the parameter to make effect for every connect, so that the previous behavior of 'blkfront' can be restored. [1] https://lore.kernel.org/xen-devel/CAJwUmVB6H3iTs-C+U=v-pwJB7-_ZRHPxHzKRJZ22xEPW7z8a=g@mail.gmail.com/ Fixes: 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants") Cc: <[email protected]> # 5.10.x Signed-off-by: SeongJae Park <[email protected]> Reviewed-by: Maximilian Heyne <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Max Filippov <[email protected]> Date: Thu Jul 7 00:23:16 2022 -0700 xtensa: iss/network: provide release() callback [ Upstream commit 8864fb8359682912ee99235db7db916733a1fd7b ] Provide release() callback for the platform device embedded into struct iss_net_private and registered in the iss_net_configure so that platform_device_unregister could be called for it. Signed-off-by: Max Filippov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yang Yingliang <[email protected]> Date: Thu Jul 7 10:32:29 2022 +0800 xtensa: iss: fix handling error cases in iss_net_configure() [ Upstream commit 628ccfc8f5f79dd548319408fcc53949fe97b258 ] The 'pdev' and 'netdev' need to be released in error cases of iss_net_configure(). Change the return type of iss_net_configure() to void, because it's not used. Fixes: 7282bee78798 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 8") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Max Filippov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>