February 2020 - Linux-stable-mirror

[RHEL 8.2 PATCH] KVM: PPC: Book3S HV: XIVE: Ensure VP isn't already in use

by Daniel Henrique Barboza

From: Greg Kurz <groug(a)kaod.org> Bugzilla: 804424 Brew: 26599344 Upstream: Yes Tested: sanity tests in a Power 8 host Conflicts: none Connecting a vCPU to a XIVE KVM device means establishing a 1:1 association between a vCPU id and the offset (VP id) of a VP structure within a fixed size block of VPs. We currently try to enforce the 1:1 relationship by checking that a vCPU with the same id isn't already connected. This is good but unfortunately not enough because we don't map VP ids to raw vCPU ids but to packed vCPU ids, and the packing function kvmppc_pack_vcpu_id() isn't bijective by design. We got away with it because QEMU passes vCPU ids that fit well in the packing pattern. But nothing prevents userspace to come up with a forged vCPU id resulting in a packed id collision which causes the KVM device to associate two vCPUs to the same VP. This greatly confuses the irq layer and ultimately crashes the kernel, as shown below. Example: a guest with 1 guest thread per core, a core stride of 8 and 300 vCPUs has vCPU ids 0,8,16...2392. If QEMU is patched to inject at some point an invalid vCPU id 348, which is the packed version of itself and 2392, we get: genirq: Flags mismatch irq 199. 00010000 (kvm-2-2392) vs. 00010000 (kvm-2-348) CPU: 24 PID: 88176 Comm: qemu-system-ppc Not tainted 5.3.0-xive-nr-servers-5.3-gku+ #38 Call Trace: [c000003f7f9937e0] [c000000000c0110c] dump_stack+0xb0/0xf4 (unreliable) [c000003f7f993820] [c0000000001cb480] __setup_irq+0xa70/0xad0 [c000003f7f9938d0] [c0000000001cb75c] request_threaded_irq+0x13c/0x260 [c000003f7f993940] [c00800000d44e7ac] kvmppc_xive_attach_escalation+0x104/0x270 [kvm] [c000003f7f9939d0] [c00800000d45013c] kvmppc_xive_connect_vcpu+0x424/0x620 [kvm] [c000003f7f993ac0] [c00800000d444428] kvm_arch_vcpu_ioctl+0x260/0x448 [kvm] [c000003f7f993b90] [c00800000d43593c] kvm_vcpu_ioctl+0x154/0x7c8 [kvm] [c000003f7f993d00] [c0000000004840f0] do_vfs_ioctl+0xe0/0xc30 [c000003f7f993db0] [c000000000484d44] ksys_ioctl+0x104/0x120 [c000003f7f993e00] [c000000000484d88] sys_ioctl+0x28/0x80 [c000003f7f993e20] [c00000000000b278] system_call+0x5c/0x68 xive-kvm: Failed to request escalation interrupt for queue 0 of VCPU 2392 ------------[ cut here ]------------ remove_proc_entry: removing non-empty directory 'irq/199', leaking at least 'kvm-2-348' WARNING: CPU: 24 PID: 88176 at /home/greg/Work/linux/kernel-kvm-ppc/fs/proc/generic.c:684 remove_proc_entry+0x1ec/0x200 Modules linked in: kvm_hv kvm dm_mod vhost_net vhost tap xt_CHECKSUM iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter squashfs loop fuse i2c_dev sg ofpart ocxl powernv_flash at24 xts mtd uio_pdrv_genirq vmx_crypto opal_prd ipmi_powernv uio ipmi_devintf ipmi_msghandler ibmpowernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables ext4 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq libcrc32c raid1 raid0 linear sd_mod ast i2c_algo_bit drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci libata tg3 drm_panel_orientation_quirks [last unloaded: kvm] CPU: 24 PID: 88176 Comm: qemu-system-ppc Not tainted 5.3.0-xive-nr-servers-5.3-gku+ #38 NIP: c00000000053b0cc LR: c00000000053b0c8 CTR: c0000000000ba3b0 REGS: c000003f7f9934b0 TRAP: 0700 Not tainted (5.3.0-xive-nr-servers-5.3-gku+) MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 48228222 XER: 20040000 CFAR: c000000000131a50 IRQMASK: 0 GPR00: c00000000053b0c8 c000003f7f993740 c0000000015ec500 0000000000000057 GPR04: 0000000000000001 0000000000000000 000049fb98484262 0000000000001bcf GPR08: 0000000000000007 0000000000000007 0000000000000001 9000000000001033 GPR12: 0000000000008000 c000003ffffeb800 0000000000000000 000000012f4ce5a1 GPR16: 000000012ef5a0c8 0000000000000000 000000012f113bb0 0000000000000000 GPR20: 000000012f45d918 c000003f863758b0 c000003f86375870 0000000000000006 GPR24: c000003f86375a30 0000000000000007 c0002039373d9020 c0000000014c4a48 GPR28: 0000000000000001 c000003fe62a4f6b c00020394b2e9fab c000003fe62a4ec0 NIP [c00000000053b0cc] remove_proc_entry+0x1ec/0x200 LR [c00000000053b0c8] remove_proc_entry+0x1e8/0x200 Call Trace: [c000003f7f993740] [c00000000053b0c8] remove_proc_entry+0x1e8/0x200 (unreliable) [c000003f7f9937e0] [c0000000001d3654] unregister_irq_proc+0x114/0x150 [c000003f7f993880] [c0000000001c6284] free_desc+0x54/0xb0 [c000003f7f9938c0] [c0000000001c65ec] irq_free_descs+0xac/0x100 [c000003f7f993910] [c0000000001d1ff8] irq_dispose_mapping+0x68/0x80 [c000003f7f993940] [c00800000d44e8a4] kvmppc_xive_attach_escalation+0x1fc/0x270 [kvm] [c000003f7f9939d0] [c00800000d45013c] kvmppc_xive_connect_vcpu+0x424/0x620 [kvm] [c000003f7f993ac0] [c00800000d444428] kvm_arch_vcpu_ioctl+0x260/0x448 [kvm] [c000003f7f993b90] [c00800000d43593c] kvm_vcpu_ioctl+0x154/0x7c8 [kvm] [c000003f7f993d00] [c0000000004840f0] do_vfs_ioctl+0xe0/0xc30 [c000003f7f993db0] [c000000000484d44] ksys_ioctl+0x104/0x120 [c000003f7f993e00] [c000000000484d88] sys_ioctl+0x28/0x80 [c000003f7f993e20] [c00000000000b278] system_call+0x5c/0x68 Instruction dump: 2c230000 41820008 3923ff78 e8e900a0 3c82ff69 3c62ff8d 7fa6eb78 7fc5f378 3884f080 3863b948 4bbf6925 60000000 <0fe00000> 4bffff7c fba10088 4bbf6e41 ---[ end trace b925b67a74a1d8d1 ]--- BUG: Kernel NULL pointer dereference at 0x00000010 Faulting instruction address: 0xc00800000d44fc04 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: kvm_hv kvm dm_mod vhost_net vhost tap xt_CHECKSUM iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter squashfs loop fuse i2c_dev sg ofpart ocxl powernv_flash at24 xts mtd uio_pdrv_genirq vmx_crypto opal_prd ipmi_powernv uio ipmi_devintf ipmi_msghandler ibmpowernv ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip_tables ext4 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq libcrc32c raid1 raid0 linear sd_mod ast i2c_algo_bit drm_vram_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm ahci libahci libata tg3 drm_panel_orientation_quirks [last unloaded: kvm] CPU: 24 PID: 88176 Comm: qemu-system-ppc Tainted: G W 5.3.0-xive-nr-servers-5.3-gku+ #38 NIP: c00800000d44fc04 LR: c00800000d44fc00 CTR: c0000000001cd970 REGS: c000003f7f9938e0 TRAP: 0300 Tainted: G W (5.3.0-xive-nr-servers-5.3-gku+) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24228882 XER: 20040000 CFAR: c0000000001cd9ac DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c00800000d44fc00 c000003f7f993b70 c00800000d468300 0000000000000000 GPR04: 00000000000000c7 0000000000000000 0000000000000000 c000003ffacd06d8 GPR08: 0000000000000000 c000003ffacd0738 0000000000000000 fffffffffffffffd GPR12: 0000000000000040 c000003ffffeb800 0000000000000000 000000012f4ce5a1 GPR16: 000000012ef5a0c8 0000000000000000 000000012f113bb0 0000000000000000 GPR20: 000000012f45d918 00007ffffe0d9a80 000000012f4f5df0 000000012ef8c9f8 GPR24: 0000000000000001 0000000000000000 c000003fe4501ed0 c000003f8b1d0000 GPR28: c0000033314689c0 c000003fe4501c00 c000003fe4501e70 c000003fe4501e90 NIP [c00800000d44fc04] kvmppc_xive_cleanup_vcpu+0xfc/0x210 [kvm] LR [c00800000d44fc00] kvmppc_xive_cleanup_vcpu+0xf8/0x210 [kvm] Call Trace: [c000003f7f993b70] [c00800000d44fc00] kvmppc_xive_cleanup_vcpu+0xf8/0x210 [kvm] (unreliable) [c000003f7f993bd0] [c00800000d450bd4] kvmppc_xive_release+0xdc/0x1b0 [kvm] [c000003f7f993c30] [c00800000d436a98] kvm_device_release+0xb0/0x110 [kvm] [c000003f7f993c70] [c00000000046730c] __fput+0xec/0x320 [c000003f7f993cd0] [c000000000164ae0] task_work_run+0x150/0x1c0 [c000003f7f993d30] [c000000000025034] do_notify_resume+0x304/0x440 [c000003f7f993e20] [c00000000000dcc4] ret_from_except_lite+0x70/0x74 Instruction dump: 3bff0008 7fbfd040 419e0054 847e0004 2fa30000 419effec e93d0000 8929203c 2f890000 419effb8 4800821d e8410018 <e9230010> e9490008 9b2a0039 7c0004ac ---[ end trace b925b67a74a1d8d2 ]--- Kernel panic - not syncing: Fatal exception This affects both XIVE and XICS-on-XIVE devices since the beginning. Check the VP id instead of the vCPU id when a new vCPU is connected. The allocation of the XIVE CPU structure in kvmppc_xive_connect_vcpu() is moved after the check to avoid the need for rollback. Cc: stable(a)vger.kernel.org # v4.12+ (cherry-picked from ) Signed-off-by: Greg Kurz <groug(a)kaod.org> Reviewed-by: Cédric Le Goater <clg(a)kaod.org> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> (cherry picked from commit 12ade69c1eb9958b13374edf5ef742ea20ccffde) Signed-off-by: Daniel Henrique Barboza <dbarboza(a)redhat.com> --- arch/powerpc/kvm/book3s_xive.c | 24 ++++++++++++++++-------- arch/powerpc/kvm/book3s_xive.h | 12 ++++++++++++ arch/powerpc/kvm/book3s_xive_native.c | 6 ++++-- 3 files changed, 32 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c index 42c4d9c2d39a..b33e9246c49f 100644 --- a/arch/powerpc/kvm/book3s_xive.c +++ b/arch/powerpc/kvm/book3s_xive.c @@ -1178,6 +1178,7 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev, struct kvmppc_xive *xive = dev->private; struct kvmppc_xive_vcpu *xc; int i, r = -EBUSY; + u32 vp_id; pr_devel("connect_vcpu(cpu=%d)\n", cpu); @@ -1189,25 +1190,32 @@ int kvmppc_xive_connect_vcpu(struct kvm_device *dev, return -EPERM; if (vcpu->arch.irq_type != KVMPPC_IRQ_DEFAULT) return -EBUSY; - if (kvmppc_xive_find_server(vcpu->kvm, cpu)) { - pr_devel("Duplicate !\n"); - return -EEXIST; - } if (cpu >= (KVM_MAX_VCPUS * vcpu->kvm->arch.emul_smt_mode)) { pr_devel("Out of bounds !\n"); return -EINVAL; } - xc = kzalloc(sizeof(*xc), GFP_KERNEL); - if (!xc) - return -ENOMEM; /* We need to synchronize with queue provisioning */ mutex_lock(&xive->lock); + + vp_id = kvmppc_xive_vp(xive, cpu); + if (kvmppc_xive_vp_in_use(xive->kvm, vp_id)) { + pr_devel("Duplicate !\n"); + r = -EEXIST; + goto bail; + } + + xc = kzalloc(sizeof(*xc), GFP_KERNEL); + if (!xc) { + r = -ENOMEM; + goto bail; + } + vcpu->arch.xive_vcpu = xc; xc->xive = xive; xc->vcpu = vcpu; xc->server_num = cpu; - xc->vp_id = kvmppc_xive_vp(xive, cpu); + xc->vp_id = vp_id; xc->mfrr = 0xff; xc->valid = true; diff --git a/arch/powerpc/kvm/book3s_xive.h b/arch/powerpc/kvm/book3s_xive.h index 862c2c9650ae..fbad38d3523c 100644 --- a/arch/powerpc/kvm/book3s_xive.h +++ b/arch/powerpc/kvm/book3s_xive.h @@ -223,6 +223,18 @@ static inline u32 kvmppc_xive_vp(struct kvmppc_xive *xive, u32 server) return xive->vp_base + kvmppc_pack_vcpu_id(xive->kvm, server); } +static inline bool kvmppc_xive_vp_in_use(struct kvm *kvm, u32 vp_id) +{ + struct kvm_vcpu *vcpu = NULL; + int i; + + kvm_for_each_vcpu(i, vcpu, kvm) { + if (vcpu->arch.xive_vcpu && vp_id == vcpu->arch.xive_vcpu->vp_id) + return true; + } + return false; +} + /* * Mapping between guest priorities and host priorities * is as follow. diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c index 74a3a1c8ee47..8a5b9e61092e 100644 --- a/arch/powerpc/kvm/book3s_xive_native.c +++ b/arch/powerpc/kvm/book3s_xive_native.c @@ -116,6 +116,7 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev, struct kvmppc_xive *xive = dev->private; struct kvmppc_xive_vcpu *xc = NULL; int rc; + u32 vp_id; pr_devel("native_connect_vcpu(server=%d)\n", server_num); @@ -134,7 +135,8 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev, mutex_lock(&xive->lock); - if (kvmppc_xive_find_server(vcpu->kvm, server_num)) { + vp_id = kvmppc_xive_vp(xive, server_num); + if (kvmppc_xive_vp_in_use(xive->kvm, vp_id)) { pr_devel("Duplicate !\n"); rc = -EEXIST; goto bail; @@ -151,7 +153,7 @@ int kvmppc_xive_native_connect_vcpu(struct kvm_device *dev, xc->vcpu = vcpu; xc->server_num = server_num; - xc->vp_id = kvmppc_xive_vp(xive, server_num); + xc->vp_id = vp_id; xc->valid = true; vcpu->arch.irq_type = KVMPPC_IRQ_XIVE; -- 2.18.2

