June 2024 - Linux-stable-mirror

patch "iio: adc: ad9467: fix scan type sign" added to char-misc-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad9467: fix scan type sign to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. From 8a01ef749b0a632f0e1f4ead0f08b3310d99fcb1 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Fri, 3 May 2024 14:45:05 -0500 Subject: iio: adc: ad9467: fix scan type sign According to the IIO documentation, the sign in the scan type should be lower case. The ad9467 driver was incorrectly using upper case. Fix by changing to lower case. Fixes: 4606d0f4b05f ("iio: adc: ad9467: add support for AD9434 high-speed ADC") Fixes: ad6797120238 ("iio: adc: ad9467: add support AD9467 ADC") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://lore.kernel.org/r/20240503-ad9467-fix-scan-type-sign-v1-1-c7a1a066e… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad9467.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/ad9467.c b/drivers/iio/adc/ad9467.c index e85b763b9ffc..8f5b9c3f6e3d 100644 --- a/drivers/iio/adc/ad9467.c +++ b/drivers/iio/adc/ad9467.c @@ -243,11 +243,11 @@ static void __ad9467_get_scale(struct ad9467_state *st, int index, } static const struct iio_chan_spec ad9434_channels[] = { - AD9467_CHAN(0, 0, 12, 'S'), + AD9467_CHAN(0, 0, 12, 's'), }; static const struct iio_chan_spec ad9467_channels[] = { - AD9467_CHAN(0, 0, 16, 'S'), + AD9467_CHAN(0, 0, 16, 's'), }; static const struct ad9467_chip_info ad9467_chip_tbl = { -- 2.45.2

12 months

1
0
0 0

[PATCH] ACPI: x86: Force StorageD3Enable on more products

by Mario Limonciello

A Rembrandt-based HP thin client is reported to have problems where the NVME disk isn't present after resume from s2idle. This is because the NVME disk wasn't put into D3 at suspend, and that happened because the StorageD3Enable _DSD was missing in the BIOS. As AMD's architecture requires that the NVME is in D3 for s2idle, adjust the criteria for force_storage_d3 to match *all* Zen SoCs when the FADT advertises low power idle support. This will ensure that any future products with this BIOS deficiency don't need to be added to the allow list of overrides. Cc: stable(a)vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- drivers/acpi/x86/utils.c | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/drivers/acpi/x86/utils.c b/drivers/acpi/x86/utils.c index 90c3d2eab9e9..7507a7706898 100644 --- a/drivers/acpi/x86/utils.c +++ b/drivers/acpi/x86/utils.c @@ -197,16 +197,16 @@ bool acpi_device_override_status(struct acpi_device *adev, unsigned long long *s } /* - * AMD systems from Renoir and Lucienne *require* that the NVME controller + * AMD systems from Renoir onwards *require* that the NVME controller * is put into D3 over a Modern Standby / suspend-to-idle cycle. * * This is "typically" accomplished using the `StorageD3Enable` * property in the _DSD that is checked via the `acpi_storage_d3` function - * but this property was introduced after many of these systems launched - * and most OEM systems don't have it in their BIOS. + * but some OEM systems still don't have it in their BIOS. * * The Microsoft documentation for StorageD3Enable mentioned that Windows has - * a hardcoded allowlist for D3 support, which was used for these platforms. + * a hardcoded allowlist for D3 support as well as a registry key to override + * the BIOS, which has been used for these cases. * * This allows quirking on Linux in a similar fashion. * @@ -219,19 +219,15 @@ bool acpi_device_override_status(struct acpi_device *adev, unsigned long long *s * https://bugzilla.kernel.org/show_bug.cgi?id=216773 * https://bugzilla.kernel.org/show_bug.cgi?id=217003 * 2) On at least one HP system StorageD3Enable is missing on the second NVME - disk in the system. + * disk in the system. + * 3) On at least one HP Rembrandt system StorageD3Enable is missing on the only + * NVME device. */ -static const struct x86_cpu_id storage_d3_cpu_ids[] = { - X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 24, NULL), /* Picasso */ - X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 96, NULL), /* Renoir */ - X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 104, NULL), /* Lucienne */ - X86_MATCH_VENDOR_FAM_MODEL(AMD, 25, 80, NULL), /* Cezanne */ - {} -}; - bool force_storage_d3(void) { - return x86_match_cpu(storage_d3_cpu_ids); + if (!cpu_feature_enabled(X86_FEATURE_ZEN)) + return false; + return acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0; } /* -- 2.43.0

12 months

3
2
0 0

[PATCH v2] dmaengine: xilinx: xdma: Fix data synchronisation in xdma_channel_isr()

by Louis Chauvet

Requests the vchan lock before using xdma->stop_request. Fixes: 6a40fb824596 ("dmaengine: xilinx: xdma: Fix synchronization issue") Cc: stable(a)vger.kernel.org Signed-off-by: Louis Chauvet <louis.chauvet(a)bootlin.com> --- Changes in v2: - Apply comments from Markus - Link to v1: https://lore.kernel.org/r/20240527-xdma-fixes-v1-1-f31434b56842@bootlin.com --- drivers/dma/xilinx/xdma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c index e143a7330816..718842fdaf98 100644 --- a/drivers/dma/xilinx/xdma.c +++ b/drivers/dma/xilinx/xdma.c @@ -885,11 +885,11 @@ static irqreturn_t xdma_channel_isr(int irq, void *dev_id) u32 st; bool repeat_tx; + spin_lock(&xchan->vchan.lock); + if (xchan->stop_requested) complete(&xchan->last_interrupt); - spin_lock(&xchan->vchan.lock); - /* get submitted request */ vd = vchan_next_desc(&xchan->vchan); if (!vd) --- base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0 change-id: 20240527-xdma-fixes-74bbe2dcbeb8 Best regards, -- Louis Chauvet <louis.chauvet(a)bootlin.com>

