December 2023 - Linux-stable-mirror

[PATCH 4/4] mtd: rawnand: Clarify conditions to enable continuous reads

by Miquel Raynal

The current logic is probably fine but is a bit convoluted. Plus, we don't want partial pages to be part of the sequential operation just in case the core would optimize the page read with a subpage read (which would break the sequence). This may happen on the first and last page only, so if the start offset or the end offset is not aligned with a page boundary, better avoid them to prevent any risk. Cc: stable(a)vger.kernel.org Fixes: 003fe4b9545b ("mtd: rawnand: Support for sequential cache reads") Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- drivers/mtd/nand/raw/nand_base.c | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c index 139fdf3e58c0..bbdcfbe643f3 100644 --- a/drivers/mtd/nand/raw/nand_base.c +++ b/drivers/mtd/nand/raw/nand_base.c @@ -3460,21 +3460,29 @@ static void rawnand_enable_cont_reads(struct nand_chip *chip, unsigned int page, u32 readlen, int col) { struct mtd_info *mtd = nand_to_mtd(chip); + unsigned int end_page, end_col; + + chip->cont_read.ongoing = false; if (!chip->controller->supported_op.cont_read) return; - if ((col && col + readlen < (3 * mtd->writesize)) || - (!col && readlen < (2 * mtd->writesize))) { - chip->cont_read.ongoing = false; - return; - } + end_page = DIV_ROUND_UP(col + readlen, mtd->writesize); + end_col = (col + readlen) % mtd->writesize; - chip->cont_read.ongoing = true; - chip->cont_read.first_page = page; if (col) - chip->cont_read.first_page++; - chip->cont_read.last_page = page + ((readlen >> chip->page_shift) & chip->pagemask); + page++; + + if (end_col && end_page) + end_page--; + + if (page + 1 > end_page) + return; + + chip->cont_read.first_page = page; + chip->cont_read.last_page = end_page; + chip->cont_read.ongoing = true; + rawnand_cap_cont_reads(chip); } -- 2.34.1

8 months

2
6
0 0

[PATCH] Bluetooth: qca: fix device-address endianness

by Johan Hovold

The WCN6855 firmware on the Lenovo ThinkPad X13s expects the Bluetooth device address in MSB order when setting it using the EDL_WRITE_BD_ADDR_OPCODE command. Presumably, this is the case for all non-ROME devices which all use the EDL_WRITE_BD_ADDR_OPCODE command for this (unlike the ROME devices which use a different command and expect the address in LSB order). Reverse the little-endian address before setting it to make sure that the address can be configured using tools like btmgmt or using the 'local-bd-address' devicetree property. Note that this can potentially break systems with boot firmware which has started relying on the broken behaviour and is incorrectly passing the address via devicetree in MSB order. Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address") Cc: stable(a)vger.kernel.org # 5.1 Cc: Balakrishna Godavarthi <quic_bgodavar(a)quicinc.com> Cc: Matthias Kaehlcke <mka(a)chromium.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- Hi Qualcomm people, Could you please verify with your documentation that all non-ROME devices expect the address provided in the EDL_WRITE_BD_ADDR_OPCODE command in MSB order? I assume this is not something that anyone would change between firmware revisions, but if that turns out to be the case, we'd need to reverse the address based on firmware revision or similar. Johan drivers/bluetooth/btqca.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index fdb0fae88d1c..29035daf21bc 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -826,11 +826,15 @@ EXPORT_SYMBOL_GPL(qca_uart_setup); int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr) { + bdaddr_t bdaddr_swapped; struct sk_buff *skb; int err; - skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, bdaddr, - HCI_EV_VENDOR, HCI_INIT_TIMEOUT); + baswap(&bdaddr_swapped, bdaddr); + + skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6, + &bdaddr_swapped, HCI_EV_VENDOR, + HCI_INIT_TIMEOUT); if (IS_ERR(skb)) { err = PTR_ERR(skb); bt_dev_err(hdev, "QCA Change address cmd failed (%d)", err); -- 2.41.0

8 months, 1 week

6
15
0 0

[PATCH] perf/x86: Fix out of range data

by Namhyung Kim