4 years, 8 months

2
1
0 0

[PATCH] ALSA: hda/realtek - Fix a regression for mute led on Lenovo Carbon X1

by Hui Wang

Need to chain the THINKPAD_ACPI, otherwise the mute led will not work. Fixes: d2cd795c4ece ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen") Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 477589e7ec1d..31bee0512334 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6684,6 +6684,8 @@ static const struct hda_fixup alc269_fixups[] = { [ALC285_FIXUP_SPEAKER2_TO_DAC1] = { .type = HDA_FIXUP_FUNC, .v.func = alc285_fixup_speaker2_to_dac1, + .chained = true, + .chain_id = ALC269_FIXUP_THINKPAD_ACPI }, [ALC256_FIXUP_DELL_INSPIRON_7559_SUBWOOFER] = { .type = HDA_FIXUP_PINS, -- 2.17.1

4 years, 8 months

2
1
0 0

❌ FAIL: Test report for kernel 5.4.21-rc1-0b36b76.cki (stable)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 0b36b7661751 - Linux 5.4.21-rc1 The results of these automated tests are provided below. Overall result: FAILED (see details below) Merge: OK Compile: OK Tests: FAILED All kernel binaries, config files, and logs are available for download here: https://cki-artifacts.s3.us-east-2.amazonaws.com/index.html?prefix=dataware… One or more kernel tests failed: ppc64le: ❌ LTP We hope that these logs can help you find the problem quickly. For the full detail on our testing procedures, please scroll to the bottom of this message. Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg ppc64le: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg x86_64: make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: Host 1: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ Storage blktests Host 2: ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm - DaCapo Benchmark Suite 🚧 ✅ jvm - jcstress tests 🚧 ✅ Memory function: kaslr 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common ppc64le: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ⚡⚡⚡ LTP ⚡⚡⚡ Loopdev Sanity ⚡⚡⚡ Memory function: memfd_create ⚡⚡⚡ AMTU (Abstract Machine Test Utility) ⚡⚡⚡ Networking bridge: sanity ⚡⚡⚡ Ethernet drivers sanity ⚡⚡⚡ Networking MACsec: sanity ⚡⚡⚡ Networking socket: fuzz ⚡⚡⚡ Networking sctp-auth: sockopts test ⚡⚡⚡ Networking route: pmtu ⚡⚡⚡ Networking route_func - local ⚡⚡⚡ Networking route_func - forward ⚡⚡⚡ Networking TCP: keepalive test ⚡⚡⚡ Networking UDP: socket ⚡⚡⚡ Networking tunnel: geneve basic test ⚡⚡⚡ Networking tunnel: gre basic ⚡⚡⚡ L2TP basic test ⚡⚡⚡ Networking tunnel: vxlan basic ⚡⚡⚡ Networking ipsec: basic netns - tunnel ⚡⚡⚡ audit: audit testsuite test ⚡⚡⚡ httpd: mod_ssl smoke sanity ⚡⚡⚡ tuned: tune-processes-through-perf ⚡⚡⚡ ALSA PCM loopback test ⚡⚡⚡ ALSA Control (mixer) Userspace Element test ⚡⚡⚡ trace: ftrace/tracer 🚧 ⚡⚡⚡ CIFS Connectathon 🚧 ⚡⚡⚡ POSIX pjd-fstest suites 🚧 ⚡⚡⚡ jvm - DaCapo Benchmark Suite 🚧 ⚡⚡⚡ jvm - jcstress tests 🚧 ⚡⚡⚡ Memory function: kaslr 🚧 ⚡⚡⚡ LTP: openposix test suite 🚧 ⚡⚡⚡ Networking vnic: ipvlan/basic 🚧 ⚡⚡⚡ iotop: sanity 🚧 ⚡⚡⚡ Usex - version 1.9-29 🚧 ⚡⚡⚡ storage: dm/common Host 2: ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ✅ Storage blktests Host 3: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ⚡⚡⚡ Podman system integration test - as root ⚡⚡⚡ Podman system integration test - as user ❌ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm - DaCapo Benchmark Suite 🚧 ✅ jvm - jcstress tests 🚧 ✅ Memory function: kaslr 🚧 ✅ LTP: openposix test suite 🚧 ✅ Networking vnic: ipvlan/basic 🚧 ✅ iotop: sanity 🚧 ✅ Usex - version 1.9-29 🚧 ✅ storage: dm/common x86_64: Host 1: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ Podman system integration test - as root ✅ Podman system integration test - as user ✅ LTP ✅ Loopdev Sanity ✅ Memory function: memfd_create ✅ AMTU (Abstract Machine Test Utility) ✅ Networking bridge: sanity ✅ Ethernet drivers sanity ✅ Networking MACsec: sanity ✅ Networking socket: fuzz ✅ Networking sctp-auth: sockopts test ✅ Networking: igmp conformance test ✅ Networking route: pmtu ✅ Networking route_func - local ✅ Networking route_func - forward ✅ Networking TCP: keepalive test ✅ Networking UDP: socket ✅ Networking tunnel: geneve basic test ✅ Networking tunnel: gre basic ✅ L2TP basic test ✅ Networking tunnel: vxlan basic ✅ Networking ipsec: basic netns - transport ✅ Networking ipsec: basic netns - tunnel ✅ audit: audit testsuite test ✅ httpd: mod_ssl smoke sanity ✅ tuned: tune-processes-through-perf ✅ pciutils: sanity smoke test ✅ ALSA PCM loopback test ✅ ALSA Control (mixer) Userspace Element test ✅ storage: SCSI VPD ✅ trace: ftrace/tracer 🚧 ✅ CIFS Connectathon 🚧 ✅ POSIX pjd-fstest suites 🚧 ✅ jvm - DaCapo Benchmark Suite 🚧 ⚡⚡⚡ jvm - jcstress tests 🚧 ⚡⚡⚡ Memory function: kaslr 🚧 ⚡⚡⚡ LTP: openposix test suite 🚧 ⚡⚡⚡ Networking vnic: ipvlan/basic 🚧 ⚡⚡⚡ iotop: sanity 🚧 ⚡⚡⚡ Usex - version 1.9-29 🚧 ⚡⚡⚡ storage: dm/common Host 2: ✅ Boot test ✅ Storage SAN device stress - mpt3sas driver Host 3: ⚡ Internal infrastructure issues prevented one or more tests (marked with ⚡⚡⚡) from running on this architecture. This is not the fault of the kernel that was tested. ✅ Boot test ✅ xfstests - ext4 ✅ xfstests - xfs ✅ selinux-policy: serge-testsuite ✅ lvm thinp sanity ✅ storage: software RAID testing ✅ stress: stress-ng 🚧 ✅ IOMMU boot test 🚧 ✅ IPMI driver test 🚧 ✅ IPMItool loop stress test 🚧 ⚡⚡⚡ Storage blktests Host 4: ✅ Boot test ✅ Storage SAN device stress - megaraid_sas Test sources: https://github.com/CKI-project/tests-beaker 💚 Pull requests are welcome for new tests or improvements to existing tests! Waived tests ------------ If the test run included waived tests, they are marked with 🚧. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed. Testing timeout --------------- We aim to provide a report within reasonable timeframe. Tests that haven't finished running yet are marked with ⏱.