12 months

3
3
0 0

[PATCH v3 2/2] x86/sgx: Resolve EREMOVE page vs EAUG page data race

by Dmitrii Kuvaiskii

Two enclave threads may try to add and remove the same enclave page simultaneously (e.g., if the SGX runtime supports both lazy allocation and MADV_DONTNEED semantics). Consider some enclave page added to the enclave. User space decides to temporarily remove this page (e.g., emulating the MADV_DONTNEED semantics) on CPU1. At the same time, user space performs a memory access on the same page on CPU2, which results in a #PF and ultimately in sgx_vma_fault(). Scenario proceeds as follows: /* * CPU1: User space performs * ioctl(SGX_IOC_ENCLAVE_REMOVE_PAGES) * on enclave page X */ sgx_encl_remove_pages() { mutex_lock(&encl->lock); entry = sgx_encl_load_page(encl); /* * verify that page is * trimmed and accepted */ mutex_unlock(&encl->lock); /* * remove PTE entry; cannot * be performed under lock */ sgx_zap_enclave_ptes(encl); /* * Fault on CPU2 on same page X */ sgx_vma_fault() { /* * PTE entry was removed, but the * page is still in enclave's xarray */ xa_load(&encl->page_array) != NULL -> /* * SGX driver thinks that this page * was swapped out and loads it */ mutex_lock(&encl->lock); /* * this is effectively a no-op */ entry = sgx_encl_load_page_in_vma(); /* * add PTE entry * * *BUG*: a PTE is installed for a * page in process of being removed */ vmf_insert_pfn(...); mutex_unlock(&encl->lock); return VM_FAULT_NOPAGE; } /* * continue with page removal */ mutex_lock(&encl->lock); sgx_encl_free_epc_page(epc_page) { /* * remove page via EREMOVE */ /* * free EPC page */ sgx_free_epc_page(epc_page); } xa_erase(&encl->page_array); mutex_unlock(&encl->lock); } Here, CPU1 removed the page. However CPU2 installed the PTE entry on the same page. This enclave page becomes perpetually inaccessible (until another SGX_IOC_ENCLAVE_REMOVE_PAGES ioctl). This is because the page is marked accessible in the PTE entry but is not EAUGed, and any subsequent access to this page raises a fault: with the kernel believing there to be a valid VMA, the unlikely error code X86_PF_SGX encountered by code path do_user_addr_fault() -> access_error() causes the SGX driver's sgx_vma_fault() to be skipped and user space receives a SIGSEGV instead. The userspace SIGSEGV handler cannot perform EACCEPT because the page was not EAUGed. Thus, the user space is stuck with the inaccessible page. Fix this race by forcing the fault handler on CPU2 to back off if the page is currently being removed (on CPU1). This is achieved by introducing a new flag SGX_ENCL_PAGE_BEING_REMOVED, which is unset by default and set only right-before the first mutex_unlock() in sgx_encl_remove_pages(). Upon loading the page, CPU2 checks whether this page is being removed, and if yes then CPU2 backs off and waits until the page is completely removed. After that, any memory access to this page results in a normal "allocate and EAUG a page on #PF" flow. Fixes: 9849bb27152c ("x86/sgx: Support complete page removal") Cc: stable(a)vger.kernel.org Signed-off-by: Dmitrii Kuvaiskii <dmitrii.kuvaiskii(a)intel.com> Reviewed-by: Haitao Huang <haitao.huang(a)linux.intel.com> Reviewed-by: Jarkko Sakkinen <jarkko(a)kernel.org> Acked-by: Reinette Chatre <reinette.chatre(a)intel.com> --- arch/x86/kernel/cpu/sgx/encl.c | 3 ++- arch/x86/kernel/cpu/sgx/encl.h | 3 +++ arch/x86/kernel/cpu/sgx/ioctl.c | 1 + 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c index 41f14b1a3025..7ccd8b2fce5f 100644 --- a/arch/x86/kernel/cpu/sgx/encl.c +++ b/arch/x86/kernel/cpu/sgx/encl.c @@ -257,7 +257,8 @@ static struct sgx_encl_page *__sgx_encl_load_page(struct sgx_encl *encl, /* Entry successfully located. */ if (entry->epc_page) { - if (entry->desc & SGX_ENCL_PAGE_BEING_RECLAIMED) + if (entry->desc & (SGX_ENCL_PAGE_BEING_RECLAIMED | + SGX_ENCL_PAGE_BEING_REMOVED)) return ERR_PTR(-EBUSY); return entry; diff --git a/arch/x86/kernel/cpu/sgx/encl.h b/arch/x86/kernel/cpu/sgx/encl.h index f94ff14c9486..fff5f2293ae7 100644 --- a/arch/x86/kernel/cpu/sgx/encl.h +++ b/arch/x86/kernel/cpu/sgx/encl.h @@ -25,6 +25,9 @@ /* 'desc' bit marking that the page is being reclaimed. */ #define SGX_ENCL_PAGE_BEING_RECLAIMED BIT(3) +/* 'desc' bit marking that the page is being removed. */ +#define SGX_ENCL_PAGE_BEING_REMOVED BIT(2) + struct sgx_encl_page { unsigned long desc; unsigned long vm_max_prot_bits:8; diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c index 5d390df21440..de59219ae794 100644 --- a/arch/x86/kernel/cpu/sgx/ioctl.c +++ b/arch/x86/kernel/cpu/sgx/ioctl.c @@ -1142,6 +1142,7 @@ static long sgx_encl_remove_pages(struct sgx_encl *encl, * Do not keep encl->lock because of dependency on * mmap_lock acquired in sgx_zap_enclave_ptes(). */ + entry->desc |= SGX_ENCL_PAGE_BEING_REMOVED; mutex_unlock(&encl->lock); sgx_zap_enclave_ptes(encl, addr); -- 2.34.1