On x86 each cpu_hw_events maintains a table for counter assignment but it missed to update one for the deleted event in x86_pmu_del(). This can make perf_clear_dirty_counters() reset used counter if it's called before event scheduling or enabling. Then it would return out of range data which doesn't make sense. The following code can reproduce the problem. $ cat repro.c #include <pthread.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <linux/perf_event.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <sys/syscall.h> struct perf_event_attr attr = { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_CPU_CYCLES, .disabled = 1, }; void *worker(void *arg) { int cpu = (long)arg; int fd1 = syscall(SYS_perf_event_open, &attr, -1, cpu, -1, 0); int fd2 = syscall(SYS_perf_event_open, &attr, -1, cpu, -1, 0); void *p; do { ioctl(fd1, PERF_EVENT_IOC_ENABLE, 0); p = mmap(NULL, 4096, PROT_READ, MAP_SHARED, fd1, 0); ioctl(fd2, PERF_EVENT_IOC_ENABLE, 0); ioctl(fd2, PERF_EVENT_IOC_DISABLE, 0); munmap(p, 4096); ioctl(fd1, PERF_EVENT_IOC_DISABLE, 0); } while (1); return NULL; } int main(void) { int i; int n = sysconf(_SC_NPROCESSORS_ONLN); pthread_t *th = calloc(n, sizeof(*th)); for (i = 0; i < n; i++) pthread_create(&th[i], NULL, worker, (void *)(long)i); for (i = 0; i < n; i++) pthread_join(th[i], NULL); free(th); return 0; } And you can see the out of range data using perf stat like this. Probably it'd be easier to see on a large machine. $ gcc -o repro repro.c -pthread $ ./repro & $ sudo perf stat -A -I 1000 2>&1 | awk '{ if (length($3) > 15) print }' 1.001028462 CPU6 196,719,295,683,763 cycles # 194290.996 GHz (71.54%) 1.001028462 CPU3 396,077,485,787,730 branch-misses # 15804359784.80% of all branches (71.07%) 1.001028462 CPU17 197,608,350,727,877 branch-misses # 14594186554.56% of all branches (71.22%) 2.020064073 CPU4 198,372,472,612,140 cycles # 194681.113 GHz (70.95%) 2.020064073 CPU6 199,419,277,896,696 cycles # 195720.007 GHz (70.57%) 2.020064073 CPU20 198,147,174,025,639 cycles # 194474.654 GHz (71.03%) 2.020064073 CPU20 198,421,240,580,145 stalled-cycles-frontend # 100.14% frontend cycles idle (70.93%) 3.037443155 CPU4 197,382,689,923,416 cycles # 194043.065 GHz (71.30%) 3.037443155 CPU20 196,324,797,879,414 cycles # 193003.773 GHz (71.69%) 3.037443155 CPU5 197,679,956,608,205 stalled-cycles-backend # 1315606428.66% backend cycles idle (71.19%) 3.037443155 CPU5 198,571,860,474,851 instructions # 13215422.58 insn per cycle It should move the contents in the cpuc->assign as well. Fixes: 5471eea5d3bf ("perf/x86: Reset the dirty counter to prevent the leak for an RDPMC task") Cc: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org Signed-off-by: Namhyung Kim <namhyung(a)kernel.org> --- arch/x86/events/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index 09050641ce5d..5b0dd07b1ef1 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -1644,6 +1644,7 @@ static void x86_pmu_del(struct perf_event *event, int flags) while (++i < cpuc->n_events) { cpuc->event_list[i-1] = cpuc->event_list[i]; cpuc->event_constraint[i-1] = cpuc->event_constraint[i]; + cpuc->assign[i-1] = cpuc->assign[i]; } cpuc->event_constraint[i-1] = NULL; --cpuc->n_events; -- 2.43.0.472.g3155946c3a-goog

8 months, 2 weeks

2
3
0 0

[PATCH 5.10/5.15 0/1] media: atomisp: add error checking to atomisp_create_pipes_stream()

by Anastasia Belova

atomisp_create_pipes_stream does not handle errors in __create_pipes and __create_streams in versions 5.10 and 5.15. The following patch may fix it. Found by Linux Verification Center (linuxtesting.org) with Svace.

8 months, 2 weeks

1
2
0 0

[REGRESSION] boot fails for EFI boot stub loaded by u-boot

by Ben Schneider