4 years, 8 months

1
0
0 0

Re: [PATCH 1/3] ext4: introduce macro sbi_array_rcu_deref() to access rcu protected fields

by Jitindar SIngh, Suraj

+Cc stable (correctly this time) On Tue, 2020-02-18 at 19:08 -0800, Suraj Jitindar Singh wrote: > The s_group_desc field in the super block info (sbi) is protected by > rcu to > prevent access to an invalid pointer during online resize operations. > There are 2 other arrays in sbi, s_group_info and s_flex_groups, > which > require similar rcu protection which is introduced in the subsequent > patches. Introduce a helper macro sbi_array_rcu_deref() to be used to > provide rcu protected access to such fields. > > Also update the current s_group_desc access site to use the macro. > > Signed-off-by: Suraj Jitindar Singh <surajjs(a)amazon.com> Cc: stable(a)vger.kernel.org > Cc: stable(a)vger-kernel.org > --- > fs/ext4/balloc.c | 11 +++++------ > fs/ext4/ext4.h | 17 +++++++++++++++++ > 2 files changed, 22 insertions(+), 6 deletions(-) > > diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c > index 5368bf67300b..8fd0b3cdab4c 100644 > --- a/fs/ext4/balloc.c > +++ b/fs/ext4/balloc.c > @@ -281,14 +281,13 @@ struct ext4_group_desc * > ext4_get_group_desc(struct super_block *sb, > > group_desc = block_group >> EXT4_DESC_PER_BLOCK_BITS(sb); > offset = block_group & (EXT4_DESC_PER_BLOCK(sb) - 1); > - rcu_read_lock(); > - bh_p = rcu_dereference(sbi->s_group_desc)[group_desc]; > + bh_p = sbi_array_rcu_deref(sbi, s_group_desc, group_desc); > /* > - * We can unlock here since the pointer being dereferenced > won't be > - * dereferenced again. By looking at the usage in add_new_gdb() > the > - * value isn't modified, just the pointer, and so it remains > valid. > + * sbi_array_rcu_deref returns with rcu unlocked, this is ok > since > + * the pointer being dereferenced won't be dereferenced again. > By > + * looking at the usage in add_new_gdb() the value isn't > modified, > + * just the pointer, and so it remains valid. > */ > - rcu_read_unlock(); > if (!bh_p) { > ext4_error(sb, "Group descriptor not loaded - " > "block_group = %u, group_desc = %u, desc = > %u", > diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h > index 149ee0ab6d64..236fc6500340 100644 > --- a/fs/ext4/ext4.h > +++ b/fs/ext4/ext4.h > @@ -1576,6 +1576,23 @@ static inline int ext4_valid_inum(struct > super_block *sb, unsigned long ino) > ino <= le32_to_cpu(EXT4_SB(sb)->s_es- > >s_inodes_count)); > } > > +/* > + * Returns: sbi->field[index] > + * Used to access an array element from the following sbi fields > which require > + * rcu protection to avoid dereferencing an invalid pointer due to > reassignment > + * - s_group_desc > + * - s_group_info > + * - s_flex_group > + */ > +#define sbi_array_rcu_deref(sbi, field, index) > \ > +({ > \ > + typeof(*((sbi)->field)) _v; > \ > + rcu_read_lock(); \ > + _v = ((typeof((sbi)->field))rcu_dereference((sbi)- > >field))[index]; \ > + rcu_read_unlock(); > \ > + _v; > \ > +}) > + > /* > * Simulate_fail codes > */

4 years, 8 months

1
0
0 0

[PATCH 3/3] ext4: fix potential race between s_flex_groups online resizing and access

by Suraj Jitindar Singh

During an online resize an array of s_flex_groups structures gets replaced so it can get enlarged. If there is a concurrent access to the array and this memory has been reused then this can lead to an invalid memory access. The s_flex_group array has been converted into an array of pointers rather than an array of structures. This is to ensure that the information contained in the structures cannot get out of sync during a resize due to an accessor updating the value in the old structure after it has been copied but before the array pointer is updated. Since the structures them- selves are no longer copied but only the pointers to them this case is mitigated. Link: https://bugzilla.kernel.org/show_bug.cgi?id=206443 Signed-off-by: Suraj Jitindar Singh <surajjs(a)amazon.com> Cc: stable(a)vger.kernel.org --- fs/ext4/ext4.h | 2 +- fs/ext4/ialloc.c | 21 +++++++++++------- fs/ext4/mballoc.c | 9 +++++--- fs/ext4/resize.c | 4 ++-- fs/ext4/super.c | 56 ++++++++++++++++++++++++++++++++--------------- 5 files changed, 60 insertions(+), 32 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 3f4aaaae7da6..e8157ce5988b 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1512,7 +1512,7 @@ struct ext4_sb_info { unsigned int s_extent_max_zeroout_kb; unsigned int s_log_groups_per_flex; - struct flex_groups *s_flex_groups; + struct flex_groups **s_flex_groups; ext4_group_t s_flex_groups_allocated; /* workqueue for reserved extent conversions (buffered io) */ diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index c66e8f9451a2..9324552a2ac2 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -330,9 +330,11 @@ void ext4_free_inode(handle_t *handle, struct inode *inode) if (sbi->s_log_groups_per_flex) { ext4_group_t f = ext4_flex_group(sbi, block_group); - atomic_inc(&sbi->s_flex_groups[f].free_inodes); + atomic_inc(&sbi_array_rcu_deref(sbi, s_flex_groups, + f)->free_inodes); if (is_directory) - atomic_dec(&sbi->s_flex_groups[f].used_dirs); + atomic_dec(&sbi_array_rcu_deref(sbi, s_flex_groups, + f)->used_dirs); } BUFFER_TRACE(bh2, "call ext4_handle_dirty_metadata"); fatal = ext4_handle_dirty_metadata(handle, NULL, bh2); @@ -368,12 +370,13 @@ static void get_orlov_stats(struct super_block *sb, ext4_group_t g, int flex_size, struct orlov_stats *stats) { struct ext4_group_desc *desc; - struct flex_groups *flex_group = EXT4_SB(sb)->s_flex_groups; + struct flex_groups *flex_group = sbi_array_rcu_deref(EXT4_SB(sb), + s_flex_groups, g); if (flex_size > 1) { - stats->free_inodes = atomic_read(&flex_group[g].free_inodes); - stats->free_clusters = atomic64_read(&flex_group[g].free_clusters); - stats->used_dirs = atomic_read(&flex_group[g].used_dirs); + stats->free_inodes = atomic_read(&flex_group->free_inodes); + stats->free_clusters = atomic64_read(&flex_group->free_clusters); + stats->used_dirs = atomic_read(&flex_group->used_dirs); return; } @@ -1054,7 +1057,8 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir, if (sbi->s_log_groups_per_flex) { ext4_group_t f = ext4_flex_group(sbi, group); - atomic_inc(&sbi->s_flex_groups[f].used_dirs); + atomic_inc(&sbi_array_rcu_deref(sbi, s_flex_groups, + f)->used_dirs); } } if (ext4_has_group_desc_csum(sb)) { @@ -1077,7 +1081,8 @@ struct inode *__ext4_new_inode(handle_t *handle, struct inode *dir, if (sbi->s_log_groups_per_flex) { flex_group = ext4_flex_group(sbi, group); - atomic_dec(&sbi->s_flex_groups[flex_group].free_inodes); + atomic_dec(&sbi_array_rcu_deref(sbi, s_flex_groups, + flex_group)->free_inodes); } inode->i_ino = ino + group * EXT4_INODES_PER_GROUP(sb); diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 0d9b17afc85f..0de1191e12a8 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -3022,7 +3022,8 @@ ext4_mb_mark_diskspace_used(struct ext4_allocation_context *ac, ext4_group_t flex_group = ext4_flex_group(sbi, ac->ac_b_ex.fe_group); atomic64_sub(ac->ac_b_ex.fe_len, - &sbi->s_flex_groups[flex_group].free_clusters); + &sbi_array_rcu_deref(sbi, s_flex_groups, + flex_group)->free_clusters); } err = ext4_handle_dirty_metadata(handle, NULL, bitmap_bh); @@ -4920,7 +4921,8 @@ void ext4_free_blocks(handle_t *handle, struct inode *inode, if (sbi->s_log_groups_per_flex) { ext4_group_t flex_group = ext4_flex_group(sbi, block_group); atomic64_add(count_clusters, - &sbi->s_flex_groups[flex_group].free_clusters); + &sbi_array_rcu_deref(sbi, s_flex_groups, + flex_group)->free_clusters); } /* @@ -5077,7 +5079,8 @@ int ext4_group_add_blocks(handle_t *handle, struct super_block *sb, if (sbi->s_log_groups_per_flex) { ext4_group_t flex_group = ext4_flex_group(sbi, block_group); atomic64_add(clusters_freed, - &sbi->s_flex_groups[flex_group].free_clusters); + &sbi_array_rcu_deref(sbi, s_flex_groups, + flex_group)->free_clusters); } ext4_mb_unload_buddy(&e4b); diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index 6fbe8607095f..941941a629a3 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1427,9 +1427,9 @@ static void ext4_update_super(struct super_block *sb, ext4_group_t flex_group; flex_group = ext4_flex_group(sbi, group_data[0].group); atomic64_add(EXT4_NUM_B2C(sbi, free_blocks), - &sbi->s_flex_groups[flex_group].free_clusters); + &sbi->s_flex_groups[flex_group]->free_clusters); atomic_add(EXT4_INODES_PER_GROUP(sb) * flex_gd->count, - &sbi->s_flex_groups[flex_group].free_inodes); + &sbi->s_flex_groups[flex_group]->free_inodes); } /* diff --git a/fs/ext4/super.c b/fs/ext4/super.c index f464dff09774..3a401f930bca 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1049,7 +1049,11 @@ static void ext4_put_super(struct super_block *sb) for (i = 0; i < sbi->s_gdb_count; i++) brelse(sbi->s_group_desc[i]); kvfree(sbi->s_group_desc); - kvfree(sbi->s_flex_groups); + if (sbi->s_flex_groups) { + for (i = 0; i < sbi->s_flex_groups_allocated; i++) + kvfree(sbi->s_flex_groups[i]); + kvfree(sbi->s_flex_groups); + } percpu_counter_destroy(&sbi->s_freeclusters_counter); percpu_counter_destroy(&sbi->s_freeinodes_counter); percpu_counter_destroy(&sbi->s_dirs_counter); @@ -2380,8 +2384,8 @@ static int ext4_setup_super(struct super_block *sb, struct ext4_super_block *es, int ext4_alloc_flex_bg_array(struct super_block *sb, ext4_group_t ngroup) { struct ext4_sb_info *sbi = EXT4_SB(sb); - struct flex_groups *new_groups; - int size; + struct flex_groups **old_groups, **new_groups; + int size, i; if (!sbi->s_log_groups_per_flex) return 0; @@ -2390,22 +2394,35 @@ int ext4_alloc_flex_bg_array(struct super_block *sb, ext4_group_t ngroup) if (size <= sbi->s_flex_groups_allocated) return 0; - size = roundup_pow_of_two(size * sizeof(struct flex_groups)); - new_groups = kvzalloc(size, GFP_KERNEL); + new_groups = kvzalloc(roundup_pow_of_two(size * + sizeof(*sbi->s_flex_groups)), GFP_KERNEL); if (!new_groups) { - ext4_msg(sb, KERN_ERR, "not enough memory for %d flex groups", - size / (int) sizeof(struct flex_groups)); + ext4_msg(sb, KERN_ERR, + "not enough memory for %d flex group pointers", size); return -ENOMEM; } - - if (sbi->s_flex_groups) { + for (i = sbi->s_flex_groups_allocated; i < size; i++) { + new_groups[i] = kvzalloc(roundup_pow_of_two( + sizeof(struct flex_groups)), + GFP_KERNEL); + if (!new_groups[i]) { + for (i--; i >= sbi->s_flex_groups_allocated; i--) + kvfree(new_groups[i]); + kvfree(new_groups); + ext4_msg(sb, KERN_ERR, + "not enough memory for %d flex groups", size); + return -ENOMEM; + } + } + old_groups = sbi->s_flex_groups; + if (sbi->s_flex_groups) memcpy(new_groups, sbi->s_flex_groups, (sbi->s_flex_groups_allocated * - sizeof(struct flex_groups))); - kvfree(sbi->s_flex_groups); - } - sbi->s_flex_groups = new_groups; - sbi->s_flex_groups_allocated = size / sizeof(struct flex_groups); + sizeof(struct flex_groups *))); + rcu_assign_pointer(sbi->s_flex_groups, new_groups); + sbi->s_flex_groups_allocated = size; + if (old_groups) + ext4_kvfree_array_rcu(old_groups); return 0; } @@ -2431,11 +2448,11 @@ static int ext4_fill_flex_info(struct super_block *sb) flex_group = ext4_flex_group(sbi, i); atomic_add(ext4_free_inodes_count(sb, gdp), - &sbi->s_flex_groups[flex_group].free_inodes); + &sbi->s_flex_groups[flex_group]->free_inodes); atomic64_add(ext4_free_group_clusters(sb, gdp), - &sbi->s_flex_groups[flex_group].free_clusters); + &sbi->s_flex_groups[flex_group]->free_clusters); atomic_add(ext4_used_dirs_count(sb, gdp), - &sbi->s_flex_groups[flex_group].used_dirs); + &sbi->s_flex_groups[flex_group]->used_dirs); } return 1; @@ -4682,8 +4699,11 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) ext4_unregister_li_request(sb); failed_mount6: ext4_mb_release(sb); - if (sbi->s_flex_groups) + if (sbi->s_flex_groups) { + for (i = 0; i < sbi->s_flex_groups_allocated; i++) + kvfree(sbi->s_flex_groups[i]); kvfree(sbi->s_flex_groups); + } percpu_counter_destroy(&sbi->s_freeclusters_counter); percpu_counter_destroy(&sbi->s_freeinodes_counter); percpu_counter_destroy(&sbi->s_dirs_counter); -- 2.17.1

4 years, 8 months

1
0
0 0

[PATCH v4 02/14] drm/i915: Clear the repeater bit on HDCP disable

by Sean Paul

From: Sean Paul <seanpaul(a)chromium.org> On HDCP disable, clear the repeater bit. This ensures if we connect a non-repeater sink after a repeater, the bit is in the state we expect. Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation) Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c(a)intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v4.17+ Reviewed-by: Ramalingam C <ramalingam.c(a)intel.com> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-sean@… #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-sean@… #v3 Changes in v2: -Added to the set Changes in v3: -None I had previously agreed that clearing the rep_ctl bits on enable would also be a good idea. However when I committed that idea to code, it didn't look right. So let's rely on enables and disables being paired and everything outside of that will be considered a bug Changes in v4: -s/I915_(READ|WRITE)/intel_de_(read|write)/ --- drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index de996f4f56997..f31a2f5d51a17 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -790,6 +790,7 @@ static int _intel_hdcp_disable(struct intel_connector *connector) struct intel_hdcp *hdcp = &connector->hdcp; enum port port = intel_dig_port->base.port; enum transcoder cpu_transcoder = hdcp->cpu_transcoder; + u32 repeater_ctl; int ret; drm_dbg_kms(&dev_priv->drm, "[%s:%d] HDCP is being disabled...\n", @@ -805,6 +806,11 @@ static int _intel_hdcp_disable(struct intel_connector *connector) return -ETIMEDOUT; } + repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder, + port); + intel_de_write(dev_priv, HDCP_REP_CTL, + intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl); + ret = hdcp->shim->toggle_signalling(intel_dig_port, false); if (ret) { drm_err(&dev_priv->drm, "Failed to disable HDCP signalling\n"); -- Sean Paul, Software Engineer, Google / Chromium OS

4 years, 8 months

1
0
0 0

[PATCH v4 01/14] drm/i915: Fix sha_text population code

by Sean Paul

From: Sean Paul <seanpaul(a)chromium.org> This patch fixes a few bugs: 1- We weren't taking into account sha_leftovers when adding multiple ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with the beginning of ksv[j] 2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was being placed on the wrong half of sha_text, overlapping the leftover ksv value 3- In the sha_leftovers == 2 case, we need to manually terminate the byte stream with 0x80 since the hardware doesn't have enough room to add it after writing M0 The upside is that all of the HDCP supported HDMI repeaters I could find on Amazon just strip HDCP anyways, so it turns out to be _really_ hard to hit any of these cases without an MST hub, which is not (yet) supported. Oh, and the sha_leftovers == 1 case works perfectly! Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation) Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Ramalingam C <ramalingam.c(a)intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Sean Paul <seanpaul(a)chromium.org> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: intel-gfx(a)lists.freedesktop.org Cc: <stable(a)vger.kernel.org> # v4.17+ Reviewed-by: Ramalingam C <ramalingam.c(a)intel.com> Signed-off-by: Sean Paul <seanpaul(a)chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-sean@p… #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-sean@… #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-sean@… #v3 Changes in v2: -None Changes in v3: -None Changes in v4: -Rebased on intel_de_write changes --- drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +++++++++++++++++------ include/drm/drm_hdcp.h | 3 +++ 2 files changed, 23 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c index 30e0a3aa9d574..de996f4f56997 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp.c +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c @@ -337,8 +337,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector *connector, /* Fill up the empty slots in sha_text and write it out */ sha_empty = sizeof(sha_text) - sha_leftovers; - for (j = 0; j < sha_empty; j++) - sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8); + for (j = 0; j < sha_empty; j++) { + u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) * 8); + sha_text |= ksv[j] << off; + } ret = intel_write_sha_text(dev_priv, sha_text); if (ret < 0) @@ -436,7 +438,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector *connector, /* Write 32 bits of text */ intel_de_write(dev_priv, HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32); - sha_text |= bstatus[0] << 24 | bstatus[1] << 16; + sha_text |= bstatus[0] << 8 | bstatus[1]; ret = intel_write_sha_text(dev_priv, sha_text); if (ret < 0) return ret; @@ -451,17 +453,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector *connector, return ret; sha_idx += sizeof(sha_text); } + + /* + * Terminate the SHA-1 stream by hand. For the other leftover + * cases this is appended by the hardware. + */ + intel_de_write(dev_priv, HDCP_REP_CTL, + rep_ctl | HDCP_SHA1_TEXT_32); + sha_text = DRM_HDCP_SHA1_TERMINATOR << 24; + ret = intel_write_sha_text(dev_priv, sha_text); + if (ret < 0) + return ret; + sha_idx += sizeof(sha_text); } else if (sha_leftovers == 3) { - /* Write 32 bits of text */ + /* Write 32 bits of text (filled from LSB) */ intel_de_write(dev_priv, HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_32); - sha_text |= bstatus[0] << 24; + sha_text |= bstatus[0]; ret = intel_write_sha_text(dev_priv, sha_text); if (ret < 0) return ret; sha_idx += sizeof(sha_text); - /* Write 8 bits of text, 24 bits of M0 */ + /* Write 8 bits of text (filled from LSB), 24 bits of M0 */ intel_de_write(dev_priv, HDCP_REP_CTL, rep_ctl | HDCP_SHA1_TEXT_8); ret = intel_write_sha_text(dev_priv, bstatus[1]); diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index 06a11202a0976..20498c8222046 100644 --- a/include/drm/drm_hdcp.h +++ b/include/drm/drm_hdcp.h @@ -29,6 +29,9 @@ /* Slave address for the HDCP registers in the receiver */ #define DRM_HDCP_DDC_ADDR 0x3A +/* Value to use at the end of the SHA-1 bytestream used for repeaters */ +#define DRM_HDCP_SHA1_TERMINATOR 0x80 + /* HDCP register offsets for HDMI/DVI devices */ #define DRM_HDCP_DDC_BKSV 0x00 #define DRM_HDCP_DDC_RI_PRIME 0x08 -- Sean Paul, Software Engineer, Google / Chromium OS

