The ttyname buffer for the ledtrig_tty_data struct is allocated in the
sysfs ttyname_store() function. This buffer must be released on trigger
deactivation. This was missing and is thus a memory leak.
While we are at it, the tty handler in the ledtrig_tty_data struct should
also be returned in case of the trigger deactivation call.
Cc: stable(a)vger.kernel.org
Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger")
Signed-off-by: Florian Eckert <fe(a)dev.tdt.de>
---
v1 -> v2:
Add Cc: tag
drivers/leds/trigger/ledtrig-tty.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/leds/trigger/ledtrig-tty.c b/drivers/leds/trigger/ledtrig-tty.c
index 8ae0d2d284af..3e69a7bde928 100644
--- a/drivers/leds/trigger/ledtrig-tty.c
+++ b/drivers/leds/trigger/ledtrig-tty.c
@@ -168,6 +168,10 @@ static void ledtrig_tty_deactivate(struct led_classdev *led_cdev)
cancel_delayed_work_sync(&trigger_data->dwork);
+ kfree(trigger_data->ttyname);
+ tty_kref_put(trigger_data->tty);
+ trigger_data->tty = NULL;
+
kfree(trigger_data);
}
--
2.30.2
On Mon, Nov 06, 2023 at 01:18:36PM +0100, gregkh(a)linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> tty: 8250: Add support for Intashield IX cards
>
> to the 5.10-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> tty-8250-add-support-for-intashield-ix-cards.patch
> and it can be found in the queue-5.10 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
>
I don't think this patch should be in 5.10-stable. It's using the
pbn_oxsemi_x_15625000 configuration which isn't available in the version
of the driver (it's actually pbn_oxsemi_x_3906250 in this version).
The rest of the patches to be merged look OK for this branch (as they are
all using the generic configuration rather than Oxsemi).
>
Thanks,
Cameron
> From 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 Mon Sep 17 00:00:00 2001
> From: Cameron Williams <cang1(a)live.co.uk>
> Date: Fri, 20 Oct 2023 17:03:16 +0100
> Subject: tty: 8250: Add support for Intashield IX cards
>
> From: Cameron Williams <cang1(a)live.co.uk>
>
> commit 62d2ec2ded278c7512d91ca7bf8eb9bac46baf90 upstream.
>
> Add support for the IX-100, IX-200 and IX-400 serial cards.
>
> Cc: stable(a)vger.kernel.org
> Signed-off-by: Cameron Williams <cang1(a)live.co.uk>
> Link: https://lore.kernel.org/r/DU0PR02MB7899614E5837E82A03272A4BC4DBA@DU0PR02MB7…
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> drivers/tty/serial/8250/8250_pci.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -5150,6 +5150,27 @@ static const struct pci_device_id serial
> { PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */
> pbn_b2_4_115200 },
> + /*
> + * IntaShield IX-100
> + */
> + { PCI_VENDOR_ID_INTASHIELD, 0x4027,
> + PCI_ANY_ID, PCI_ANY_ID,
> + 0, 0,
> + pbn_oxsemi_1_15625000 },
> + /*
> + * IntaShield IX-200
> + */
> + { PCI_VENDOR_ID_INTASHIELD, 0x4028,
> + PCI_ANY_ID, PCI_ANY_ID,
> + 0, 0,
> + pbn_oxsemi_2_15625000 },
> + /*
> + * IntaShield IX-400
> + */
> + { PCI_VENDOR_ID_INTASHIELD, 0x4029,
> + PCI_ANY_ID, PCI_ANY_ID,
> + 0, 0,
> + pbn_oxsemi_4_15625000 },
> /* Brainboxes Devices */
> /*
> * Brainboxes UC-101
>
>
> Patches currently in stable-queue which might be from cang1(a)live.co.uk are
>
> queue-5.10/tty-8250-add-support-for-additional-brainboxes-uc-cards.patch
> queue-5.10/tty-8250-add-support-for-intashield-ix-cards.patch
> queue-5.10/tty-8250-add-support-for-brainboxes-up-cards.patch
> queue-5.10/tty-8250-add-support-for-intashield-is-100.patch
> queue-5.10/tty-8250-remove-uc-257-and-uc-431.patch
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 b65235f6e102354ccafda601eaa1c5bef5284d21
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023102017-human-marine-7125@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From b65235f6e102354ccafda601eaa1c5bef5284d21 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <mlevitsk(a)redhat.com>
Date: Thu, 28 Sep 2023 20:33:51 +0300
Subject: [PATCH] x86: KVM: SVM: always update the x2avic msr interception
The following problem exists since x2avic was enabled in the KVM:
svm_set_x2apic_msr_interception is called to enable the interception of
the x2apic msrs.
In particular it is called at the moment the guest resets its apic.
Assuming that the guest's apic was in x2apic mode, the reset will bring
it back to the xapic mode.
The svm_set_x2apic_msr_interception however has an erroneous check for
'!apic_x2apic_mode()' which prevents it from doing anything in this case.
As a result of this, all x2apic msrs are left unintercepted, and that
exposes the bare metal x2apic (if enabled) to the guest.
Oops.
Remove the erroneous '!apic_x2apic_mode()' check to fix that.
This fixes CVE-2023-5090
Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode")
Cc: stable(a)vger.kernel.org
Signed-off-by: Maxim Levitsky <mlevitsk(a)redhat.com>
Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com>
Reviewed-by: Sean Christopherson <seanjc(a)google.com>
Message-Id: <20230928173354.217464-2-mlevitsk(a)redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 9507df93f410..acdd0b89e471 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -913,8 +913,7 @@ void svm_set_x2apic_msr_interception(struct vcpu_svm *svm, bool intercept)
if (intercept == svm->x2avic_msrs_intercepted)
return;
- if (!x2avic_enabled ||
- !apic_x2apic_mode(svm->vcpu.arch.apic))
+ if (!x2avic_enabled)
return;
for (i = 0; i < MAX_DIRECT_ACCESS_MSRS; i++) {
This helper is used for checking if the connected host supports
the feature, it can be moved into generic code to be used by other
smu implementations as well.
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
Reviewed-by: Evan Quan <evan.quan(a)amd.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
(cherry picked from commit 188623076d0f1a500583d392b6187056bf7cc71a)
The original problematic dGPU is not supported in 5.15.
Just introduce new function for 5.15 as a dependency for fixing
unrelated dGPU that uses this symbol as well.
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
v1->v2:
* Update commit to 6.5-rc2 commit.
It merged as both of these:
188623076d0f1a500583d392b6187056bf7cc71a
5d1eb4c4c872b55664f5754cc16827beff8630a7
It's already been backported into 6.1.y as well.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +++++++++++++++++++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d90da384d185..1f1e7966beb5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1285,6 +1285,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
void amdgpu_device_pci_config_reset(struct amdgpu_device *adev);
int amdgpu_device_pci_reset(struct amdgpu_device *adev);
bool amdgpu_device_need_post(struct amdgpu_device *adev);
+bool amdgpu_device_pcie_dynamic_switching_supported(void);
bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
bool amdgpu_device_aspm_support_quirk(void);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 2cf49a32ac6c..f57334fff7fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1319,6 +1319,25 @@ bool amdgpu_device_need_post(struct amdgpu_device *adev)
return true;
}
+/*
+ * Intel hosts such as Raptor Lake and Sapphire Rapids don't support dynamic
+ * speed switching. Until we have confirmation from Intel that a specific host
+ * supports it, it's safer that we keep it disabled for all.
+ *
+ * https://edc.intel.com/content/www/us/en/design/products/platforms/details/r…
+ * https://gitlab.freedesktop.org/drm/amd/-/issues/2663
+ */
+bool amdgpu_device_pcie_dynamic_switching_supported(void)
+{
+#if IS_ENABLED(CONFIG_X86)
+ struct cpuinfo_x86 *c = &cpu_data(0);
+
+ if (c->x86_vendor == X86_VENDOR_INTEL)
+ return false;
+#endif
+ return true;
+}
+
/**
* amdgpu_device_should_use_aspm - check if the device should program ASPM
*
--
2.34.1