Hi Ard, I have an ESPRESSObin Ultra (aarch64) that uses U-Boot as its bootloader. It shipped from the manufacturer with with v5.10, and I've been trying to upgrade. U-Boot supports booting Image directly via EFI (https://u-boot.readthedocs.io/en/latest/usage/cmd/bootefi.html), and I have been using it that way to successfully boot the system up to and including v6.0.19. However, v6.1 and v6.5 kernels fail to boot. When booting successfully, the following messages are displayed: EFI stub: Booting Linux Kernel...EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary EFI stub: Using DTB from configuration table EFI stub: ERROR: Failed to install memreserve config table! EFI stub: Exiting boot services... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] I suspect many of the above error messages are simply attributable to using U-Boot to load an EFI stub and can be safely ignored given that the system boots and runs fine. When boot fails (v6.5), the following messages are displayed: EFI stub: Booting Linux Kernel... EFI stub: ERROR: FIRMWARE BUG: efi_loaded_image_t::image_base has bogus value EFI stub: ERROR: FIRMWARE BUG: kernel image not aligned on 64k boundary EFI stub: ERROR: Failed to install memreserve config table! EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... EFI stub: ERROR: Unable to construct new device tree. EFI stub: ERROR: Failed to update FDT and exit boot services In case it's relevant, the device tree for this device is arch/arm64/boot/marvell/armada-3720-espressobin-ultra.dts Hopefully I've reported this in the correct place or that the information provided is sufficient to get it where it needs to be. Let me know if there is additional information I can provide. I am also able to use the device to test. Sincerely, Ben Schneider #regzbot introduced v6.0..v6.1

8 months, 3 weeks

4
9
0 0

selftests: ftrace: Internal error: Oops: sve_save_state

by Naresh Kamboju

Following kernel crash noticed while running selftests: ftrace: ftracetest-ktap on FVP models running stable-rc 6.5.8-rc2. This is not an easy to reproduce issue and not seen on mainline and next. We are investigating this report. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Reported-by: Naresh Kamboju <naresh.kamboju(a)linaro.org> Test log: ---------- kselftest: Running tests in ftrace TAP version 13 1..1 # timeout set to 0 # selftests: ftrace: ftracetest-ktap # TAP version 13 # 1..129 # ok 1 Basic trace file check # ok 2 Basic test for tracers # ok 3 Basic trace clock test # ok 4 Basic event tracing check # ok 5 Change the ringbuffer size # ok 6 Snapshot and tracing setting # ok 7 Snapshot and tracing_cpumask # ok 8 trace_pipe and trace_marker [ 471.689140] [ 471.689264] ********************************************************** [ 471.689422] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ** [ 471.689574] ** ** [ 471.689716] ** trace_printk() being used. Allocating extra memory. ** [ 471.689878] ** ** [ 471.690031] ** This means that this is a DEBUG kernel and it is ** [ 471.690183] ** unsafe for production use. ** [ 471.690335] ** ** [ 471.690487] ** If you see this message and you are not debugging ** [ 471.690728] ** the kernel, report this immediately to your vendor! ** [ 471.690881] ** ** [ 471.691033] ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ** [ 471.691185] ********************************************************** [ 543.243648] hrtimer: interrupt took 11937170 ns [ 764.987161] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 764.992518] Mem abort info: [ 764.995330] ESR = 0x0000000096000044 [ 764.998562] EC = 0x25: DABT (current EL), IL = 32 bits [ 765.002434] SET = 0, FnV = 0 [ 765.005361] EA = 0, S1PTW = 0 [ 765.008327] FSC = 0x04: level 0 translation fault [ 765.012011] Data abort info: [ 765.014858] ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000 [ 765.018797] CM = 0, WnR = 1, TnD = 0, TagAccess = 0 [ 765.022562] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 765.026438] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008848bd000 [ 765.030782] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 765.037045] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP [ 765.038392] Modules linked in: ftrace_direct pl111_drm arm_spe_pmu drm_dma_helper crct10dif_ce panel_simple drm_kms_helper fuse drm dm_mod ip_tables x_tables [last unloaded: ftrace_direct] [ 765.044892] CPU: 3 PID: 808 Comm: rmmod Not tainted 6.5.8-rc2 #1 [ 765.046192] Hardware name: FVP Base RevC (DT) [ 765.047264] pstate: 234020c9 (nzCv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) [ 765.048693] pc : sve_save_state+0x4/0xf0 [ 765.049820] lr : fpsimd_save+0x1b8/0x218 [ 765.050933] sp : ffff800080a83ac0 [ 765.051871] x29: ffff800080a83ac0 x28: ffff000805257058 x27: 0000000000000001 [ 765.054108] x26: 0000000000000000 x25: ffffd7c64d332980 x24: 0000000000000000 [ 765.056341] x23: 0000000000000001 x22: ffff284232103000 x21: 0000000000000040 [ 765.058575] x20: ffff00087f7470b0 x19: ffffd7c64d6440b0 x18: 0000000000000000 [ 765.060811] x17: 0000000000000000 x16: ffff800080018000 x15: 0000000000000000 [ 765.063041] x14: 0000000000000000 x13: 0000000000000000 x12: 0000380a873b560e [ 765.065277] x11: ffffd7c64e0ae390 x10: ffff800080a83b10 x9 : ffffd7c64b5b7710 [ 765.067516] x8 : ffff800080a839b8 x7 : 000000000000001e x6 : ffff00080000c200 [ 765.069752] x5 : ffffd7c64b78cc30 x4 : 0000000000000000 x3 : 0000000000000000 [ 765.071983] x2 : 0000000000000001 x1 : ffff000805257820 x0 : 0000000000000880 [ 765.074221] Call trace: [ 765.075045] sve_save_state+0x4/0xf0 [ 765.076138] fpsimd_thread_switch+0x2c/0xe8 [ 765.077305] __switch_to+0x20/0x158 [ 765.078384] __schedule+0x2cc/0xb38 [ 765.079464] preempt_schedule_irq+0x44/0xa8 [ 765.080633] el1_interrupt+0x4c/0x68 [ 765.081691] el1h_64_irq_handler+0x18/0x28 [ 765.082829] el1h_64_irq+0x64/0x68 [ 765.083874] ftrace_return_to_handler+0x98/0x158 [ 765.085090] return_to_handler+0x20/0x48 [ 765.086205] do_sve_acc+0x64/0x128 [ 765.087272] el0_sve_acc+0x3c/0xa0 [ 765.088356] el0t_64_sync_handler+0x114/0x130 [ 765.089524] el0t_64_sync+0x190/0x198 [ 765.090712] Code: d51b4408 d65f03c0 d503201f d503245f (e5bb5800) [ 765.092024] ---[ end trace 0000000000000000 ]--- [ 765.904294] pstore: backend (efi_pstore) writing error (-5) [ 765.905531] note: rmmod[808] exited with irqs disabled Links: test log link: - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.5.y/build/v6.5.7… Details of tests: - https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/lkft/tests/2WrHwIIFdZ… Build link: - https://storage.tuxsuite.com/public/linaro/lkft/builds/2WrHvExYOOOZVoxlISTd… -- Linaro LKFT https://lkft.linaro.org

8 months, 3 weeks

6
12
0 0

[PATCH] thermal/drivers/mediatek: Fix control buffer enablement on MT7896

by Frank Wunderlich

From: Frank Wunderlich <frank-w(a)public-files.de> Reading thermal sensor on mt7986 devices returns invalid temperature: bpi-r3 ~ # cat /sys/class/thermal/thermal_zone0/temp -274000 Fix this by adding missing members in mtk_thermal_data struct which were used in mtk_thermal_turn_on_buffer after commit 33140e668b10. Cc: stable(a)vger.kernel.org Fixes: 33140e668b10 ("thermal/drivers/mediatek: Control buffer enablement tweaks") Signed-off-by: Frank Wunderlich <frank-w(a)public-files.de> --- drivers/thermal/mediatek/auxadc_thermal.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/thermal/mediatek/auxadc_thermal.c b/drivers/thermal/mediatek/auxadc_thermal.c index 843214d30bd8..967b9a1aead4 100644 --- a/drivers/thermal/mediatek/auxadc_thermal.c +++ b/drivers/thermal/mediatek/auxadc_thermal.c @@ -690,6 +690,9 @@ static const struct mtk_thermal_data mt7986_thermal_data = { .adcpnp = mt7986_adcpnp, .sensor_mux_values = mt7986_mux_values, .version = MTK_THERMAL_V3, + .apmixed_buffer_ctl_reg = APMIXED_SYS_TS_CON1, + .apmixed_buffer_ctl_mask = GENMASK(31, 6) | BIT(3), + .apmixed_buffer_ctl_set = BIT(0), }; static bool mtk_thermal_temp_is_valid(int temp) -- 2.34.1