12 months

3
4
0 0

[PATCH v2 1/2] memfd: fix MFD_NOEXEC_SEAL to be non-sealable by default

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)google.com> By default, memfd_create() creates a non-sealable MFD, unless the MFD_ALLOW_SEALING flag is set. When the MFD_NOEXEC_SEAL flag is initially introduced, the MFD created with that flag is sealable, even though MFD_ALLOW_SEALING is not set. This patch changes MFD_NOEXEC_SEAL to be non-sealable by default, unless MFD_ALLOW_SEALING is explicitly set. This is a non-backward compatible change. However, as MFD_NOEXEC_SEAL is new, we expect not many applications will rely on the nature of MFD_NOEXEC_SEAL being sealable. In most cases, the application already sets MFD_ALLOW_SEALING if they need a sealable MFD. Additionally, this enhances the useability of pid namespace sysctl vm.memfd_noexec. When vm.memfd_noexec equals 1 or 2, the kernel will add MFD_NOEXEC_SEAL if mfd_create does not specify MFD_EXEC or MFD_NOEXEC_SEAL, and the addition of MFD_NOEXEC_SEAL enables the MFD to be sealable. This means, any application that does not desire this behavior will be unable to utilize vm.memfd_noexec = 1 or 2 to migrate/enforce non-executable MFD. This adjustment ensures that applications can anticipate that the sealable characteristic will remain unmodified by vm.memfd_noexec. This patch was initially developed by Barnabás Pőcze, and Barnabás used Debian Code Search and GitHub to try to find potential breakages and could only find a single one. Dbus-broker's memfd_create() wrapper is aware of this implicit `MFD_ALLOW_SEALING` behavior, and tries to work around it [1]. This workaround will break. Luckily, this only affects the test suite, it does not affect the normal operations of dbus-broker. There is a PR with a fix[2]. In addition, David Rheinsberg also raised similar fix in [3] [1]: https://github.com/bus1/dbus-broker/blob/9eb0b7e5826fc76cad7b025bc46f267d4a… [2]: https://github.com/bus1/dbus-broker/pull/366 [3]: https://lore.kernel.org/lkml/20230714114753.170814-1-david@readahead.eu/ Cc: stable(a)vger.kernel.org Fixes: 105ff5339f498a ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC") Signed-off-by: Barnabás Pőcze <pobrn(a)protonmail.com> Signed-off-by: Jeff Xu <jeffxu(a)google.com> Reviewed-by: David Rheinsberg <david(a)readahead.eu> --- mm/memfd.c | 9 ++++---- tools/testing/selftests/memfd/memfd_test.c | 26 +++++++++++++++++++++- 2 files changed, 29 insertions(+), 6 deletions(-) diff --git a/mm/memfd.c b/mm/memfd.c index 7d8d3ab3fa37..8b7f6afee21d 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -356,12 +356,11 @@ SYSCALL_DEFINE2(memfd_create, inode->i_mode &= ~0111; file_seals = memfd_file_seals_ptr(file); - if (file_seals) { - *file_seals &= ~F_SEAL_SEAL; + if (file_seals) *file_seals |= F_SEAL_EXEC; - } - } else if (flags & MFD_ALLOW_SEALING) { - /* MFD_EXEC and MFD_ALLOW_SEALING are set */ + } + + if (flags & MFD_ALLOW_SEALING) { file_seals = memfd_file_seals_ptr(file); if (file_seals) *file_seals &= ~F_SEAL_SEAL; diff --git a/tools/testing/selftests/memfd/memfd_test.c b/tools/testing/selftests/memfd/memfd_test.c index 95af2d78fd31..8579a93d006b 100644 --- a/tools/testing/selftests/memfd/memfd_test.c +++ b/tools/testing/selftests/memfd/memfd_test.c @@ -1151,7 +1151,7 @@ static void test_noexec_seal(void) mfd_def_size, MFD_CLOEXEC | MFD_NOEXEC_SEAL); mfd_assert_mode(fd, 0666); - mfd_assert_has_seals(fd, F_SEAL_EXEC); + mfd_assert_has_seals(fd, F_SEAL_SEAL | F_SEAL_EXEC); mfd_fail_chmod(fd, 0777); close(fd); } @@ -1169,6 +1169,14 @@ static void test_sysctl_sysctl0(void) mfd_assert_has_seals(fd, 0); mfd_assert_chmod(fd, 0644); close(fd); + + fd = mfd_assert_new("kern_memfd_sysctl_0_dfl", + mfd_def_size, + MFD_CLOEXEC); + mfd_assert_mode(fd, 0777); + mfd_assert_has_seals(fd, F_SEAL_SEAL); + mfd_assert_chmod(fd, 0644); + close(fd); } static void test_sysctl_set_sysctl0(void) @@ -1206,6 +1214,14 @@ static void test_sysctl_sysctl1(void) mfd_assert_has_seals(fd, F_SEAL_EXEC); mfd_fail_chmod(fd, 0777); close(fd); + + fd = mfd_assert_new("kern_memfd_sysctl_1_noexec_nosealable", + mfd_def_size, + MFD_CLOEXEC | MFD_NOEXEC_SEAL); + mfd_assert_mode(fd, 0666); + mfd_assert_has_seals(fd, F_SEAL_EXEC | F_SEAL_SEAL); + mfd_fail_chmod(fd, 0777); + close(fd); } static void test_sysctl_set_sysctl1(void) @@ -1238,6 +1254,14 @@ static void test_sysctl_sysctl2(void) mfd_assert_has_seals(fd, F_SEAL_EXEC); mfd_fail_chmod(fd, 0777); close(fd); + + fd = mfd_assert_new("kern_memfd_sysctl_2_noexec_notsealable", + mfd_def_size, + MFD_CLOEXEC | MFD_NOEXEC_SEAL); + mfd_assert_mode(fd, 0666); + mfd_assert_has_seals(fd, F_SEAL_EXEC | F_SEAL_SEAL); + mfd_fail_chmod(fd, 0777); + close(fd); } static void test_sysctl_set_sysctl2(void) -- 2.45.1.288.g0e0cd299f1-goog