4 years, 8 months

1
0
0 0

[PATCH] libnvdimm/of_pmem: Fix leaking bus_desc.provider_name in some paths

by Vaibhav Jain

String 'bus_desc.provider_name' allocated inside of_pmem_region_probe() will leak in case call to nvdimm_bus_register() fails or when of_pmem_region_remove() is called. This minor patch ensures that 'bus_desc.provider_name' is freed in error path for of_pmem_region_probe() as well as in of_pmem_region_remove(). Cc: stable(a)vger.kernel.org Fixes:49bddc73d15c2("libnvdimm/of_pmem: Provide a unique name for bus provider") Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com> --- drivers/nvdimm/of_pmem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/nvdimm/of_pmem.c b/drivers/nvdimm/of_pmem.c index 8224d1431ea9..9cb76f9837ad 100644 --- a/drivers/nvdimm/of_pmem.c +++ b/drivers/nvdimm/of_pmem.c @@ -36,6 +36,7 @@ static int of_pmem_region_probe(struct platform_device *pdev) priv->bus = bus = nvdimm_bus_register(&pdev->dev, &priv->bus_desc); if (!bus) { + kfree(priv->bus_desc.provider_name); kfree(priv); return -ENODEV; } @@ -81,6 +82,7 @@ static int of_pmem_region_remove(struct platform_device *pdev) struct of_pmem_private *priv = platform_get_drvdata(pdev); nvdimm_bus_unregister(priv->bus); + kfree(priv->bus_desc.provider_name); kfree(priv); return 0; -- 2.24.1