8 months, 3 weeks

5
4
0 0

[PATCH v2] rpm-pkg: simplify installkernel %post

by Jose Ignacio Tornos Martinez

A new installkernel application is now included in systemd-udev package and it has been improved to allow simplifications. For the new installkernel application, as Davide says: <<The %post currently does a shuffling dance before calling installkernel. This isn't actually necessary afaict, and the current implementation ends up triggering downstream issues such as https://github.com/systemd/systemd/issues/29568 This commit simplifies the logic to remove the shuffling. For reference, the original logic was added in commit 3c9c7a14b627("rpm-pkg: add %post section to create initramfs and grub hooks").>> But we need to keep the old behavior as well, because the old installkernel application from grubby package, does not allow this simplification and we need to be backward compatible to avoid issues with the different packages. So the easiest solution is to check the package that provides the installkernel application, and simplify (and fix for this application at the same time), only if the package is systemd-udev. cc: stable(a)vger.kernel.org Co-Developed-by: Davide Cavalca <dcavalca(a)meta.com> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm(a)redhat.com> --- V1 -> V2: - Complete to be backward compatible with the previous installkernel application. scripts/package/kernel.spec | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/scripts/package/kernel.spec b/scripts/package/kernel.spec index 3eee0143e0c5..d4276ddb6645 100644 --- a/scripts/package/kernel.spec +++ b/scripts/package/kernel.spec @@ -77,12 +77,16 @@ rm -rf %{buildroot} %post if [ -x /sbin/installkernel -a -r /boot/vmlinuz-%{KERNELRELEASE} -a -r /boot/System.map-%{KERNELRELEASE} ]; then +if [ $(rpm -qf /sbin/installkernel --queryformat "%{n}") = systemd-udev ];then +/sbin/installkernel %{KERNELRELEASE} /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE} +else cp /boot/vmlinuz-%{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm cp /boot/System.map-%{KERNELRELEASE} /boot/.System.map-%{KERNELRELEASE}-rpm rm -f /boot/vmlinuz-%{KERNELRELEASE} /boot/System.map-%{KERNELRELEASE} /sbin/installkernel %{KERNELRELEASE} /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm rm -f /boot/.vmlinuz-%{KERNELRELEASE}-rpm /boot/.System.map-%{KERNELRELEASE}-rpm fi +fi %preun if [ -x /sbin/new-kernel-pkg ]; then -- 2.43.0

8 months, 3 weeks

3
24
0 0

[PATCH] arm64: dts: qcom: sc7280: Add additional MSI interrupts

by Krishna chaitanya chundru

Current MSI's mapping doesn't have all the vectors. This platform supports 8 vectors each vector supports 32 MSI's, so total MSI's supported is 256. Add all the MSI groups supported for this PCIe instance in this platform. Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related nodes") cc: stable(a)vger.kernel.org Signed-off-by: Krishna chaitanya chundru <quic_krichai(a)quicinc.com> --- arch/arm64/boot/dts/qcom/sc7280.dtsi | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index 66f1eb83cca7..e1dc41705f61 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -2146,8 +2146,16 @@ pcie1: pci@1c08000 { ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>, <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>; - interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "msi"; + interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi0", "msi1", "msi2", "msi3", + "msi4", "msi5", "msi6", "msi7"; #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0x7>; interrupt-map = <0 0 0 1 &intc 0 0 0 434 IRQ_TYPE_LEVEL_HIGH>, --- base-commit: 5bd7ef53ffe5ca580e93e74eb8c81ed191ddc4bd change-id: 20231218-additional_msi-6062dc812c29 Best regards, -- Krishna chaitanya chundru <quic_krichai(a)quicinc.com>

8 months, 3 weeks

2
1
0 0

[PATCH] drm/ttm: Make sure the mapped tt pages are decrypted when needed

by Zack Rusin