12 months

5
6
0 0

[PATCH 1/1] hwrng: amd - Convert PCIBIOS_* return codes to errnos

by Ilpo Järvinen

amd_rng_mod_init() uses pci_read_config_dword() that returns PCIBIOS_* codes. The return code is then returned as is but amd_rng_mod_init() is a module_init() function that should return normal errnos. Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: 96d63c0297cc ("[PATCH] Add AMD HW RNG driver") Cc: stable(a)vger.kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> --- drivers/char/hw_random/amd-rng.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c index 86162a13681e..9a24d19236dc 100644 --- a/drivers/char/hw_random/amd-rng.c +++ b/drivers/char/hw_random/amd-rng.c @@ -143,8 +143,10 @@ static int __init amd_rng_mod_init(void) found: err = pci_read_config_dword(pdev, 0x58, &pmbase); - if (err) + if (err) { + err = pcibios_err_to_errno(err); goto put_dev; + } pmbase &= 0x0000FF00; if (pmbase == 0) { -- 2.39.2

12 months

2
1
0 0

backport request

by Ard Biesheuvel

Please consider commit 15aa8fb852f995dd x86/efistub: Omit physical KASLR when memory reservations exist for backporting to v6.1 and later. Thanks, Ard.

12 months

2
7
0 0

[PATCH v2] drm/amdgpu: Fix the BO release clear memory warning

by Arunpravin Paneer Selvam

This happens when the amdgpu_bo_release_notify running before amdgpu_ttm_set_buffer_funcs_status set the buffer funcs to enabled. check the buffer funcs enablement before calling the fill buffer memory. v2:(Christian) - Apply it only for GEM buffers and since GEM buffers are only allocated/freed while the driver is loaded we never run into the issue to clear with buffer funcs disabled. Log snip: [ 6.036477] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory with ring turned off. [ 6.036667] ------------[ cut here ]------------ [ 6.036668] WARNING: CPU: 3 PID: 370 at drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1355 amdgpu_bo_release_notify+0x201/0x220 [amdgpu] [ 6.036767] Modules linked in: hid_generic amdgpu(+) amdxcp drm_exec gpu_sched drm_buddy i2c_algo_bit usbhid drm_suballoc_helper drm_display_helper hid sd_mod cec rc_core drm_ttm_helper ahci ttm nvme libahci drm_kms_helper nvme_core r8169 xhci_pci libata t10_pi xhci_hcd realtek crc32_pclmul crc64_rocksoft mdio_devres crc64 drm crc32c_intel scsi_mod usbcore thunderbolt crc_t10dif i2c_piix4 libphy crct10dif_generic crct10dif_pclmul crct10dif_common scsi_common usb_common video wmi gpio_amdpt gpio_generic button [ 6.036793] CPU: 3 PID: 370 Comm: (udev-worker) Not tainted 6.8.7-dirty #1 [ 6.036795] Hardware name: ASRock X670E Taichi/X670E Taichi, BIOS 2.10 03/26/2024 [ 6.036796] RIP: 0010:amdgpu_bo_release_notify+0x201/0x220 [amdgpu] [ 6.036891] Code: 0b e9 af fe ff ff 48 ba ff ff ff ff ff ff ff 7f 31 f6 4c 89 e7 e8 7f 2f 7a d8 eb 98 e8 18 28 7a d8 eb b2 0f 0b e9 58 fe ff ff <0f> 0b eb a7 be 03 00 00 00 e8 e1 89 4e d8 eb 9b e8 aa 4d ad d8 66 [ 6.036892] RSP: 0018:ffffbbe140d1f638 EFLAGS: 00010282 [ 6.036894] RAX: 00000000ffffffea RBX: ffff90cba9e4e858 RCX: ffff90dabde38c28 [ 6.036895] RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001 [ 6.036896] RBP: ffff90cba980ef40 R08: 0000000000000000 R09: ffffbbe140d1f3c0 [ 6.036896] R10: ffffbbe140d1f3b8 R11: 0000000000000003 R12: ffff90cba9e4e800 [ 6.036897] R13: ffff90cba9e4e958 R14: ffff90cba980ef40 R15: 0000000000000258 [ 6.036898] FS: 00007f2bd1679d00(0000) GS:ffff90da7e2c0000(0000) knlGS:0000000000000000 [ 6.036899] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.036900] CR2: 000055a9b0f7299d CR3: 000000011bb6e000 CR4: 0000000000750ef0 [ 6.036901] PKRU: 55555554 [ 6.036901] Call Trace: [ 6.036903] <TASK> [ 6.036904] ? amdgpu_bo_release_notify+0x201/0x220 [amdgpu] [ 6.036998] ? __warn+0x81/0x130 [ 6.037002] ? amdgpu_bo_release_notify+0x201/0x220 [amdgpu] [ 6.037095] ? report_bug+0x171/0x1a0 [ 6.037099] ? handle_bug+0x3c/0x80 [ 6.037101] ? exc_invalid_op+0x17/0x70 [ 6.037103] ? asm_exc_invalid_op+0x1a/0x20 [ 6.037107] ? amdgpu_bo_release_notify+0x201/0x220 [amdgpu] [ 6.037199] ? amdgpu_bo_release_notify+0x14a/0x220 [amdgpu] [ 6.037292] ttm_bo_release+0xff/0x2e0 [ttm] [ 6.037297] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.037299] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.037301] ? ttm_resource_move_to_lru_tail+0x140/0x1e0 [ttm] [ 6.037306] amdgpu_bo_free_kernel+0xcb/0x120 [amdgpu] [ 6.037399] dm_helpers_free_gpu_mem+0x41/0x80 [amdgpu] [ 6.037544] dcn315_clk_mgr_construct+0x198/0x7e0 [amdgpu] [ 6.037692] dc_clk_mgr_create+0x16e/0x5f0 [amdgpu] [ 6.037826] dc_create+0x28a/0x650 [amdgpu] [ 6.037958] amdgpu_dm_init.isra.0+0x2d5/0x1ec0 [amdgpu] [ 6.038085] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038087] ? prb_read_valid+0x1b/0x30 [ 6.038089] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038090] ? console_unlock+0x78/0x120 [ 6.038092] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038094] ? vprintk_emit+0x175/0x2c0 [ 6.038095] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038097] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038098] ? dev_printk_emit+0xa5/0xd0 [ 6.038104] dm_hw_init+0x12/0x30 [amdgpu] [ 6.038209] amdgpu_device_init+0x1e50/0x2500 [amdgpu] [ 6.038308] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038310] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038313] amdgpu_driver_load_kms+0x19/0x190 [amdgpu] [ 6.038409] amdgpu_pci_probe+0x18b/0x510 [amdgpu] [ 6.038505] local_pci_probe+0x42/0xa0 [ 6.038508] pci_device_probe+0xc7/0x240 [ 6.038510] really_probe+0x19b/0x3e0 [ 6.038513] ? __pfx___driver_attach+0x10/0x10 [ 6.038514] __driver_probe_device+0x78/0x160 [ 6.038516] driver_probe_device+0x1f/0x90 [ 6.038517] __driver_attach+0xd2/0x1c0 [ 6.038519] bus_for_each_dev+0x85/0xd0 [ 6.038521] bus_add_driver+0x116/0x220 [ 6.038523] driver_register+0x59/0x100 [ 6.038525] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [ 6.038618] do_one_initcall+0x58/0x320 [ 6.038621] do_init_module+0x60/0x230 [ 6.038624] init_module_from_file+0x89/0xe0 [ 6.038628] idempotent_init_module+0x120/0x2b0 [ 6.038630] __x64_sys_finit_module+0x5e/0xb0 [ 6.038632] do_syscall_64+0x84/0x1a0 [ 6.038634] ? do_syscall_64+0x90/0x1a0 [ 6.038635] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038637] ? do_syscall_64+0x90/0x1a0 [ 6.038638] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038639] ? do_syscall_64+0x90/0x1a0 [ 6.038640] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038642] ? srso_alias_return_thunk+0x5/0xfbef5 [ 6.038644] entry_SYSCALL_64_after_hwframe+0x78/0x80 [ 6.038645] RIP: 0033:0x7f2bd1e9d059 [ 6.038647] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8f 1d 0d 00 f7 d8 64 89 01 48 [ 6.038648] RSP: 002b:00007fffaf804878 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 6.038650] RAX: ffffffffffffffda RBX: 000055a9b2328d60 RCX: 00007f2bd1e9d059 [ 6.038650] RDX: 0000000000000000 RSI: 00007f2bd1fd0509 RDI: 0000000000000024 [ 6.038651] RBP: 0000000000000000 R08: 0000000000000040 R09: 000055a9b23000a0 [ 6.038652] R10: 0000000000000038 R11: 0000000000000246 R12: 00007f2bd1fd0509 [ 6.038652] R13: 0000000000020000 R14: 000055a9b2326f90 R15: 0000000000000000 [ 6.038655] </TASK> [ 6.038656] ---[ end trace 0000000000000000 ]--- Cc: <stable(a)vger.kernel.org> # 6.10+ Fixes: a68c7eaa7a8f ("drm/amdgpu: Enable clear page functionality") Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam(a)amd.com> Suggested-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c index 67c234bcf89f..3adaa4670103 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -108,6 +108,7 @@ int amdgpu_gem_object_create(struct amdgpu_device *adev, unsigned long size, memset(&bp, 0, sizeof(bp)); *obj = NULL; + flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE; bp.size = size; bp.byte_align = alignment; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index 8d8c39be6129..c556c8b653fa 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -604,8 +604,6 @@ int amdgpu_bo_create(struct amdgpu_device *adev, if (!amdgpu_bo_support_uswc(bo->flags)) bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; - bo->flags |= AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE; - bo->tbo.bdev = &adev->mman.bdev; if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA | AMDGPU_GEM_DOMAIN_GDS)) -- 2.25.1

12 months

4
3
0 0

[PATCH 0/7] arm64: dts: imx8qm: add subsystem lvds and mipi

by Frank Li

Add subsystem lvds and mipi. Add pwm and i2c in lvds and mipi. imx8qm-mek: - add remove-proc - fixed gpio number error for vmmc - add usb3 and typec - add pwm and i2c in lvds and mipi DTB_CHECK warning fixed by seperate patches. arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: usb@5b110000: usb@5b120000: 'port', 'usb-role-switch' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/usb/fsl,imx8qm-cdns3.yaml# arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: usb@5b120000: 'port', 'usb-role-switch' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/usb/cdns,usb3.yaml# ** binding fix patch: https://lore.kernel.org/imx/20240606161509.3201080-1-Frank.Li@nxp.com/T/#u arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: interrupt-controller@56240000: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/interrupt-controller/fsl,irqsteer.yaml# ** binding fix patch: https://lore.kernel.org/imx/20240528071141.92003-1-alexander.stein@ew.tq-gr… arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: pwm@56244000: 'oneOf' conditional failed, one must be fixed: 'interrupts' is a required property 'interrupts-extended' is a required property from schema $id: http://devicetree.org/schemas/pwm/imx-pwm.yaml# ** binding fix patch: https://lore.kernel.org/imx/dc9accba-78af-45ec-a516-b89f2d4f4b03@kernel.org… from schema $id: http://devicetree.org/schemas/interrupt-controller/fsl,irqsteer.yaml# arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: imx8qm-cm4-0: power-domains: [[15, 278], [15, 297]] is too short from schema $id: http://devicetree.org/schemas/remoteproc/fsl,imx-rproc.yaml# arch/arm64/boot/dts/freescale/imx8qm-mek.dtb: imx8qm-cm4-1: power-domains: [[15, 298], [15, 317]] is too short ** binding fix patch: https://lore.kernel.org/imx/20240606150030.3067015-1-Frank.Li@nxp.com/T/#u Signed-off-by: Frank Li <Frank.Li(a)nxp.com> --- Frank Li (7): arm64: dts: imx8qm: add lvds subsystem arm64: dts: imx8qm: add mipi subsystem arm64: dts: imx8qm-mek: add cm4 remote-proc and related memory region arm64: dts: imx8qm-mek: add pwm and i2c in lvds subsystem arm64: dts: imx8qm-mek: add i2c in mipi[0,1] subsystem arm64: dts: imx8qm-mek: fix gpio number for reg_usdhc2_vmmc arm64: dts: imx8qm-mek: add usb 3.0 and related type C nodes arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 308 +++++++++++++++++++++- arch/arm64/boot/dts/freescale/imx8qm-ss-lvds.dtsi | 231 ++++++++++++++++ arch/arm64/boot/dts/freescale/imx8qm-ss-mipi.dtsi | 286 ++++++++++++++++++++ arch/arm64/boot/dts/freescale/imx8qm.dtsi | 2 + 4 files changed, 826 insertions(+), 1 deletion(-) --- base-commit: ee78a17615ad0cfdbbc27182b1047cd36c9d4d5f change-id: 20240606-imx8qm-dts-usb-9c55d2bfe526 Best regards, --- Frank Li <Frank.Li(a)nxp.com>

12 months

2
2
0 0

Re: [PATCH v2] ext4: fix i_data_sem unlock order in ext4_ind_migrate()

by Theodore Ts'o

On Thu, Jun 06, 2024 at 12:14:22AM +0300, миша ухин wrote: > <div><div>Thank you for the comment.<br />It seems there might be a misunderstanding.<br />The commit 00d873c17e29 ("ext4: avoid deadlock in fs reclaim with page writeback") you mentioned introduces the use of memalloc_nofs_save()/memalloc_nofs_restore() when acquiring the EXT4_SB(sb)->s_writepages_rwsem lock.<br />On the other hand the patch we proposed corrects the order of locking/unlocking resources with calls to the functions ext4_journal_start()/ext4_journal_stop() and down_write(&EXT4_I(inode)->i_data_sem)/up_write(&EXT4_I(inode)->i_data_sem).<br />These patches do not appear to resolve the same issue, and the code changes are different.</div><div> </div><div>- <span style="white-space:pre-wrap">Mikhail Ukhin</span></div></div> PLEASE do not send HTML messages to the linux-kernel mailing list. It looks like garbage when read on a text mail reader. In any case, you're correct. I had misremembered the issue with this patch. The complaint that I had made with the V1 of the patch has not been corrected, which is that the assertion made in the commit description "the order of unlocking must be the reverse of the order of locking" is errant nonsense. It is simply is technically incorrect; the order in which locks are released doesn't matter. (And a jbd2 handle is not a lock.) The syzkaller report which apparntly triggered this failure was supplied by Artem here[1], and the explanation should include that it was triggered by an EXT4_IOC_MIGRATE ioctl which was set to require synchornous update because the file descriptor was opened with O_SYNC, and this could result in the jbd2_journal_stop() function calling jbd2_might_wait_for_commit() which could potentially trigger a deadlock if the EXT4_IOC_MIGRATE call is racing with write(2) system call. [1] https://lore.kernel.org/r/1845977.e0hk0VWMCB@cherry In any case, this is a low priority issue since the only program which uses EXT4_IOC_MIGRATE is e4defrag, and it doesn't open files with O_SYNC, so this isn't going to happen in real life. And so why don't you use this as an opportunity to practice writing a technically valid and correct commit description, and how to properlty submit patches and send valid (non-HTML) messages to the Linux kernel mailing list? Cheers, - Ted

12 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024