4 years, 8 months

3
2
0 0

drivers/iommu/qcom_iommu.c:348 qcom_iommu_domain_free+0x5c/0x70

by Naresh Kamboju

We have noticed these kernel warnings on APQ 8016 SBC (dragonboard 410c ) running stable rc 5.5, 5.4 branches and linux mainline and linux-next master branches. This warning started happening from linux mainline 5.3 onwards (2019-08-29) [ 5.488128] ------------[ cut here ]------------ [ 5.488161] WARNING: CPU: 3 PID: 221 at drivers/iommu/qcom_iommu.c:348 qcom_iommu_domain_free+0x5c/0x70 [ 5.491817] Modules linked in: crct10dif_ce(+) adv7511(+) cec msm(+) mdt_loader drm_kms_helper drm fuse [ 5.491842] CPU: 3 PID: 221 Comm: systemd-udevd Not tainted 5.4.21-rc1-00037-g6f8f5c79416e #1 [ 5.491844] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 5.491849] pstate: 00000005 (nzcv daif -PAN -UAO) [ 5.491858] pc : qcom_iommu_domain_free+0x5c/0x70 [ 5.491865] lr : iommu_group_release+0x44/0x60 [ 5.491867] sp : ffff800011e83600 Starting Network Manager...[ 5.491870] x29: ffff800011e83600 x28: 0000000000000100 [ 5.491893] x19: ffff000036a9e500 x18: 0000000000000001 [ 5.491898] x17: 0000000000000000 x16: 0000000000000000 [ 5.491902] x15: 0000000000000004 x14: 0000000000000000 [ 5.491907] x13: 0000000000000000 x12: ffff00003a137aa0 [ 5.491911] x11: ffff00003a137908 x10: 0000000000000000 [ 5.491916] x9 : ffff00000eb2c098 x8 : ffff00000eb2c090 [ 5.491920] x7 : 00000000400c0000 x6 : 0000000000000004 [ 5.491924] x5 : 0000000000000001 x4 : 0000000000000000 [ 5.491929] x3 : 0000000000000000 x2 : 0000000000000000 [ 5.491933] x1 : ffff00003bdb9680 x0 : ffff000036aa0ab0 [ 5.491938] Call trace: [ 5.491946] qcom_iommu_domain_free+0x5c/0x70 [ 5.491951] iommu_group_release+0x44/0x60 [ 5.491957] kobject_put+0x6c/0xf0 [ 5.491962] kobject_del+0x50/0x68 [ 5.491966] kobject_put+0xd0/0xf0 [ 5.491972] iommu_group_remove_device+0xd8/0xec [ 5.491977] qcom_iommu_remove_device+0x44/0x60 [ 5.491982] iommu_release_device+0x28/0x40 [ 5.491987] iommu_bus_notifier+0xac/0xc0 [ 5.491993] notifier_call_chain+0x58/0x98 [ 5.491998] blocking_notifier_call_chain+0x54/0x78 [ 5.492003] device_del+0x224/0x348 [ 5.492008] platform_device_del.part.0+0x18/0x88 [ 5.492012] platform_device_unregister+0x20/0x38 [ 5.492019] of_platform_device_destroy+0xdc/0xf0 [ 5.492023] device_for_each_child+0x58/0xa0 [ 5.492028] of_platform_depopulate+0x38/0x78 [ 5.492155] msm_pdev_probe+0x1c0/0x308 [msm] [ 5.492166] platform_drv_probe+0x50/0xa0 [ 5.682404] really_probe+0xd4/0x308 [ 5.686388] driver_probe_device+0x54/0xe8 [ 5.690035] device_driver_attach+0x6c/0x78 [ 5.693940] __driver_attach+0x54/0xd0 [ 5.698020] bus_for_each_dev+0x6c/0xc0 [ 5.701838] driver_attach+0x20/0x28 [ 5.705572] bus_add_driver+0x140/0x1e8 [ 5.709390] driver_register+0x60/0x110 [ 5.712950] __platform_driver_register+0x44/0x50 [ 5.716886] msm_drm_register+0x54/0x68 [msm] [ 5.721633] do_one_initcall+0x50/0x190 [ 5.725972] do_init_module+0x50/0x208 [ 5.729615] load_module+0x1d1c/0x2298 [ 5.733435] __do_sys_finit_module+0xd0/0xe8 [ 5.737169] __arm64_sys_finit_module+0x1c/0x28 [ 5.741598] el0_svc_common.constprop.0+0x68/0x160 [ 5.745851] el0_svc_handler+0x20/0x80 [ 5.750709] el0_svc+0x8/0xc [ 5.754443] ---[ end trace 0ebe200932dd18fc ]--- Full test log link, https://lkft.validation.linaro.org/scheduler/job/1226062#L3841 https://lkft.validation.linaro.org/scheduler/job/1227242#L3877 Ref: https://bugs.linaro.org/show_bug.cgi?id=5460 -- Linaro LKFT https://lkft.linaro.org

4 years, 8 months

3
3
0 0

mmc patches for v5.4.y, v5.5.y

by Guenter Roeck

Hi Greg, please apply the following two patches to v5.4.y and v5.5.y to fix a problem when trying to boot various pxa machines from MMC. d3a5bcb4a17f gpio: add gpiod_toggle_active_low() 9073d10b0989 mmc: core: Rework wp-gpio handling The second patch fixes the problem, the first patch is necessary for the second patch to compile. Background: Commit 9073d10b0989 claims "No functional changes intended". However, it does include the following functional code change. --- a/drivers/mmc/host/pxamci.c +++ b/drivers/mmc/host/pxamci.c @@ -740,16 +740,16 @@ static int pxamci_probe(struct platform_device *pdev) goto out; } + if (!host->pdata->gpio_card_ro_invert) + mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH; + ret = mmc_gpiod_request_ro(mmc, "wp", 0, 0, NULL); if (ret && ret != -ENOENT) { dev_err(dev, "Failed requesting gpio_ro\n"); goto out; } - if (!ret) { + if (!ret) host->use_ro_gpio = true; - mmc->caps2 |= host->pdata->gpio_card_ro_invert ? - 0 : MMC_CAP2_RO_ACTIVE_HIGH; - } This _is_ a functional change: Previously, if there was no "ro" gpio pin, caps2 was never updated to active-high. This can have the practical effect of making the the card read-only, thus preventing the system from booting if it was mounted (and expected to be mounted) read-write. This is seen when trying to boot "spitz" and similar qemu machines from mmc. I bisected the problem to commit c914a27c92f91 ("mmc: pxamci: Support getting GPIO descs for RO and WP), affecting v5.0 and later kernels. Thanks, Guenter

4 years, 8 months

3
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2020