From: Zack Rusin <zackr(a)vmware.com> Some drivers require the mapped tt pages to be decrypted. In an ideal world this would have been handled by the dma layer, but the TTM page fault handling would have to be rewritten to able to do that. A side-effect of the TTM page fault handling is using a dma allocation per order (via ttm_pool_alloc_page) which makes it impossible to just trivially use dma_mmap_attrs. As a result ttm has to be very careful about trying to make its pgprot for the mapped tt pages match what the dma layer thinks it is. At the ttm layer it's possible to deduce the requirement to have tt pages decrypted by checking whether coherent dma allocations have been requested and the system is running with confidential computing technologies. This approach isn't ideal but keeping TTM matching DMAs expectations for the page properties is in general fragile, unfortunately proper fix would require a rewrite of TTM's page fault handling. Fixes vmwgfx with SEV enabled. Signed-off-by: Zack Rusin <zackr(a)vmware.com> Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem") Cc: Christian König <christian.koenig(a)amd.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Cc: <stable(a)vger.kernel.org> # v5.14+ --- drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +++++++++++-- drivers/gpu/drm/ttm/ttm_tt.c | 7 +++++++ include/drm/ttm/ttm_tt.h | 9 ++++++++- 3 files changed, 26 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index fd9fd3d15101..0b3f4267130c 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -294,7 +294,13 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct ttm_resource *res, enum ttm_caching caching; man = ttm_manager_type(bo->bdev, res->mem_type); - caching = man->use_tt ? bo->ttm->caching : res->bus.caching; + if (man->use_tt) { + caching = bo->ttm->caching; + if (bo->ttm->page_flags & TTM_TT_FLAG_DECRYPTED) + tmp = pgprot_decrypted(tmp); + } else { + caching = res->bus.caching; + } return ttm_prot_from_caching(caching, tmp); } @@ -337,6 +343,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo, .no_wait_gpu = false }; struct ttm_tt *ttm = bo->ttm; + struct ttm_resource_manager *man = + ttm_manager_type(bo->bdev, bo->resource->mem_type); pgprot_t prot; int ret; @@ -346,7 +354,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo, if (ret) return ret; - if (num_pages == 1 && ttm->caching == ttm_cached) { + if (num_pages == 1 && ttm->caching == ttm_cached && + !(man->use_tt && (ttm->page_flags & TTM_TT_FLAG_DECRYPTED))) { /* * We're mapping a single page, and the desired * page protection is consistent with the bo. diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c index e0a77671edd6..02dcb728e29c 100644 --- a/drivers/gpu/drm/ttm/ttm_tt.c +++ b/drivers/gpu/drm/ttm/ttm_tt.c @@ -81,6 +81,13 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc) pr_err("Illegal buffer object type\n"); return -EINVAL; } + /* + * When using dma_alloc_coherent with memory encryption the + * mapped TT pages need to be decrypted or otherwise the drivers + * will end up sending encrypted mem to the gpu. + */ + if (bdev->pool.use_dma_alloc && cc_platform_has(CC_ATTR_MEM_ENCRYPT)) + page_flags |= TTM_TT_FLAG_DECRYPTED; bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags); if (unlikely(bo->ttm == NULL)) diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h index a4eff85b1f44..2b9d856ff388 100644 --- a/include/drm/ttm/ttm_tt.h +++ b/include/drm/ttm/ttm_tt.h @@ -79,6 +79,12 @@ struct ttm_tt { * page_flags = TTM_TT_FLAG_EXTERNAL | * TTM_TT_FLAG_EXTERNAL_MAPPABLE; * + * TTM_TT_FLAG_DECRYPTED: The mapped ttm pages should be marked as + * not encrypted. The framework will try to match what the dma layer + * is doing, but note that it is a little fragile because ttm page + * fault handling abuses the DMA api a bit and dma_map_attrs can't be + * used to assure pgprot always matches. + * * TTM_TT_FLAG_PRIV_POPULATED: TTM internal only. DO NOT USE. This is * set by TTM after ttm_tt_populate() has successfully returned, and is * then unset when TTM calls ttm_tt_unpopulate(). @@ -87,8 +93,9 @@ struct ttm_tt { #define TTM_TT_FLAG_ZERO_ALLOC BIT(1) #define TTM_TT_FLAG_EXTERNAL BIT(2) #define TTM_TT_FLAG_EXTERNAL_MAPPABLE BIT(3) +#define TTM_TT_FLAG_DECRYPTED BIT(4) -#define TTM_TT_FLAG_PRIV_POPULATED BIT(4) +#define TTM_TT_FLAG_PRIV_POPULATED BIT(5) uint32_t page_flags; /** @num_pages: Number of pages in the page array. */ uint32_t num_pages; -- 2.39.2

8 months, 3 weeks

6
10
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023