- Linux-stable-mirror - lists.linaro.org

[PATCH] ocfs2: Fix kernel BUG in ocfs2_write_block

by Prithvi Tambewagh

When the filesystem is being mounted, the kernel panics while the data regarding slot map allocation to the local node, is being written to the disk. This occurs because the value of slot map buffer head block number, which should have been greater than or equal to `OCFS2_SUPER_BLOCK_BLKNO` (evaluating to 2) is less than it, indicative of disk metadata corruption. This triggers BUG_ON(bh->b_blocknr < OCFS2_SUPER_BLOCK_BLKNO) in ocfs2_write_block(), causing the kernel to panic. This is fixed by introducing an if condition block in ocfs2_update_disk_slot(), right before calling ocfs2_write_block(), which checks if `bh->b_blocknr` is lesser than `OCFS2_SUPER_BLOCK_BLKNO`; if yes, then ocfs2_error is called, which prints the error log, for debugging purposes, and the return value of ocfs2_error() is returned back to caller of ocfs2_update_disk_slot() i.e. ocfs2_find_slot(). If the return value is zero. then error code EIO is returned. Reported-by: syzbot+c818e5c4559444f88aa0(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=c818e5c4559444f88aa0 Tested-by: syzbot+c818e5c4559444f88aa0(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> --- fs/ocfs2/slot_map.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/ocfs2/slot_map.c b/fs/ocfs2/slot_map.c index e544c704b583..788924fc3663 100644 --- a/fs/ocfs2/slot_map.c +++ b/fs/ocfs2/slot_map.c @@ -193,6 +193,16 @@ static int ocfs2_update_disk_slot(struct ocfs2_super *osb, else ocfs2_update_disk_slot_old(si, slot_num, &bh); spin_unlock(&osb->osb_lock); + if (bh->b_blocknr < OCFS2_SUPER_BLOCK_BLKNO) { + status = ocfs2_error(osb->sb, + "Invalid Slot Map Buffer Head " + "Block Number : %llu, Should be >= %d", + le16_to_cpu(bh->b_blocknr), + le16_to_cpu((int)OCFS2_SUPER_BLOCK_BLKNO)); + if (!status) + return -EIO; + return status; + } status = ocfs2_write_block(osb, bh, INODE_CACHE(si->si_inode)); if (status < 0) base-commit: 24172e0d79900908cf5ebf366600616d29c9b417 -- 2.43.0

1 week, 2 days

2
1
0 0

[PATCH] KEYS: trusted: Fix overwrite of keyhandle parameter

by Jarkko Sakkinen

tpm2_key_decode() overrides the explicit keyhandle parameter, which can lead to problems, if the loaded parent handle does not match the handle stored to the key file. This can easily happen as handle by definition is an ambiguous attribute. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs") Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org> --- security/keys/trusted-keys/trusted_tpm2.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/security/keys/trusted-keys/trusted_tpm2.c b/security/keys/trusted-keys/trusted_tpm2.c index fb76c4ea496f..950684e54c71 100644 --- a/security/keys/trusted-keys/trusted_tpm2.c +++ b/security/keys/trusted-keys/trusted_tpm2.c @@ -121,7 +121,9 @@ static int tpm2_key_decode(struct trusted_key_payload *payload, return -ENOMEM; *buf = blob; - options->keyhandle = ctx.parent; + + if (!options->keyhandle) + options->keyhandle = ctx.parent; memcpy(blob, ctx.priv, ctx.priv_len); blob += ctx.priv_len; -- 2.39.5

1 week, 2 days

1
1
0 0

FAILED: patch "[PATCH] KVM: SVM: Don't skip unrelated instruction if INT3/INTO is" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 4da3768e1820cf15cced390242d8789aed34f54d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120802-remedy-glimmer-fc9d@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 4da3768e1820cf15cced390242d8789aed34f54d Mon Sep 17 00:00:00 2001 From: Omar Sandoval <osandov(a)fb.com> Date: Tue, 4 Nov 2025 09:55:26 -0800 Subject: [PATCH] KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced When re-injecting a soft interrupt from an INT3, INT0, or (select) INTn instruction, discard the exception and retry the instruction if the code stream is changed (e.g. by a different vCPU) between when the CPU executes the instruction and when KVM decodes the instruction to get the next RIP. As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction"), failure to verify that the correct INTn instruction was decoded can effectively clobber guest state due to decoding the wrong instruction and thus specifying the wrong next RIP. The bug most often manifests as "Oops: int3" panics on static branch checks in Linux guests. Enabling or disabling a static branch in Linux uses the kernel's "text poke" code patching mechanism. To modify code while other CPUs may be executing that code, Linux (temporarily) replaces the first byte of the original instruction with an int3 (opcode 0xcc), then patches in the new code stream except for the first byte, and finally replaces the int3 with the first byte of the new code stream. If a CPU hits the int3, i.e. executes the code while it's being modified, then the guest kernel must look up the RIP to determine how to handle the #BP, e.g. by emulating the new instruction. If the RIP is incorrect, then this lookup fails and the guest kernel panics. The bug reproduces almost instantly by hacking the guest kernel to repeatedly check a static branch[1] while running a drgn script[2] on the host to constantly swap out the memory containing the guest's TSS. [1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a [2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b Fixes: 6ef88d6e36c2 ("KVM: SVM: Re-inject INT3/INTO instead of retrying the instruction") Cc: stable(a)vger.kernel.org Co-developed-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Omar Sandoval <osandov(a)fb.com> Link: https://patch.msgid.link/1cc6dcdf36e3add7ee7c8d90ad58414eeb6c3d34.176227876… Signed-off-by: Sean Christopherson <seanjc(a)google.com> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 48598d017d6f..974d64bf0a4d 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -2143,6 +2143,11 @@ u64 vcpu_tsc_khz(struct kvm_vcpu *vcpu); * the gfn, i.e. retrying the instruction will hit a * !PRESENT fault, which results in a new shadow page * and sends KVM back to square one. + * + * EMULTYPE_SKIP_SOFT_INT - Set in combination with EMULTYPE_SKIP to only skip + * an instruction if it could generate a given software + * interrupt, which must be encoded via + * EMULTYPE_SET_SOFT_INT_VECTOR(). */ #define EMULTYPE_NO_DECODE (1 << 0) #define EMULTYPE_TRAP_UD (1 << 1) @@ -2153,6 +2158,10 @@ u64 vcpu_tsc_khz(struct kvm_vcpu *vcpu); #define EMULTYPE_PF (1 << 6) #define EMULTYPE_COMPLETE_USER_EXIT (1 << 7) #define EMULTYPE_WRITE_PF_TO_SP (1 << 8) +#define EMULTYPE_SKIP_SOFT_INT (1 << 9) + +#define EMULTYPE_SET_SOFT_INT_VECTOR(v) ((u32)((v) & 0xff) << 16) +#define EMULTYPE_GET_SOFT_INT_VECTOR(e) (((e) >> 16) & 0xff) static inline bool kvm_can_emulate_event_vectoring(int emul_type) { diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 1ae7b3c5a7c5..459db8154929 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -272,6 +272,7 @@ static void svm_set_interrupt_shadow(struct kvm_vcpu *vcpu, int mask) } static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu, + int emul_type, bool commit_side_effects) { struct vcpu_svm *svm = to_svm(vcpu); @@ -293,7 +294,7 @@ static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu, if (unlikely(!commit_side_effects)) old_rflags = svm->vmcb->save.rflags; - if (!kvm_emulate_instruction(vcpu, EMULTYPE_SKIP)) + if (!kvm_emulate_instruction(vcpu, emul_type)) return 0; if (unlikely(!commit_side_effects)) @@ -311,11 +312,13 @@ static int __svm_skip_emulated_instruction(struct kvm_vcpu *vcpu, static int svm_skip_emulated_instruction(struct kvm_vcpu *vcpu) { - return __svm_skip_emulated_instruction(vcpu, true); + return __svm_skip_emulated_instruction(vcpu, EMULTYPE_SKIP, true); } -static int svm_update_soft_interrupt_rip(struct kvm_vcpu *vcpu) +static int svm_update_soft_interrupt_rip(struct kvm_vcpu *vcpu, u8 vector) { + const int emul_type = EMULTYPE_SKIP | EMULTYPE_SKIP_SOFT_INT | + EMULTYPE_SET_SOFT_INT_VECTOR(vector); unsigned long rip, old_rip = kvm_rip_read(vcpu); struct vcpu_svm *svm = to_svm(vcpu); @@ -331,7 +334,7 @@ static int svm_update_soft_interrupt_rip(struct kvm_vcpu *vcpu) * in use, the skip must not commit any side effects such as clearing * the interrupt shadow or RFLAGS.RF. */ - if (!__svm_skip_emulated_instruction(vcpu, !nrips)) + if (!__svm_skip_emulated_instruction(vcpu, emul_type, !nrips)) return -EIO; rip = kvm_rip_read(vcpu); @@ -367,7 +370,7 @@ static void svm_inject_exception(struct kvm_vcpu *vcpu) kvm_deliver_exception_payload(vcpu, ex); if (kvm_exception_is_soft(ex->vector) && - svm_update_soft_interrupt_rip(vcpu)) + svm_update_soft_interrupt_rip(vcpu, ex->vector)) return; svm->vmcb->control.event_inj = ex->vector @@ -3642,11 +3645,12 @@ static bool svm_set_vnmi_pending(struct kvm_vcpu *vcpu) static void svm_inject_irq(struct kvm_vcpu *vcpu, bool reinjected) { + struct kvm_queued_interrupt *intr = &vcpu->arch.interrupt; struct vcpu_svm *svm = to_svm(vcpu); u32 type; - if (vcpu->arch.interrupt.soft) { - if (svm_update_soft_interrupt_rip(vcpu)) + if (intr->soft) { + if (svm_update_soft_interrupt_rip(vcpu, intr->nr)) return; type = SVM_EVTINJ_TYPE_SOFT; @@ -3654,12 +3658,10 @@ static void svm_inject_irq(struct kvm_vcpu *vcpu, bool reinjected) type = SVM_EVTINJ_TYPE_INTR; } - trace_kvm_inj_virq(vcpu->arch.interrupt.nr, - vcpu->arch.interrupt.soft, reinjected); + trace_kvm_inj_virq(intr->nr, intr->soft, reinjected); ++vcpu->stat.irq_injections; - svm->vmcb->control.event_inj = vcpu->arch.interrupt.nr | - SVM_EVTINJ_VALID | type; + svm->vmcb->control.event_inj = intr->nr | SVM_EVTINJ_VALID | type; } void svm_complete_interrupt_delivery(struct kvm_vcpu *vcpu, int delivery_mode, diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 42ecd093bb4c..8e14c0292809 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -9338,6 +9338,23 @@ static bool is_vmware_backdoor_opcode(struct x86_emulate_ctxt *ctxt) return false; } +static bool is_soft_int_instruction(struct x86_emulate_ctxt *ctxt, + int emulation_type) +{ + u8 vector = EMULTYPE_GET_SOFT_INT_VECTOR(emulation_type); + + switch (ctxt->b) { + case 0xcc: + return vector == BP_VECTOR; + case 0xcd: + return vector == ctxt->src.val; + case 0xce: + return vector == OF_VECTOR; + default: + return false; + } +} + /* * Decode an instruction for emulation. The caller is responsible for handling * code breakpoints. Note, manually detecting code breakpoints is unnecessary @@ -9448,6 +9465,10 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, * injecting single-step #DBs. */ if (emulation_type & EMULTYPE_SKIP) { + if (emulation_type & EMULTYPE_SKIP_SOFT_INT && + !is_soft_int_instruction(ctxt, emulation_type)) + return 0; + if (ctxt->mode != X86EMUL_MODE_PROT64) ctxt->eip = (u32)ctxt->_eip; else

1 week, 2 days

3
4
0 0

¿Cuánto cuesta una mala contratación?

by Valeria Pérez

¿Cuánto cuesta una mala contratación? body { margin: 0; padding: 0; font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: #333; background-color: #ffffff; } table { border-spacing: 0; width: 100%; max-width: 600px; margin: auto; } td { padding: 12px 20px; } a { color: #1a73e8; text-decoration: none; } .footer { font-size: 12px; color: #888888; text-align: center; } Una mala contratación cuesta 3X el salario. Evítalo con datos, no percepciones. Hola, , ¿Sabías que una mala contratación cuesta hasta 3 veces el salario anual? El 74% de empresas admite haber contratado a la persona equivocada. El motivo: decisiones basadas en percepciones, no en datos objetivos. PsicoSmart te ayuda a evaluar talento con precisión: 31 pruebas psicométricas validadas para medir liderazgo, honestidad e inteligencia 2,500+ exámenes técnicos especializados por industria Verificación de identidad con captura fotográfica automática Resultados en minutos, accesible desde cualquier dispositivo Reduce hasta 60% el riesgo de error en selección. ¿Quieres una demostración gratuita? Responde este correo y te contacto en menos de 24 horas. Saludos, -------------- Atte.: Valeria Pérez Ciudad de México: (55) 5018 0565 WhatsApp: +52 33 1607 2089 Si no deseas recibir más correos, haz clic aquí para darte de baja. Para remover su dirección de esta lista haga <a href="https://s1.arrobamail.com/unsuscribe.php?id=yiwtsrewiswqrpseup">click aquí</a>

1 week, 3 days

1
0
0 0

[PATCH] pmdomain: imx: Fix reference count leak in imx_gpc_probe()

by Wentao Liang

of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() calls in imx_gpc_probe() to avoid reference count leak. This commit fixes the following issues: 1. Add of_node_put(pgc_node) before returning from imx_gpc_probe() 2. Use goto pattern to consolidate error handling Fixes: 721cabf6c660 ("soc: imx: move PGC handling to a new GPC driver") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/pmdomain/imx/gpc.c | 31 +++++++++++++++++++++---------- 1 file changed, 21 insertions(+), 10 deletions(-) diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c index f18c7e6e75dd..754c60effc8a 100644 --- a/drivers/pmdomain/imx/gpc.c +++ b/drivers/pmdomain/imx/gpc.c @@ -416,8 +416,10 @@ static int imx_gpc_probe(struct platform_device *pdev) return 0; base = devm_platform_ioremap_resource(pdev, 0); - if (IS_ERR(base)) - return PTR_ERR(base); + if (IS_ERR(base)) { + ret = PTR_ERR(base); + goto err_free; + } regmap = devm_regmap_init_mmio_clk(&pdev->dev, NULL, base, &imx_gpc_regmap_config); @@ -425,7 +427,7 @@ static int imx_gpc_probe(struct platform_device *pdev) ret = PTR_ERR(regmap); dev_err(&pdev->dev, "failed to init regmap: %d\n", ret); - return ret; + goto err_free; } /* @@ -460,29 +462,33 @@ static int imx_gpc_probe(struct platform_device *pdev) int domain_index; ipg_clk = devm_clk_get(&pdev->dev, "ipg"); - if (IS_ERR(ipg_clk)) - return PTR_ERR(ipg_clk); + if (IS_ERR(ipg_clk)) { + ret = PTR_ERR(ipg_clk); + goto err_free; + } ipg_rate_mhz = clk_get_rate(ipg_clk) / 1000000; for_each_child_of_node_scoped(pgc_node, np) { ret = of_property_read_u32(np, "reg", &domain_index); if (ret) - return ret; + goto err_free; if (domain_index >= of_id_data->num_domains) continue; pd_pdev = platform_device_alloc("imx-pgc-power-domain", domain_index); - if (!pd_pdev) - return -ENOMEM; + if (!pd_pdev) { + ret = -ENOMEM; + goto err_free; + } ret = platform_device_add_data(pd_pdev, &imx_gpc_domains[domain_index], sizeof(imx_gpc_domains[domain_index])); if (ret) { platform_device_put(pd_pdev); - return ret; + goto err_free; } domain = pd_pdev->dev.platform_data; domain->regmap = regmap; @@ -495,12 +501,17 @@ static int imx_gpc_probe(struct platform_device *pdev) ret = platform_device_add(pd_pdev); if (ret) { platform_device_put(pd_pdev); - return ret; + goto err_free; } } } + of_node_put(pgc_node); return 0; + +err_free: + of_node_put(pgc_node); + return ret; } static void imx_gpc_remove(struct platform_device *pdev) -- 2.34.1

1 week, 3 days

3
2
0 0

[PATCH v3 1/2] intel_th: fix device leak on output open()

by Johan Hovold

Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close(). Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open(). Fixes: 39f4034693b7 ("intel_th: Add driver infrastructure for Intel(R) Trace Hub devices") Fixes: 6d5925b667e4 ("intel_th: Fix error handling in intel_th_output_open") Cc: stable(a)vger.kernel.org # 4.4: 6d5925b667e4 Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Cc: Ma Ke <make24(a)iscas.ac.cn> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/hwtracing/intel_th/core.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c index 591b7c12aae5..d9c17214d3dc 100644 --- a/drivers/hwtracing/intel_th/core.c +++ b/drivers/hwtracing/intel_th/core.c @@ -810,9 +810,12 @@ static int intel_th_output_open(struct inode *inode, struct file *file) int err; dev = bus_find_device_by_devt(&intel_th_bus, inode->i_rdev); - if (!dev || !dev->driver) { + if (!dev) + return -ENODEV; + + if (!dev->driver) { err = -ENODEV; - goto out_no_device; + goto out_put_device; } thdrv = to_intel_th_driver(dev->driver); @@ -836,12 +839,22 @@ static int intel_th_output_open(struct inode *inode, struct file *file) out_put_device: put_device(dev); -out_no_device: + return err; } +static int intel_th_output_release(struct inode *inode, struct file *file) +{ + struct intel_th_device *thdev = file->private_data; + + put_device(&thdev->dev); + + return 0; +} + static const struct file_operations intel_th_output_fops = { .open = intel_th_output_open, + .release = intel_th_output_release, .llseek = noop_llseek, }; -- 2.52.0

1 week, 3 days

1
0
0 0

[PATCH] fsi: master-gpio: Fix reference count leak in probe error path

by Wentao Liang

The function of_node_get() returns a node pointer with its refcount incremented, but in the error path of the fsi_master_gpio_probe(), this reference is not released before freeing the master structure, causing a refcount leak. Add the missing of_node_put() in the error handling path to properly release the device tree node reference. Fixes: 8ef9ccf81044 ("fsi: master-gpio: Add missing release function") Cc: stable(a)vger.kernel.org Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/fsi/fsi-master-gpio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/fsi/fsi-master-gpio.c b/drivers/fsi/fsi-master-gpio.c index 69de0b5b9cbd..ae9e156284d0 100644 --- a/drivers/fsi/fsi-master-gpio.c +++ b/drivers/fsi/fsi-master-gpio.c @@ -861,6 +861,7 @@ static int fsi_master_gpio_probe(struct platform_device *pdev) } return 0; err_free: + of_node_put(master->master.dev.of_node); kfree(master); return rc; } -- 2.34.1

1 week, 3 days

2
1
0 0

[PATCH] resource: handle wrong resource_size value on zero start/end resource

by Christian Marangi

Commit 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for "memory-region"") uncovered a massive problem with the usage of resource_size() helper. The reported commit caused a regression with ath11k WiFi firmware loading and the change was just a simple replacement of duplicate code with a new helper of_reserved_mem_region_to_resource(). On reworking this, in the commit also a check for the presence of the node was replaced with resource_size(&res). This was done following the logic that if the node wasn't present then it's expected that also the resource_size is zero, mimicking the same if-else logic. This was also the reason the regression was mostly hard to catch at first sight as the rework is correctly done given the assumption on the used helpers. BUT this is actually not the case. On further inspection on resource_size() it was found that it NEVER actually returns 0. Even if the resource value of start and end are 0, the return value of resource_size() will ALWAYS be 1, resulting in the broken if-else condition ALWAYS going in the first if condition. This was simply confirmed by reading the resource_size() logic: return res->end - res->start + 1; Given the confusion, also other case of such usage were searched in the kernel and with great suprise it seems LOTS of place assume resource_size() should return zero in the context of the resource start and end set to 0. Quoting for example comments in drivers/vfio/pci/vfio_pci_core.c: /* * The PCI core shouldn't set up a resource with a * type but zero size. But there may be bugs that * cause us to do that. */ if (!resource_size(res)) goto no_mmap; It really seems resource_size() was tought with the assumption that resource struct was always correctly initialized before calling it and never set to zero. But across the year this got lost and now there are lots of driver that assume resource_size() returns 0 if start and end are also 0. To better handle this and make resource_size() returns correct value in such case, add a simple check and return 0 if both resource start and resource end are zero. Cc: Rob Herring (Arm) <robh(a)kernel.org> Cc: stable(a)vger.kernel.org Fixes: 1a4e564b7db9 ("resource: add resource_size()") Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> --- include/linux/ioport.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index 9afa30f9346f..1b8ce62255db 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -288,6 +288,9 @@ static inline void resource_set_range(struct resource *res, static inline resource_size_t resource_size(const struct resource *res) { + if (!res->start && !res->end) + return 0; + return res->end - res->start + 1; } static inline unsigned long resource_type(const struct resource *res) -- 2.51.0

1 week, 3 days

3
10
0 0

[PATCH] powerpc/pseries: Fix MSI-X allocation failure when quota is exceeded

by Nam Cao

Nilay reported that since commit daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()"), the NVMe driver cannot enable MSI-X when the device's MSI-X table size is larger than the firmware's MSI quota for the device. This is because the commit changes how rtas_prepare_msi_irqs() is called: - Before, it is called when interrupts are allocated at the global interrupt domain with nvec_in being the number of allocated interrupts. rtas_prepare_msi_irqs() can return a positive number and the allocation will be retried. - Now, it is called at the creation of per-device interrupt domain with nvec_in being the number of interrupts that the device supports. If rtas_prepare_msi_irqs() returns positive, domain creation just fails. For Nilay's NVMe driver case, rtas_prepare_msi_irqs() returns a positive number (the quota). This causes per-device interrupt domain creation to fail and thus the NVMe driver cannot enable MSI-X. Rework to make this scenario works again: - pseries_msi_ops_prepare() only prepares as many interrupts as the quota permit. - pseries_irq_domain_alloc() fails if the device's quota is exceeded. Now, if the quota is exceeded, pseries_msi_ops_prepare() will only prepare as allowed by the quota. If device drivers attempt to allocate more interrupts than the quota permits, pseries_irq_domain_alloc() will return an error code and msi_handle_pci_fail() will allow device drivers a retry. Reported-by: Nilay Shroff <nilay(a)inux.ibm.com> Closes: https://lore.kernel.org/linuxppc-dev/6af2c4c2-97f6-4758-be33-256638ef39e5@l… Fixes: daaa574aba6f ("powerpc/pseries/msi: Switch to msi_create_parent_irq_domain()") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Acked-by: Nilay Shroff <nilay(a)inux.ibm.com> Cc: stable(a)vger.kernel.org --- arch/powerpc/platforms/pseries/msi.c | 42 ++++++++++++++++++++++++++-- 1 file changed, 39 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c index a82aaa786e9e..8898a968a59b 100644 --- a/arch/powerpc/platforms/pseries/msi.c +++ b/arch/powerpc/platforms/pseries/msi.c @@ -19,6 +19,11 @@ #include "pseries.h" +struct pseries_msi_device { + unsigned int msi_quota; + unsigned int msi_used; +}; + static int query_token, change_token; #define RTAS_QUERY_FN 0 @@ -433,8 +438,26 @@ static int pseries_msi_ops_prepare(struct irq_domain *domain, struct device *dev struct msi_domain_info *info = domain->host_data; struct pci_dev *pdev = to_pci_dev(dev); int type = (info->flags & MSI_FLAG_PCI_MSIX) ? PCI_CAP_ID_MSIX : PCI_CAP_ID_MSI; + int ret; + + struct pseries_msi_device *pseries_dev __free(kfree) + = kmalloc(sizeof(*pseries_dev), GFP_KERNEL); + if (!pseries_dev) + return -ENOMEM; + + ret = rtas_prepare_msi_irqs(pdev, nvec, type, arg); + if (ret > 0) { + nvec = ret; + ret = rtas_prepare_msi_irqs(pdev, nvec, type, arg); + } + if (ret < 0) + return ret; - return rtas_prepare_msi_irqs(pdev, nvec, type, arg); + pseries_dev->msi_quota = nvec; + pseries_dev->msi_used = 0; + + arg->scratchpad[0].ptr = no_free_ptr(pseries_dev); + return 0; } /* @@ -443,9 +466,13 @@ static int pseries_msi_ops_prepare(struct irq_domain *domain, struct device *dev */ static void pseries_msi_ops_teardown(struct irq_domain *domain, msi_alloc_info_t *arg) { + struct pseries_msi_device *pseries_dev = arg->scratchpad[0].ptr; struct pci_dev *pdev = to_pci_dev(domain->dev); rtas_disable_msi(pdev); + + WARN_ON(pseries_dev->msi_used); + kfree(pseries_dev); } static void pseries_msi_shutdown(struct irq_data *d) @@ -546,12 +573,18 @@ static int pseries_irq_domain_alloc(struct irq_domain *domain, unsigned int virq unsigned int nr_irqs, void *arg) { struct pci_controller *phb = domain->host_data; + struct pseries_msi_device *pseries_dev; msi_alloc_info_t *info = arg; struct msi_desc *desc = info->desc; struct pci_dev *pdev = msi_desc_to_pci_dev(desc); int hwirq; int i, ret; + pseries_dev = info->scratchpad[0].ptr; + + if (pseries_dev->msi_used + nr_irqs > pseries_dev->msi_quota) + return -ENOSPC; + hwirq = rtas_query_irq_number(pci_get_pdn(pdev), desc->msi_index); if (hwirq < 0) { dev_err(&pdev->dev, "Failed to query HW IRQ: %d\n", hwirq); @@ -567,9 +600,10 @@ static int pseries_irq_domain_alloc(struct irq_domain *domain, unsigned int virq goto out; irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i, - &pseries_msi_irq_chip, domain->host_data); + &pseries_msi_irq_chip, pseries_dev); } + pseries_dev->msi_used++; return 0; out: @@ -582,9 +616,11 @@ static void pseries_irq_domain_free(struct irq_domain *domain, unsigned int virq unsigned int nr_irqs) { struct irq_data *d = irq_domain_get_irq_data(domain, virq); - struct pci_controller *phb = irq_data_get_irq_chip_data(d); + struct pseries_msi_device *pseries_dev = irq_data_get_irq_chip_data(d); + struct pci_controller *phb = domain->host_data; pr_debug("%s bridge %pOF %d #%d\n", __func__, phb->dn, virq, nr_irqs); + pseries_dev->msi_used -= nr_irqs; irq_domain_free_irqs_parent(domain, virq, nr_irqs); } -- 2.47.3

1 week, 3 days

1
0
0 0

FAILED: patch "[PATCH] xhci: dbgtty: fix device unregister" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 1f73b8b56cf35de29a433aee7bfff26cea98be3f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120110-coastal-litigator-8952@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1f73b8b56cf35de29a433aee7bfff26cea98be3f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=81ukasz=20Bartosik?= <ukaszb(a)chromium.org> Date: Wed, 19 Nov 2025 21:29:09 +0000 Subject: [PATCH] xhci: dbgtty: fix device unregister MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_vhangup() call in xhci_dbc_tty_unregister_device(). The tty_vhangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> Link: https://patch.msgid.link/20251119212910.1245694-1-ukaszb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index b7f95565524d..57cdda4e09c8 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -550,6 +550,12 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + tty_vhangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false;

1 week, 3 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror