Since commit 4959aebba8c0 ("virtio-net: use mtu size as buffer length
for big packets"), when guest gso is off, the allocated size for big
packets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends on
negotiated MTU. The number of allocated frags for big packets is stored
in vi->big_packets_num_skbfrags.
Because the host announced buffer length can be malicious (e.g. the host
vhost_net driver's get_rx_bufs is modified to announce incorrect
length), we need a check in virtio_net receive path. Currently, the
check is not adapted to the new change which can lead to NULL page
pointer dereference in the below while loop when receiving length that
is larger than the allocated one.
This commit fixes the received length check corresponding to the new
change.
Fixes: 4959aebba8c0 ("virtio-net: use mtu size as buffer length for big packets")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bui Quang Minh <minhquangbui99(a)gmail.com>
---
Changes in v4:
- Remove unrelated changes, add more comments
Changes in v3:
- Convert BUG_ON to WARN_ON_ONCE
Changes in v2:
- Remove incorrect give_pages call
---
drivers/net/virtio_net.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index a757cbcab87f..0ffe78b3fd8d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -852,7 +852,7 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
{
struct sk_buff *skb;
struct virtio_net_common_hdr *hdr;
- unsigned int copy, hdr_len, hdr_padded_len;
+ unsigned int copy, hdr_len, hdr_padded_len, max_remaining_len;
struct page *page_to_free = NULL;
int tailroom, shinfo_size;
char *p, *hdr_p, *buf;
@@ -915,13 +915,23 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi,
* This is here to handle cases when the device erroneously
* tries to receive more than is possible. This is usually
* the case of a broken device.
+ *
+ * The number of allocated pages for big packet is
+ * vi->big_packets_num_skbfrags + 1, the start of first page is
+ * for virtio header, the remaining is for data. We need to ensure
+ * the remaining len does not go out of the allocated pages.
+ * Please refer to add_recvbuf_big for more details on big packet
+ * buffer allocation.
*/
- if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) {
+ BUG_ON(offset >= PAGE_SIZE);
+ max_remaining_len = (unsigned int)PAGE_SIZE - offset;
+ max_remaining_len += vi->big_packets_num_skbfrags * PAGE_SIZE;
+ if (unlikely(len > max_remaining_len)) {
net_dbg_ratelimited("%s: too much data\n", skb->dev->name);
dev_kfree_skb(skb);
return NULL;
}
- BUG_ON(offset >= PAGE_SIZE);
+
while (len) {
unsigned int frag_size = min((unsigned)PAGE_SIZE - offset, len);
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset,
--
2.43.0
When GSO tunnel is negotiated virtio_net_hdr_tnl_from_skb() tries to
initialize the tunnel metadata but forget to zero unused rxhash
fields. This may leak information to another side. Fixing this by
zeroing the unused hash fields.
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Fixes: a2fb4bc4e2a6a ("net: implement virtio helpers to handle UDP GSO tunneling")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Jason Wang <jasowang(a)redhat.com>
---
include/linux/virtio_net.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
index 20e0584db1dd..4d1780848d0e 100644
--- a/include/linux/virtio_net.h
+++ b/include/linux/virtio_net.h
@@ -401,6 +401,10 @@ virtio_net_hdr_tnl_from_skb(const struct sk_buff *skb,
if (!tnl_hdr_negotiated)
return -EINVAL;
+ vhdr->hash_hdr.hash_value = 0;
+ vhdr->hash_hdr.hash_report = 0;
+ vhdr->hash_hdr.padding = 0;
+
/* Let the basic parsing deal with plain GSO features. */
skb_shinfo(skb)->gso_type &= ~tnl_gso_type;
ret = virtio_net_hdr_from_skb(skb, hdr, true, false, vlan_hlen);
--
2.42.0
vb2_ioctl_remove_bufs() call manipulates queue internal buffer list,
potentially overwriting some pointers used by the legacy fileio access
mode. Forbid that ioctl when fileio is active to protect internal queue
state between subsequent read/write calls.
CC: stable(a)vger.kernel.org
Fixes: a3293a85381e ("media: v4l2: Add REMOVE_BUFS ioctl")
Reported-by: Shuangpeng Bai <SJB7183(a)psu.edu>
Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
---
v4:
- got back to simple vb2_fileio_is_active() check as in v1, as relying on
vb2_verify_memory_type() misses some corner cases important to v4l2
compliance
v3: https://lore.kernel.org/all/20251023113052.1303082-1-m.szyprowski@samsung.c…
- moved vb2_verify_memory_type() check after (d->count == 0) check to pass v4l2
compliance
v2: https://lore.kernel.org/all/20251020160121.1985354-1-m.szyprowski@samsung.c…
- dropped a change to vb2_ioctl_create_bufs(), as it is already handled
by the vb2_verify_memory_type() call
- replaced queue->type check in vb2_ioctl_remove_bufs() by a call to
vb2_verify_memory_type() which covers all cases
v1: https://lore.kernel.org/all/20251016111154.993949-1-m.szyprowski@samsung.co…
---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index d911021c1bb0..83862d57b126 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -1010,6 +1010,11 @@ int vb2_ioctl_remove_bufs(struct file *file, void *priv,
if (vb2_queue_is_busy(vdev->queue, file))
return -EBUSY;
+ if (vb2_fileio_is_active(vdev->queue)) {
+ dprintk(vdev->queue, 1, "file io in progress\n");
+ return -EBUSY;
+ }
+
return vb2_core_remove_bufs(vdev->queue, d->index, d->count);
}
EXPORT_SYMBOL_GPL(vb2_ioctl_remove_bufs);
--
2.34.1
From: Stefano Garzarella <sgarzare(a)redhat.com>
Syzbot reported a potential lock inversion deadlock between
vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.
The issue was introduced by commit 687aa0c5581b ("vsock: Fix
transport_* TOCTOU") which added vsock_register_mutex locking in
vsock_assign_transport() around the transport->release() call, that can
call vsock_linger(). vsock_assign_transport() can be called with sk_lock
held. vsock_linger() calls sk_wait_event() that temporarily releases and
re-acquires sk_lock. During this window, if another thread hold
vsock_register_mutex while trying to acquire sk_lock, a circular
dependency is created.
Fix this by releasing vsock_register_mutex before calling
transport->release() and vsock_deassign_transport(). This is safe
because we don't need to hold vsock_register_mutex while releasing the
old transport, and we ensure the new transport won't disappear by
obtaining a module reference first via try_module_get().
Reported-by: syzbot+10e35716f8e4929681fa(a)syzkaller.appspotmail.com
Tested-by: syzbot+10e35716f8e4929681fa(a)syzkaller.appspotmail.com
Fixes: 687aa0c5581b ("vsock: Fix transport_* TOCTOU")
Cc: mhal(a)rbox.co
Cc: stable(a)vger.kernel.org
Signed-off-by: Stefano Garzarella <sgarzare(a)redhat.com>
---
net/vmw_vsock/af_vsock.c | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 4c2db6cca557..76763247a377 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -487,12 +487,26 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
goto err;
}
- if (vsk->transport) {
- if (vsk->transport == new_transport) {
- ret = 0;
- goto err;
- }
+ if (vsk->transport && vsk->transport == new_transport) {
+ ret = 0;
+ goto err;
+ }
+ /* We increase the module refcnt to prevent the transport unloading
+ * while there are open sockets assigned to it.
+ */
+ if (!new_transport || !try_module_get(new_transport->module)) {
+ ret = -ENODEV;
+ goto err;
+ }
+
+ /* It's safe to release the mutex after a successful try_module_get().
+ * Whichever transport `new_transport` points at, it won't go away until
+ * the last module_put() below or in vsock_deassign_transport().
+ */
+ mutex_unlock(&vsock_register_mutex);
+
+ if (vsk->transport) {
/* transport->release() must be called with sock lock acquired.
* This path can only be taken during vsock_connect(), where we
* have already held the sock lock. In the other cases, this
@@ -512,20 +526,6 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
vsk->peer_shutdown = 0;
}
- /* We increase the module refcnt to prevent the transport unloading
- * while there are open sockets assigned to it.
- */
- if (!new_transport || !try_module_get(new_transport->module)) {
- ret = -ENODEV;
- goto err;
- }
-
- /* It's safe to release the mutex after a successful try_module_get().
- * Whichever transport `new_transport` points at, it won't go away until
- * the last module_put() below or in vsock_deassign_transport().
- */
- mutex_unlock(&vsock_register_mutex);
-
if (sk->sk_type == SOCK_SEQPACKET) {
if (!new_transport->seqpacket_allow ||
!new_transport->seqpacket_allow(remote_cid)) {
--
2.51.0
From: Johannes Berg <johannes.berg(a)intel.com>
commit eb29b4ffafb20281624dcd2cbb768d6f30edf600 upstream.
The order of actions taken for debug was implemented incorrectly.
Now we implemented the dump split and do the FW reset only in the
middle of the dump (rather than the FW killing itself on error.)
As a result, some of the actions taken when applying the config
will now crash the device, so we need to fix the order.
Fixes: 1a5daead217c ("iwlwifi: yoyo: support for ROM usniffer")
Fixes: f21baf244112 ("iwlwifi: yoyo: fw debug config from context info and preset")
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com>
Link: https://patch.msgid.link/20250308231427.6de7fa8e63ed.I40632c48e2a67a8aca05d…
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
[ kovalev: bp to fix CVE-2025-38045; added Fixes tags ]
Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org>
---
drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
index ab80c79e35bc..d6d9f60839db 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/*
- * Copyright (C) 2018-2022 Intel Corporation
+ * Copyright (C) 2018-2025 Intel Corporation
*/
#include <linux/firmware.h>
#include "iwl-drv.h"
@@ -1363,15 +1363,15 @@ void _iwl_dbg_tlv_time_point(struct iwl_fw_runtime *fwrt,
switch (tp_id) {
case IWL_FW_INI_TIME_POINT_EARLY:
iwl_dbg_tlv_init_cfg(fwrt);
- iwl_dbg_tlv_apply_config(fwrt, conf_list);
iwl_dbg_tlv_update_drams(fwrt);
iwl_dbg_tlv_tp_trigger(fwrt, sync, trig_list, tp_data, NULL);
+ iwl_dbg_tlv_apply_config(fwrt, conf_list);
break;
case IWL_FW_INI_TIME_POINT_AFTER_ALIVE:
iwl_dbg_tlv_apply_buffers(fwrt);
iwl_dbg_tlv_send_hcmds(fwrt, hcmd_list);
- iwl_dbg_tlv_apply_config(fwrt, conf_list);
iwl_dbg_tlv_tp_trigger(fwrt, sync, trig_list, tp_data, NULL);
+ iwl_dbg_tlv_apply_config(fwrt, conf_list);
break;
case IWL_FW_INI_TIME_POINT_PERIODIC:
iwl_dbg_tlv_set_periodic_trigs(fwrt);
@@ -1381,14 +1381,14 @@ void _iwl_dbg_tlv_time_point(struct iwl_fw_runtime *fwrt,
case IWL_FW_INI_TIME_POINT_MISSED_BEACONS:
case IWL_FW_INI_TIME_POINT_FW_DHC_NOTIFICATION:
iwl_dbg_tlv_send_hcmds(fwrt, hcmd_list);
- iwl_dbg_tlv_apply_config(fwrt, conf_list);
iwl_dbg_tlv_tp_trigger(fwrt, sync, trig_list, tp_data,
iwl_dbg_tlv_check_fw_pkt);
+ iwl_dbg_tlv_apply_config(fwrt, conf_list);
break;
default:
iwl_dbg_tlv_send_hcmds(fwrt, hcmd_list);
- iwl_dbg_tlv_apply_config(fwrt, conf_list);
iwl_dbg_tlv_tp_trigger(fwrt, sync, trig_list, tp_data, NULL);
+ iwl_dbg_tlv_apply_config(fwrt, conf_list);
break;
}
}
--
2.50.1
Hi,
After a stable kernel update, the hwclock command seems no longer
functional on my SPARC system with an ST M48T59Y-70PC1 RTC:
# hwclock
[...long delay...]
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
On prior kernels, there is no problem:
# hwclock
2025-10-22 22:21:04.806992-04:00
I reproduced the same failure on 6.18-rc2 and bisected to this commit:
commit 795cda8338eab036013314dbc0b04aae728880ab
Author: Esben Haabendal <esben(a)geanix.com>
Date: Fri May 16 09:23:35 2025 +0200
rtc: interface: Fix long-standing race when setting alarm
This commit was backported to all current 6.x stable branches,
as well as 5.15.x, so they all have the same regression.
Reverting this commit on top of 6.18-rc2 corrects the problem.
Let me know if you need any more info!
Thanks,
Nick
From: Christian Hitz <christian.hitz(a)bbv.ch>
led_banks contains LED module number(s) that should be grouped into the
module bank. led_banks is 0-initialized.
By checking the led_banks entries for 0, un-set entries are detected.
But a 0-entry also indicates that LED module 0 should be grouped into the
module bank.
By only iterating over the available entries no check for unused entries
is required and LED module 0 can be added to bank.
Signed-off-by: Christian Hitz <christian.hitz(a)bbv.ch>
Cc: stable(a)vger.kernel.org
---
drivers/leds/leds-lp50xx.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
index 94f8ef6b482c..d50c7f3e8f99 100644
--- a/drivers/leds/leds-lp50xx.c
+++ b/drivers/leds/leds-lp50xx.c
@@ -341,17 +341,15 @@ static int lp50xx_brightness_set(struct led_classdev *cdev,
return ret;
}
-static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[])
+static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[], int num_leds)
{
u8 led_config_lo, led_config_hi;
u32 bank_enable_mask = 0;
int ret;
int i;
- for (i = 0; i < priv->chip_info->max_modules; i++) {
- if (led_banks[i])
- bank_enable_mask |= (1 << led_banks[i]);
- }
+ for (i = 0; i < num_leds; i++)
+ bank_enable_mask |= (1 << led_banks[i]);
led_config_lo = bank_enable_mask;
led_config_hi = bank_enable_mask >> 8;
@@ -405,7 +403,7 @@ static int lp50xx_probe_leds(struct fwnode_handle *child, struct lp50xx *priv,
return ret;
}
- ret = lp50xx_set_banks(priv, led_banks);
+ ret = lp50xx_set_banks(priv, led_banks, num_leds);
if (ret) {
dev_err(priv->dev, "Cannot setup banked LEDs\n");
return ret;
--
2.51.0
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 9daa5a8795865f9a3c93d8d1066785b07ded6073
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101905-removal-wistful-dd49@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9daa5a8795865f9a3c93d8d1066785b07ded6073 Mon Sep 17 00:00:00 2001
From: Vineeth Vijayan <vneethv(a)linux.ibm.com>
Date: Wed, 1 Oct 2025 15:38:17 +0200
Subject: [PATCH] s390/cio: Update purge function to unregister the unused
subchannels
Starting with 'commit 2297791c92d0 ("s390/cio: dont unregister
subchannel from child-drivers")', cio no longer unregisters
subchannels when the attached device is invalid or unavailable.
As an unintended side-effect, the cio_ignore purge function no longer
removes subchannels for devices on the cio_ignore list if no CCW device
is attached. This situation occurs when a CCW device is non-operational
or unavailable
To ensure the same outcome of the purge function as when the
current cio_ignore list had been active during boot, update the purge
function to remove I/O subchannels without working CCW devices if the
associated device number is found on the cio_ignore list.
Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
Suggested-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index fb2c07cb4d3d..4b2dae6eb376 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1316,23 +1316,34 @@ void ccw_device_schedule_recovery(void)
spin_unlock_irqrestore(&recovery_lock, flags);
}
-static int purge_fn(struct device *dev, void *data)
+static int purge_fn(struct subchannel *sch, void *data)
{
- struct ccw_device *cdev = to_ccwdev(dev);
- struct ccw_dev_id *id = &cdev->private->dev_id;
- struct subchannel *sch = to_subchannel(cdev->dev.parent);
+ struct ccw_device *cdev;
- spin_lock_irq(cdev->ccwlock);
- if (is_blacklisted(id->ssid, id->devno) &&
- (cdev->private->state == DEV_STATE_OFFLINE) &&
- (atomic_cmpxchg(&cdev->private->onoff, 0, 1) == 0)) {
- CIO_MSG_EVENT(3, "ccw: purging 0.%x.%04x\n", id->ssid,
- id->devno);
+ spin_lock_irq(&sch->lock);
+ if (sch->st != SUBCHANNEL_TYPE_IO || !sch->schib.pmcw.dnv)
+ goto unlock;
+
+ if (!is_blacklisted(sch->schid.ssid, sch->schib.pmcw.dev))
+ goto unlock;
+
+ cdev = sch_get_cdev(sch);
+ if (cdev) {
+ if (cdev->private->state != DEV_STATE_OFFLINE)
+ goto unlock;
+
+ if (atomic_cmpxchg(&cdev->private->onoff, 0, 1) != 0)
+ goto unlock;
ccw_device_sched_todo(cdev, CDEV_TODO_UNREG);
- css_sched_sch_todo(sch, SCH_TODO_UNREG);
atomic_set(&cdev->private->onoff, 0);
}
- spin_unlock_irq(cdev->ccwlock);
+
+ css_sched_sch_todo(sch, SCH_TODO_UNREG);
+ CIO_MSG_EVENT(3, "ccw: purging 0.%x.%04x%s\n", sch->schid.ssid,
+ sch->schib.pmcw.dev, cdev ? "" : " (no cdev)");
+
+unlock:
+ spin_unlock_irq(&sch->lock);
/* Abort loop in case of pending signal. */
if (signal_pending(current))
return -EINTR;
@@ -1348,7 +1359,7 @@ static int purge_fn(struct device *dev, void *data)
int ccw_purge_blacklisted(void)
{
CIO_MSG_EVENT(2, "ccw: purging blacklisted devices\n");
- bus_for_each_dev(&ccw_bus_type, NULL, NULL, purge_fn);
+ for_each_subchannel_staged(purge_fn, NULL, NULL);
return 0;
}
The patch below does not apply to the 5.15-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.15.y
git checkout FETCH_HEAD
git cherry-pick -x 9daa5a8795865f9a3c93d8d1066785b07ded6073
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101905-depress-banjo-bc7e@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9daa5a8795865f9a3c93d8d1066785b07ded6073 Mon Sep 17 00:00:00 2001
From: Vineeth Vijayan <vneethv(a)linux.ibm.com>
Date: Wed, 1 Oct 2025 15:38:17 +0200
Subject: [PATCH] s390/cio: Update purge function to unregister the unused
subchannels
Starting with 'commit 2297791c92d0 ("s390/cio: dont unregister
subchannel from child-drivers")', cio no longer unregisters
subchannels when the attached device is invalid or unavailable.
As an unintended side-effect, the cio_ignore purge function no longer
removes subchannels for devices on the cio_ignore list if no CCW device
is attached. This situation occurs when a CCW device is non-operational
or unavailable
To ensure the same outcome of the purge function as when the
current cio_ignore list had been active during boot, update the purge
function to remove I/O subchannels without working CCW devices if the
associated device number is found on the cio_ignore list.
Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
Suggested-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index fb2c07cb4d3d..4b2dae6eb376 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1316,23 +1316,34 @@ void ccw_device_schedule_recovery(void)
spin_unlock_irqrestore(&recovery_lock, flags);
}
-static int purge_fn(struct device *dev, void *data)
+static int purge_fn(struct subchannel *sch, void *data)
{
- struct ccw_device *cdev = to_ccwdev(dev);
- struct ccw_dev_id *id = &cdev->private->dev_id;
- struct subchannel *sch = to_subchannel(cdev->dev.parent);
+ struct ccw_device *cdev;
- spin_lock_irq(cdev->ccwlock);
- if (is_blacklisted(id->ssid, id->devno) &&
- (cdev->private->state == DEV_STATE_OFFLINE) &&
- (atomic_cmpxchg(&cdev->private->onoff, 0, 1) == 0)) {
- CIO_MSG_EVENT(3, "ccw: purging 0.%x.%04x\n", id->ssid,
- id->devno);
+ spin_lock_irq(&sch->lock);
+ if (sch->st != SUBCHANNEL_TYPE_IO || !sch->schib.pmcw.dnv)
+ goto unlock;
+
+ if (!is_blacklisted(sch->schid.ssid, sch->schib.pmcw.dev))
+ goto unlock;
+
+ cdev = sch_get_cdev(sch);
+ if (cdev) {
+ if (cdev->private->state != DEV_STATE_OFFLINE)
+ goto unlock;
+
+ if (atomic_cmpxchg(&cdev->private->onoff, 0, 1) != 0)
+ goto unlock;
ccw_device_sched_todo(cdev, CDEV_TODO_UNREG);
- css_sched_sch_todo(sch, SCH_TODO_UNREG);
atomic_set(&cdev->private->onoff, 0);
}
- spin_unlock_irq(cdev->ccwlock);
+
+ css_sched_sch_todo(sch, SCH_TODO_UNREG);
+ CIO_MSG_EVENT(3, "ccw: purging 0.%x.%04x%s\n", sch->schid.ssid,
+ sch->schib.pmcw.dev, cdev ? "" : " (no cdev)");
+
+unlock:
+ spin_unlock_irq(&sch->lock);
/* Abort loop in case of pending signal. */
if (signal_pending(current))
return -EINTR;
@@ -1348,7 +1359,7 @@ static int purge_fn(struct device *dev, void *data)
int ccw_purge_blacklisted(void)
{
CIO_MSG_EVENT(2, "ccw: purging blacklisted devices\n");
- bus_for_each_dev(&ccw_bus_type, NULL, NULL, purge_fn);
+ for_each_subchannel_staged(purge_fn, NULL, NULL);
return 0;
}
The RFCOMM driver confuses the local and remote modem control signals,
which specifically means that the reported DTR and RTS state will
instead reflect the remote end (i.e. DSR and CTS).
This issue dates back to the original driver (and a follow-on update)
merged in 2002, which resulted in a non-standard implementation of
TIOCMSET that allowed controlling also the TS07.10 IC and DV signals by
mapping them to the RI and DCD input flags, while TIOCMGET failed to
return the actual state of DTR and RTS.
Note that the bogus control of input signals in tiocmset() is just
dead code as those flags will have been masked out by the tty layer
since 2003.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable(a)vger.kernel.org
Signed-off-by: Johan Hovold <johan(a)kernel.org>
---
net/bluetooth/rfcomm/tty.c | 25 ++++++++++---------------
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 376ce6de84be..f20f043cc9b5 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -643,8 +643,8 @@ static void rfcomm_dev_modem_status(struct rfcomm_dlc *dlc, u8 v24_sig)
tty_port_tty_hangup(&dev->port, true);
dev->modem_status =
- ((v24_sig & RFCOMM_V24_RTC) ? (TIOCM_DSR | TIOCM_DTR) : 0) |
- ((v24_sig & RFCOMM_V24_RTR) ? (TIOCM_RTS | TIOCM_CTS) : 0) |
+ ((v24_sig & RFCOMM_V24_RTC) ? TIOCM_DSR : 0) |
+ ((v24_sig & RFCOMM_V24_RTR) ? TIOCM_CTS : 0) |
((v24_sig & RFCOMM_V24_IC) ? TIOCM_RI : 0) |
((v24_sig & RFCOMM_V24_DV) ? TIOCM_CD : 0);
}
@@ -1055,10 +1055,13 @@ static void rfcomm_tty_hangup(struct tty_struct *tty)
static int rfcomm_tty_tiocmget(struct tty_struct *tty)
{
struct rfcomm_dev *dev = tty->driver_data;
+ u8 v24_sig;
BT_DBG("tty %p dev %p", tty, dev);
- return dev->modem_status;
+ rfcomm_dlc_get_modem_status(dlc, &v24_sig);
+
+ return (v24_sig & (TIOCM_DTR | TIOCM_RTS)) | dev->modem_status;
}
static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigned int clear)
@@ -1071,23 +1074,15 @@ static int rfcomm_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigne
rfcomm_dlc_get_modem_status(dlc, &v24_sig);
- if (set & TIOCM_DSR || set & TIOCM_DTR)
+ if (set & TIOCM_DTR)
v24_sig |= RFCOMM_V24_RTC;
- if (set & TIOCM_RTS || set & TIOCM_CTS)
+ if (set & TIOCM_RTS)
v24_sig |= RFCOMM_V24_RTR;
- if (set & TIOCM_RI)
- v24_sig |= RFCOMM_V24_IC;
- if (set & TIOCM_CD)
- v24_sig |= RFCOMM_V24_DV;
- if (clear & TIOCM_DSR || clear & TIOCM_DTR)
+ if (clear & TIOCM_DTR)
v24_sig &= ~RFCOMM_V24_RTC;
- if (clear & TIOCM_RTS || clear & TIOCM_CTS)
+ if (clear & TIOCM_RTS)
v24_sig &= ~RFCOMM_V24_RTR;
- if (clear & TIOCM_RI)
- v24_sig &= ~RFCOMM_V24_IC;
- if (clear & TIOCM_CD)
- v24_sig &= ~RFCOMM_V24_DV;
rfcomm_dlc_set_modem_status(dlc, v24_sig);
--
2.49.1
The patch below does not apply to the 6.6-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.6.y
git checkout FETCH_HEAD
git cherry-pick -x 9daa5a8795865f9a3c93d8d1066785b07ded6073
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025101904-seltzer-landslide-60b6@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9daa5a8795865f9a3c93d8d1066785b07ded6073 Mon Sep 17 00:00:00 2001
From: Vineeth Vijayan <vneethv(a)linux.ibm.com>
Date: Wed, 1 Oct 2025 15:38:17 +0200
Subject: [PATCH] s390/cio: Update purge function to unregister the unused
subchannels
Starting with 'commit 2297791c92d0 ("s390/cio: dont unregister
subchannel from child-drivers")', cio no longer unregisters
subchannels when the attached device is invalid or unavailable.
As an unintended side-effect, the cio_ignore purge function no longer
removes subchannels for devices on the cio_ignore list if no CCW device
is attached. This situation occurs when a CCW device is non-operational
or unavailable
To ensure the same outcome of the purge function as when the
current cio_ignore list had been active during boot, update the purge
function to remove I/O subchannels without working CCW devices if the
associated device number is found on the cio_ignore list.
Fixes: 2297791c92d0 ("s390/cio: dont unregister subchannel from child-drivers")
Suggested-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar(a)linux.ibm.com>
Signed-off-by: Vineeth Vijayan <vneethv(a)linux.ibm.com>
Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com>
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index fb2c07cb4d3d..4b2dae6eb376 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -1316,23 +1316,34 @@ void ccw_device_schedule_recovery(void)
spin_unlock_irqrestore(&recovery_lock, flags);
}
-static int purge_fn(struct device *dev, void *data)
+static int purge_fn(struct subchannel *sch, void *data)
{
- struct ccw_device *cdev = to_ccwdev(dev);
- struct ccw_dev_id *id = &cdev->private->dev_id;
- struct subchannel *sch = to_subchannel(cdev->dev.parent);
+ struct ccw_device *cdev;
- spin_lock_irq(cdev->ccwlock);
- if (is_blacklisted(id->ssid, id->devno) &&
- (cdev->private->state == DEV_STATE_OFFLINE) &&
- (atomic_cmpxchg(&cdev->private->onoff, 0, 1) == 0)) {
- CIO_MSG_EVENT(3, "ccw: purging 0.%x.%04x\n", id->ssid,
- id->devno);
+ spin_lock_irq(&sch->lock);
+ if (sch->st != SUBCHANNEL_TYPE_IO || !sch->schib.pmcw.dnv)
+ goto unlock;
+
+ if (!is_blacklisted(sch->schid.ssid, sch->schib.pmcw.dev))
+ goto unlock;
+
+ cdev = sch_get_cdev(sch);
+ if (cdev) {
+ if (cdev->private->state != DEV_STATE_OFFLINE)
+ goto unlock;
+
+ if (atomic_cmpxchg(&cdev->private->onoff, 0, 1) != 0)
+ goto unlock;
ccw_device_sched_todo(cdev, CDEV_TODO_UNREG);
- css_sched_sch_todo(sch, SCH_TODO_UNREG);
atomic_set(&cdev->private->onoff, 0);
}
- spin_unlock_irq(cdev->ccwlock);
+
+ css_sched_sch_todo(sch, SCH_TODO_UNREG);
+ CIO_MSG_EVENT(3, "ccw: purging 0.%x.%04x%s\n", sch->schid.ssid,
+ sch->schib.pmcw.dev, cdev ? "" : " (no cdev)");
+
+unlock:
+ spin_unlock_irq(&sch->lock);
/* Abort loop in case of pending signal. */
if (signal_pending(current))
return -EINTR;
@@ -1348,7 +1359,7 @@ static int purge_fn(struct device *dev, void *data)
int ccw_purge_blacklisted(void)
{
CIO_MSG_EVENT(2, "ccw: purging blacklisted devices\n");
- bus_for_each_dev(&ccw_bus_type, NULL, NULL, purge_fn);
+ for_each_subchannel_staged(purge_fn, NULL, NULL);
return 0;
}
If you need to cancel your Spirit Airlines flight, do not worry — the process is fairly straightforward! You can call Spirit Airlines directly at 📞 1-866-284-3022. Whether you are canceling due to personal reasons, weather disruptions, or a change in plans, this guide will walk you through every step. While cancellations can be made online, calling may provide faster support and more detailed assistance.
📍 Step 1: Find Your Flight Information
Before you call or go online, make sure you have the following information ready:
✅ Your booking confirmation number
✅ The name on the reservation
✅ Your flight details (departure date, destination, etc.)
Having this information handy will make the process quicker, especially if you are speaking with a Spirit Airlines representative at 📞 1-866-284-3022.
📞 Step 2: Call Spirit Airlines Customer Support
The easiest and most direct way to cancel your flight is by calling Spirit Airlines customer service at 1-866-284-3022. This line is available to assist with cancellations, modifications, and refund requests.
🧑💼 When you call:
• You will be prompted to enter your confirmation number
• Select the option for "existing reservation"
• Ask to speak to a live representative if needed
Pro tip: Call during off-peak hours (early mornings or late evenings) to avoid long wait times.
🌐 Step 3: Cancel Online (Alternative Option)
If you prefer to cancel online, follow these steps:
1. Go to the official Volaris Airlines website
2. Click on "My Trips" at the top of the homepage
3. Enter your last name and confirmation code
4. Find the reservation you want to cancel
5. Click on “Cancel” and follow the on-screen instructions
However, if you run into any issues or if your fare type does not allow online cancellations, don’t hesitate to call 1-866-284-3022 for support.
💸 Step 4: Check for Refund or Credit Eligibility
Spirit Airlines is a low-cost carrier, and refund policies can vary depending on the fare type. Here is a quick breakdown:
🟢 WORKS Bundle or Refundable Tickets: Eligible for a full refund
🟡 Standard Tickets: May not be refundable but can be canceled for a credit (valid for 90 days)
🔴 Basic Fare or Promo Tickets: Often non-refundable
To clarify your eligibility, it is best to speak to a Porter representative directly at 📞 1-866-284-3022. They can explain whether you will receive a refund, a travel credit, or incur a cancellation fee.
⏱️ Step 5: Cancel Within 24 Hours (If Possible)
✅ If you booked your ticket less than 24 hours ago AND your flight is at least 7 days away, you are eligible for a full refund with no cancellation fees.
To take advantage of this policy, it is strongly advised to call 1-866-284-3022 right away and notify them that you fall within the 24-hour window.
📧 Step 6: Get Confirmation of Cancellation
Once your flight is canceled, make sure to:
📨 Check your email for a cancellation confirmation
💳 Verify if any refund or credit has been issued to your account
📅 Note the expiration date of any travel credit issued (typically valid for 90 days)
If you have not received confirmation within a few hours, call 📞 1-866-284-3022 again to follow up and ensure your cancellation was processed correctly.
🤔 Need Help? Contact Spirit Airlines Again
Porter’s website can sometimes be tricky or limited in functionality, especially for special fares or last-minute cancellations. That is why calling customer service at 📞 1-866-284-3022 is always the most reliable option. Their agents can also assist with:
• Modifying your travel dates
• Applying travel credits
• Rebooking future flights
• Answering policy-related questions
✍️ Final Thoughts
Canceling a Spirit Airlines flight does not have to be stressful. Whether you are canceling online or over the phone, knowing the process and your rights can save you time and money. Always keep the Porter customer service number 📞 1-866-284-3022 on hand for quick assistance and peace of mind.
🧭 Quick Recap:
• Prepare your booking info
• Try canceling online or via the Porter app
• For best results, call Porter directly at 📞 1-866-284-3022
• Check your eligibility for refunds or travel credits
• Always get a cancellation confirmation
✈️ Safe travels — or smooth cancellations — whichever your journey brings next!
If you need to cancel your Aeromexico Airlines flight, do not worry — the process is fairly straightforward! You can call Aeromexico Airlines directly at 📞 1-866-284-3022. Whether you are canceling due to personal reasons, weather disruptions, or a change in plans, this guide will walk you through every step. While cancellations can be made online, calling may provide faster support and more detailed assistance.
📍 Step 1: Find Your Flight Information
Before you call or go online, make sure you have the following information ready:
✅ Your booking confirmation number
✅ The name on the reservation
✅ Your flight details (departure date, destination, etc.)
Having this information handy will make the process quicker, especially if you are speaking with a Aeromexico Airlines representative at 📞 1-866-284-3022.
📞 Step 2: Call Aeromexico Airlines Customer Support
The easiest and most direct way to cancel your flight is by calling Aeromexico Airlines customer service at 1-866-284-3022. This line is available to assist with cancellations, modifications, and refund requests.
🧑💼 When you call:
• You will be prompted to enter your confirmation number
• Select the option for "existing reservation"
• Ask to speak to a live representative if needed
Pro tip: Call during off-peak hours (early mornings or late evenings) to avoid long wait times.
🌐 Step 3: Cancel Online (Alternative Option)
If you prefer to cancel online, follow these steps:
1. Go to the official Volaris Airlines website
2. Click on "My Trips" at the top of the homepage
3. Enter your last name and confirmation code
4. Find the reservation you want to cancel
5. Click on “Cancel” and follow the on-screen instructions
However, if you run into any issues or if your fare type does not allow online cancellations, don’t hesitate to call 1-866-284-3022 for support.
💸 Step 4: Check for Refund or Credit Eligibility
Aeromexico Airlines is a low-cost carrier, and refund policies can vary depending on the fare type. Here is a quick breakdown:
🟢 WORKS Bundle or Refundable Tickets: Eligible for a full refund
🟡 Standard Tickets: May not be refundable but can be canceled for a credit (valid for 90 days)
🔴 Basic Fare or Promo Tickets: Often non-refundable
To clarify your eligibility, it is best to speak to a Porter representative directly at 📞 1-866-284-3022. They can explain whether you will receive a refund, a travel credit, or incur a cancellation fee.
⏱️ Step 5: Cancel Within 24 Hours (If Possible)
✅ If you booked your ticket less than 24 hours ago AND your flight is at least 7 days away, you are eligible for a full refund with no cancellation fees.
To take advantage of this policy, it is strongly advised to call 1-866-284-3022 right away and notify them that you fall within the 24-hour window.
📧 Step 6: Get Confirmation of Cancellation
Once your flight is canceled, make sure to:
📨 Check your email for a cancellation confirmation
💳 Verify if any refund or credit has been issued to your account
📅 Note the expiration date of any travel credit issued (typically valid for 90 days)
If you have not received confirmation within a few hours, call 📞 1-866-284-3022 again to follow up and ensure your cancellation was processed correctly.
🤔 Need Help? Contact Aeromexico Airlines Again
Porter’s website can sometimes be tricky or limited in functionality, especially for special fares or last-minute cancellations. That is why calling customer service at 📞 1-866-284-3022 is always the most reliable option. Their agents can also assist with:
• Modifying your travel dates
• Applying travel credits
• Rebooking future flights
• Answering policy-related questions
✍️ Final Thoughts
Canceling a Aeromexico Airlines flight does not have to be stressful. Whether you are canceling online or over the phone, knowing the process and your rights can save you time and money. Always keep the Porter customer service number 📞 1-866-284-3022 on hand for quick assistance and peace of mind.
🧭 Quick Recap:
• Prepare your booking info
• Try canceling online or via the Porter app
• For best results, call Porter directly at 📞 1-866-284-3022
• Check your eligibility for refunds or travel credits
• Always get a cancellation confirmation
✈️ Safe travels — or smooth cancellations — whichever your journey brings next!
If you need to cancel your Avelo Airlines flight, do not worry — the process is fairly straightforward! You can call Avelo Airlines directly at 📞 1-866-284-3022. Whether you are canceling due to personal reasons, weather disruptions, or a change in plans, this guide will walk you through every step. While cancellations can be made online, calling may provide faster support and more detailed assistance.
📍 Step 1: Find Your Flight Information
Before you call or go online, make sure you have the following information ready:
✅ Your booking confirmation number
✅ The name on the reservation
✅ Your flight details (departure date, destination, etc.)
Having this information handy will make the process quicker, especially if you are speaking with a Avelo Airlines representative at 📞 1-866-284-3022.
📞 Step 2: Call Avelo Airlines Customer Support
The easiest and most direct way to cancel your flight is by calling Avelo Airlines customer service at 1-866-284-3022. This line is available to assist with cancellations, modifications, and refund requests.
🧑💼 When you call:
• You will be prompted to enter your confirmation number
• Select the option for "existing reservation"
• Ask to speak to a live representative if needed
Pro tip: Call during off-peak hours (early mornings or late evenings) to avoid long wait times.
🌐 Step 3: Cancel Online (Alternative Option)
If you prefer to cancel online, follow these steps:
1. Go to the official Volaris Airlines website
2. Click on "My Trips" at the top of the homepage
3. Enter your last name and confirmation code
4. Find the reservation you want to cancel
5. Click on “Cancel” and follow the on-screen instructions
However, if you run into any issues or if your fare type does not allow online cancellations, don’t hesitate to call 1-866-284-3022 for support.
💸 Step 4: Check for Refund or Credit Eligibility
Avelo Airlines is a low-cost carrier, and refund policies can vary depending on the fare type. Here is a quick breakdown:
🟢 WORKS Bundle or Refundable Tickets: Eligible for a full refund
🟡 Standard Tickets: May not be refundable but can be canceled for a credit (valid for 90 days)
🔴 Basic Fare or Promo Tickets: Often non-refundable
To clarify your eligibility, it is best to speak to a Porter representative directly at 📞 1-866-284-3022. They can explain whether you will receive a refund, a travel credit, or incur a cancellation fee.
⏱️ Step 5: Cancel Within 24 Hours (If Possible)
✅ If you booked your ticket less than 24 hours ago AND your flight is at least 7 days away, you are eligible for a full refund with no cancellation fees.
To take advantage of this policy, it is strongly advised to call 1-866-284-3022 right away and notify them that you fall within the 24-hour window.
📧 Step 6: Get Confirmation of Cancellation
Once your flight is canceled, make sure to:
📨 Check your email for a cancellation confirmation
💳 Verify if any refund or credit has been issued to your account
📅 Note the expiration date of any travel credit issued (typically valid for 90 days)
If you have not received confirmation within a few hours, call 📞 1-866-284-3022 again to follow up and ensure your cancellation was processed correctly.
🤔 Need Help? Contact Avelo Airlines Again
Porter’s website can sometimes be tricky or limited in functionality, especially for special fares or last-minute cancellations. That is why calling customer service at 📞 1-866-284-3022 is always the most reliable option. Their agents can also assist with:
• Modifying your travel dates
• Applying travel credits
• Rebooking future flights
• Answering policy-related questions
✍️ Final Thoughts
Canceling a Avelo Airlines flight does not have to be stressful. Whether you are canceling online or over the phone, knowing the process and your rights can save you time and money. Always keep the Porter customer service number 📞 1-866-284-3022 on hand for quick assistance and peace of mind.
🧭 Quick Recap:
• Prepare your booking info
• Try canceling online or via the Porter app
• For best results, call Porter directly at 📞 1-866-284-3022
• Check your eligibility for refunds or travel credits
• Always get a cancellation confirmation
✈️ Safe travels — or smooth cancellations — whichever your journey brings next!
If you need to cancel your Contour Airlines flight, do not worry — the process is fairly straightforward! You can call Contour Airlines directly at 📞 1-866-284-3022. Whether you are canceling due to personal reasons, weather disruptions, or a change in plans, this guide will walk you through every step. While cancellations can be made online, calling may provide faster support and more detailed assistance.
📍 Step 1: Find Your Flight Information
Before you call or go online, make sure you have the following information ready:
✅ Your booking confirmation number
✅ The name on the reservation
✅ Your flight details (departure date, destination, etc.)
Having this information handy will make the process quicker, especially if you are speaking with a Contour Airlines representative at 📞 1-866-284-3022.
📞 Step 2: Call Contour Airlines Customer Support
The easiest and most direct way to cancel your flight is by calling Contour Airlines customer service at 1-866-284-3022. This line is available to assist with cancellations, modifications, and refund requests.
🧑💼 When you call:
• You will be prompted to enter your confirmation number
• Select the option for "existing reservation"
• Ask to speak to a live representative if needed
Pro tip: Call during off-peak hours (early mornings or late evenings) to avoid long wait times.
🌐 Step 3: Cancel Online (Alternative Option)
If you prefer to cancel online, follow these steps:
1. Go to the official Volaris Airlines website
2. Click on "My Trips" at the top of the homepage
3. Enter your last name and confirmation code
4. Find the reservation you want to cancel
5. Click on “Cancel” and follow the on-screen instructions
However, if you run into any issues or if your fare type does not allow online cancellations, don’t hesitate to call 1-866-284-3022 for support.
💸 Step 4: Check for Refund or Credit Eligibility
Contour Airlines is a low-cost carrier, and refund policies can vary depending on the fare type. Here is a quick breakdown:
🟢 WORKS Bundle or Refundable Tickets: Eligible for a full refund
🟡 Standard Tickets: May not be refundable but can be canceled for a credit (valid for 90 days)
🔴 Basic Fare or Promo Tickets: Often non-refundable
To clarify your eligibility, it is best to speak to a Porter representative directly at 📞 1-866-284-3022. They can explain whether you will receive a refund, a travel credit, or incur a cancellation fee.
⏱️ Step 5: Cancel Within 24 Hours (If Possible)
✅ If you booked your ticket less than 24 hours ago AND your flight is at least 7 days away, you are eligible for a full refund with no cancellation fees.
To take advantage of this policy, it is strongly advised to call 1-866-284-3022 right away and notify them that you fall within the 24-hour window.
📧 Step 6: Get Confirmation of Cancellation
Once your flight is canceled, make sure to:
📨 Check your email for a cancellation confirmation
💳 Verify if any refund or credit has been issued to your account
📅 Note the expiration date of any travel credit issued (typically valid for 90 days)
If you have not received confirmation within a few hours, call 📞 1-866-284-3022 again to follow up and ensure your cancellation was processed correctly.
🤔 Need Help? Contact Contour Airlines Again
Porter’s website can sometimes be tricky or limited in functionality, especially for special fares or last-minute cancellations. That is why calling customer service at 📞 1-866-284-3022 is always the most reliable option. Their agents can also assist with:
• Modifying your travel dates
• Applying travel credits
• Rebooking future flights
• Answering policy-related questions
✍️ Final Thoughts
Canceling a Contour Airlines flight does not have to be stressful. Whether you are canceling online or over the phone, knowing the process and your rights can save you time and money. Always keep the Porter customer service number 📞 1-866-284-3022 on hand for quick assistance and peace of mind.
🧭 Quick Recap:
• Prepare your booking info
• Try canceling online or via the Porter app
• For best results, call Porter directly at 📞 1-866-284-3022
• Check your eligibility for refunds or travel credits
• Always get a cancellation confirmation
✈️ Safe travels — or smooth cancellations — whichever your journey brings next!
If you need to cancel your Condor Airlines flight, do not worry — the process is fairly straightforward! You can call Condor Airlines directly at 📞 1-866-284-3022. Whether you are canceling due to personal reasons, weather disruptions, or a change in plans, this guide will walk you through every step. While cancellations can be made online, calling may provide faster support and more detailed assistance.
📍 Step 1: Find Your Flight Information
Before you call or go online, make sure you have the following information ready:
✅ Your booking confirmation number
✅ The name on the reservation
✅ Your flight details (departure date, destination, etc.)
Having this information handy will make the process quicker, especially if you are speaking with a Condor Airlines representative at 📞 1-866-284-3022.
📞 Step 2: Call Condor Airlines Customer Support
The easiest and most direct way to cancel your flight is by calling Condor Airlines customer service at 1-866-284-3022. This line is available to assist with cancellations, modifications, and refund requests.
🧑💼 When you call:
• You will be prompted to enter your confirmation number
• Select the option for "existing reservation"
• Ask to speak to a live representative if needed
Pro tip: Call during off-peak hours (early mornings or late evenings) to avoid long wait times.
🌐 Step 3: Cancel Online (Alternative Option)
If you prefer to cancel online, follow these steps:
1. Go to the official Volaris Airlines website
2. Click on "My Trips" at the top of the homepage
3. Enter your last name and confirmation code
4. Find the reservation you want to cancel
5. Click on “Cancel” and follow the on-screen instructions
However, if you run into any issues or if your fare type does not allow online cancellations, don’t hesitate to call 1-866-284-3022 for support.
💸 Step 4: Check for Refund or Credit Eligibility
Condor Airlines is a low-cost carrier, and refund policies can vary depending on the fare type. Here is a quick breakdown:
🟢 WORKS Bundle or Refundable Tickets: Eligible for a full refund
🟡 Standard Tickets: May not be refundable but can be canceled for a credit (valid for 90 days)
🔴 Basic Fare or Promo Tickets: Often non-refundable
To clarify your eligibility, it is best to speak to a Porter representative directly at 📞 1-866-284-3022. They can explain whether you will receive a refund, a travel credit, or incur a cancellation fee.
⏱️ Step 5: Cancel Within 24 Hours (If Possible)
✅ If you booked your ticket less than 24 hours ago AND your flight is at least 7 days away, you are eligible for a full refund with no cancellation fees.
To take advantage of this policy, it is strongly advised to call 1-866-284-3022 right away and notify them that you fall within the 24-hour window.
📧 Step 6: Get Confirmation of Cancellation
Once your flight is canceled, make sure to:
📨 Check your email for a cancellation confirmation
💳 Verify if any refund or credit has been issued to your account
📅 Note the expiration date of any travel credit issued (typically valid for 90 days)
If you have not received confirmation within a few hours, call 📞 1-866-284-3022 again to follow up and ensure your cancellation was processed correctly.
🤔 Need Help? Contact Condor Airlines Again
Porter’s website can sometimes be tricky or limited in functionality, especially for special fares or last-minute cancellations. That is why calling customer service at 📞 1-866-284-3022 is always the most reliable option. Their agents can also assist with:
• Modifying your travel dates
• Applying travel credits
• Rebooking future flights
• Answering policy-related questions
✍️ Final Thoughts
Canceling a Condor Airlines flight does not have to be stressful. Whether you are canceling online or over the phone, knowing the process and your rights can save you time and money. Always keep the Porter customer service number 📞 1-866-284-3022 on hand for quick assistance and peace of mind.
🧭 Quick Recap:
• Prepare your booking info
• Try canceling online or via the Porter app
• For best results, call Porter directly at 📞 1-866-284-3022
• Check your eligibility for refunds or travel credits
• Always get a cancellation confirmation
✈️ Safe travels — or smooth cancellations — whichever your journey brings next!
If you need to cancel your Frontier Airlines flight, do not worry — the process is fairly straightforward! You can call Frontier Airlines directly at 📞 1-866-284-3022. Whether you are canceling due to personal reasons, weather disruptions, or a change in plans, this guide will walk you through every step. While cancellations can be made online, calling may provide faster support and more detailed assistance.
📍 Step 1: Find Your Flight Information
Before you call or go online, make sure you have the following information ready:
✅ Your booking confirmation number
✅ The name on the reservation
✅ Your flight details (departure date, destination, etc.)
Having this information handy will make the process quicker, especially if you are speaking with a Frontier Airlines representative at 📞 1-866-284-3022.
📞 Step 2: Call Frontier Airlines Customer Support
The easiest and most direct way to cancel your flight is by calling Frontier Airlines customer service at 1-866-284-3022. This line is available to assist with cancellations, modifications, and refund requests.
🧑💼 When you call:
• You will be prompted to enter your confirmation number
• Select the option for "existing reservation"
• Ask to speak to a live representative if needed
Pro tip: Call during off-peak hours (early mornings or late evenings) to avoid long wait times.
🌐 Step 3: Cancel Online (Alternative Option)
If you prefer to cancel online, follow these steps:
1. Go to the official Volaris Airlines website
2. Click on "My Trips" at the top of the homepage
3. Enter your last name and confirmation code
4. Find the reservation you want to cancel
5. Click on “Cancel” and follow the on-screen instructions
However, if you run into any issues or if your fare type does not allow online cancellations, don’t hesitate to call 1-866-284-3022 for support.
💸 Step 4: Check for Refund or Credit Eligibility
Frontier Airlines is a low-cost carrier, and refund policies can vary depending on the fare type. Here is a quick breakdown:
🟢 WORKS Bundle or Refundable Tickets: Eligible for a full refund
🟡 Standard Tickets: May not be refundable but can be canceled for a credit (valid for 90 days)
🔴 Basic Fare or Promo Tickets: Often non-refundable
To clarify your eligibility, it is best to speak to a Porter representative directly at 📞 1-866-284-3022. They can explain whether you will receive a refund, a travel credit, or incur a cancellation fee.
⏱️ Step 5: Cancel Within 24 Hours (If Possible)
✅ If you booked your ticket less than 24 hours ago AND your flight is at least 7 days away, you are eligible for a full refund with no cancellation fees.
To take advantage of this policy, it is strongly advised to call 1-866-284-3022 right away and notify them that you fall within the 24-hour window.
📧 Step 6: Get Confirmation of Cancellation
Once your flight is canceled, make sure to:
📨 Check your email for a cancellation confirmation
💳 Verify if any refund or credit has been issued to your account
📅 Note the expiration date of any travel credit issued (typically valid for 90 days)
If you have not received confirmation within a few hours, call 📞 1-866-284-3022 again to follow up and ensure your cancellation was processed correctly.
🤔 Need Help? Contact Frontier Airlines Again
Porter’s website can sometimes be tricky or limited in functionality, especially for special fares or last-minute cancellations. That is why calling customer service at 📞 1-866-284-3022 is always the most reliable option. Their agents can also assist with:
• Modifying your travel dates
• Applying travel credits
• Rebooking future flights
• Answering policy-related questions
✍️ Final Thoughts
Canceling a Frontier Airlines flight does not have to be stressful. Whether you are canceling online or over the phone, knowing the process and your rights can save you time and money. Always keep the Porter customer service number 📞 1-866-284-3022 on hand for quick assistance and peace of mind.
🧭 Quick Recap:
• Prepare your booking info
• Try canceling online or via the Porter app
• For best results, call Porter directly at 📞 1-866-284-3022
• Check your eligibility for refunds or travel credits
• Always get a cancellation confirmation
✈️ Safe travels — or smooth cancellations — whichever your journey brings next!
Fix the order of the freq-table-hz property, then convert to OPP tables
and add interconnect support for UFS for the SM6350 SoC.
Signed-off-by: Luca Weiss <luca.weiss(a)fairphone.com>
---
Changes in v2:
- Resend, pick up tags
- Link to v1: https://lore.kernel.org/r/20250314-sm6350-ufs-things-v1-0-3600362cc52c@fair…
---
Luca Weiss (3):
arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS
arm64: dts: qcom: sm6350: Add OPP table support to UFSHC
arm64: dts: qcom: sm6350: Add interconnect support to UFS
arch/arm64/boot/dts/qcom/sm6350.dtsi | 49 ++++++++++++++++++++++++++++--------
1 file changed, 39 insertions(+), 10 deletions(-)
---
base-commit: a92c761bcac3d5042559107fa7679470727a4bcb
change-id: 20250314-sm6350-ufs-things-53c5de9fec5e
Best regards,
--
Luca Weiss <luca.weiss(a)fairphone.com>
If the send_peer_notif counter and the peer event notify are not synchronized.
It may cause problems such as the loss or dup of peer notify event.
Before this patch:
- If should_notify_peers is true and the lock for send_peer_notif-- fails, peer
event may be sent again in next mii_monitor loop, because should_notify_peers
is still true.
- If should_notify_peers is true and the lock for send_peer_notif-- succeeded,
but the lock for peer event fails, the peer event will be lost.
This patch locks the RTNL for send_peer_notif, events, and commit simultaneously.
Fixes: 07a4ddec3ce9 ("bonding: add an option to specify a delay between peer notifications")
Cc: Jay Vosburgh <jv(a)jvosburgh.net>
Cc: Andrew Lunn <andrew+netdev(a)lunn.ch>
Cc: Eric Dumazet <edumazet(a)google.com>
Cc: Jakub Kicinski <kuba(a)kernel.org>
Cc: Paolo Abeni <pabeni(a)redhat.com>
Cc: Hangbin Liu <liuhangbin(a)gmail.com>
Cc: Nikolay Aleksandrov <razor(a)blackwall.org>
Cc: Vincent Bernat <vincent(a)bernat.ch>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Tonghao Zhang <tonghao(a)bamaicloud.com>
---
drivers/net/bonding/bond_main.c | 40 +++++++++++++++------------------
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5791c3e39baa..52b7ac8ddfbc 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2971,7 +2971,7 @@ static void bond_mii_monitor(struct work_struct *work)
{
struct bonding *bond = container_of(work, struct bonding,
mii_work.work);
- bool should_notify_peers = false;
+ bool should_notify_peers;
bool commit;
unsigned long delay;
struct slave *slave;
@@ -2983,30 +2983,33 @@ static void bond_mii_monitor(struct work_struct *work)
goto re_arm;
rcu_read_lock();
+
should_notify_peers = bond_should_notify_peers(bond);
commit = !!bond_miimon_inspect(bond);
- if (bond->send_peer_notif) {
- rcu_read_unlock();
- if (rtnl_trylock()) {
- bond->send_peer_notif--;
- rtnl_unlock();
- }
- } else {
- rcu_read_unlock();
- }
- if (commit) {
+ rcu_read_unlock();
+
+ if (commit || bond->send_peer_notif) {
/* Race avoidance with bond_close cancel of workqueue */
if (!rtnl_trylock()) {
delay = 1;
- should_notify_peers = false;
goto re_arm;
}
- bond_for_each_slave(bond, slave, iter) {
- bond_commit_link_state(slave, BOND_SLAVE_NOTIFY_LATER);
+ if (commit) {
+ bond_for_each_slave(bond, slave, iter) {
+ bond_commit_link_state(slave,
+ BOND_SLAVE_NOTIFY_LATER);
+ }
+ bond_miimon_commit(bond);
+ }
+
+ if (bond->send_peer_notif) {
+ bond->send_peer_notif--;
+ if (should_notify_peers)
+ call_netdevice_notifiers(NETDEV_NOTIFY_PEERS,
+ bond->dev);
}
- bond_miimon_commit(bond);
rtnl_unlock(); /* might sleep, hold no other locks */
}
@@ -3014,13 +3017,6 @@ static void bond_mii_monitor(struct work_struct *work)
re_arm:
if (bond->params.miimon)
queue_delayed_work(bond->wq, &bond->mii_work, delay);
-
- if (should_notify_peers) {
- if (!rtnl_trylock())
- return;
- call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, bond->dev);
- rtnl_unlock();
- }
}
static int bond_upper_dev_walk(struct net_device *upper,
--
2.34.1
In i2c_amd_probe(), amd_mp2_find_device() utilizes
driver_find_next_device() which internally calls driver_find_device()
to locate the matching device. driver_find_device() increments the
reference count of the found device by calling get_device(), but
amd_mp2_find_device() fails to call put_device() to decrement the
reference count before returning. This results in a reference count
leak of the PCI device each time i2c_amd_probe() is executed, which
may prevent the device from being properly released and cause a memory
leak.
Found by code review.
Cc: stable(a)vger.kernel.org
Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
Changes in v3:
- kept the temporary variable to store pci_get_drvdata() result before releasing the device reference;
Changes in v2:
- modified the missing initialization in the patch. Sorry for the omission.
---
drivers/i2c/busses/i2c-amd-mp2-pci.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-amd-mp2-pci.c b/drivers/i2c/busses/i2c-amd-mp2-pci.c
index ef7370d3dbea..60edbabc2986 100644
--- a/drivers/i2c/busses/i2c-amd-mp2-pci.c
+++ b/drivers/i2c/busses/i2c-amd-mp2-pci.c
@@ -458,13 +458,16 @@ struct amd_mp2_dev *amd_mp2_find_device(void)
{
struct device *dev;
struct pci_dev *pci_dev;
+ struct amd_mp2_dev *mp2_dev;
dev = driver_find_next_device(&amd_mp2_pci_driver.driver, NULL);
if (!dev)
return NULL;
pci_dev = to_pci_dev(dev);
- return (struct amd_mp2_dev *)pci_get_drvdata(pci_dev);
+ mp2_dev = (struct amd_mp2_dev *)pci_get_drvdata(pci_dev);
+ put_device(dev);
+ return mp2_dev;
}
EXPORT_SYMBOL_GPL(amd_mp2_find_device);
--
2.17.1