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

by Peter Oberparleiter

Using gcov on kernels compiled with GCC 15 results in truncated 16-byte long .gcda files with no usable data. To fix this, update GCOV_COUNTERS to match the value defined by GCC 15. Tested with GCC 14.3.0 and GCC 15.2.0. Reported-by: Matthieu Baerts <matttbe(a)kernel.org> Closes: https://github.com/linux-test-project/lcov/issues/445 Tested-by: Matthieu Baerts <matttbe(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Peter Oberparleiter <oberpar(a)linux.ibm.com> --- kernel/gcov/gcc_4_7.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c index a08cc076f332..ffde93d051a4 100644 --- a/kernel/gcov/gcc_4_7.c +++ b/kernel/gcov/gcc_4_7.c @@ -18,7 +18,9 @@ #include <linux/mm.h> #include "gcov.h" -#if (__GNUC__ >= 14) +#if (__GNUC__ >= 15) +#define GCOV_COUNTERS 10 +#elif (__GNUC__ >= 14) #define GCOV_COUNTERS 9 #elif (__GNUC__ >= 10) #define GCOV_COUNTERS 8 -- 2.48.1

2 weeks, 6 days

1
0
0 0

[PATCH 05/25] media: i2c: ov01a10: Fix passing stream instead of pad to v4l2_subdev_state_get_format()

by Hans de Goede

The 2 argument version of v4l2_subdev_state_get_format() takes the pad as second argument, not the stream. Fixes: bc0e8d91feec ("media: v4l: subdev: Switch to stream-aware state functions") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hansg(a)kernel.org> --- Note the problem pre-exists the Fixes: commit but backporting further will require manual backports and seems unnecessary. --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index f92867f542f0..0405ec7c75fd 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -731,7 +731,7 @@ static int ov01a10_set_format(struct v4l2_subdev *sd, h_blank); } - format = v4l2_subdev_state_get_format(sd_state, fmt->stream); + format = v4l2_subdev_state_get_format(sd_state, fmt->pad); *format = fmt->format; return 0; -- 2.51.0

2 weeks, 6 days

2
1
0 0

[PATCH 04/25] media: i2c: ov01a10: Add missing v4l2_subdev_cleanup() calls

by Hans de Goede

Add missing v4l2_subdev_cleanup() calls to cleanup after v4l2_subdev_init_finalize(). Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hansg(a)kernel.org> --- drivers/media/i2c/ov01a10.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 95d6a0f046a0..f92867f542f0 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -864,6 +864,7 @@ static void ov01a10_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_async_unregister_subdev(sd); + v4l2_subdev_cleanup(sd); media_entity_cleanup(&sd->entity); v4l2_ctrl_handler_free(sd->ctrl_handler); @@ -934,6 +935,7 @@ static int ov01a10_probe(struct i2c_client *client) err_pm_disable: pm_runtime_disable(dev); pm_runtime_set_suspended(&client->dev); + v4l2_subdev_cleanup(&ov01a10->sd); err_media_entity_cleanup: media_entity_cleanup(&ov01a10->sd.entity); -- 2.51.0

2 weeks, 6 days

3
3
0 0

[PATCH wireless v4 1/4] wifi: cfg80211: add an hrtimer based delayed work item

by Miri Korenblit

From: Benjamin Berg <benjamin.berg(a)intel.com> The normal timer mechanism assume that timeout further in the future need a lower accuracy. As an example, the granularity for a timer scheduled 4096 ms in the future on a 1000 Hz system is already 512 ms. This granularity is perfectly sufficient for e.g. timeouts, but there are other types of events that will happen at a future point in time and require a higher accuracy. Add a new wiphy_hrtimer_work type that uses an hrtimer internally. The API is almost identical to the existing wiphy_delayed_work and it can be used as a drop-in replacement after minor adjustments. The work will be scheduled relative to the current time with a slack of 1 millisecond. CC: stable(a)vger.kernel.org # 6.4+ Signed-off-by: Benjamin Berg <benjamin.berg(a)intel.com> Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> --- include/net/cfg80211.h | 78 ++++++++++++++++++++++++++++++++++++++++++ net/wireless/core.c | 56 ++++++++++++++++++++++++++++++ net/wireless/trace.h | 21 ++++++++++++ 3 files changed, 155 insertions(+) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 781624f5913a..820e299f06b5 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -6435,6 +6435,11 @@ static inline void wiphy_delayed_work_init(struct wiphy_delayed_work *dwork, * after wiphy_lock() was called. Therefore, wiphy_cancel_work() can * use just cancel_work() instead of cancel_work_sync(), it requires * being in a section protected by wiphy_lock(). + * + * Note that these are scheduled with a timer where the accuracy + * becomes less the longer in the future the scheduled timer is. Use + * wiphy_hrtimer_work_queue() if the timer must be not be late by more + * than approximately 10 percent. */ void wiphy_delayed_work_queue(struct wiphy *wiphy, struct wiphy_delayed_work *dwork, @@ -6506,6 +6511,79 @@ void wiphy_delayed_work_flush(struct wiphy *wiphy, bool wiphy_delayed_work_pending(struct wiphy *wiphy, struct wiphy_delayed_work *dwork); +struct wiphy_hrtimer_work { + struct wiphy_work work; + struct wiphy *wiphy; + struct hrtimer timer; +}; + +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t); + +static inline void wiphy_hrtimer_work_init(struct wiphy_hrtimer_work *hrwork, + wiphy_work_func_t func) +{ + hrtimer_setup(&hrwork->timer, wiphy_hrtimer_work_timer, + CLOCK_BOOTTIME, HRTIMER_MODE_REL); + wiphy_work_init(&hrwork->work, func); +} + +/** + * wiphy_hrtimer_work_queue - queue hrtimer work for the wiphy + * @wiphy: the wiphy to queue for + * @hrwork: the high resolution timer worker + * @delay: the delay given as a ktime_t + * + * Please refer to wiphy_delayed_work_queue(). The difference is that + * the hrtimer work uses a high resolution timer for scheduling. This + * may be needed if timeouts might be scheduled further in the future + * and the accuracy of the normal timer is not sufficient. + * + * Expect a delay of a few milliseconds as the timer is scheduled + * with some slack and some more time may pass between queueing the + * work and its start. + */ +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay); + +/** + * wiphy_hrtimer_work_cancel - cancel previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrtimer: the hrtimer work to cancel + * + * Cancel the work *without* waiting for it, this assumes being + * called under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrtimer); + +/** + * wiphy_hrtimer_work_flush - flush previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work to flush + * + * Flush the work (i.e. run it if pending). This must be called + * under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + +/** + * wiphy_hrtimer_work_pending - Find out whether a wiphy hrtimer + * work item is currently pending. + * + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work in question + * + * Return: true if timer is pending, false otherwise + * + * Please refer to the wiphy_delayed_work_pending() documentation as + * this is the equivalent function for hrtimer based delayed work + * items. + */ +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + /** * enum ieee80211_ap_reg_power - regulatory power for an Access Point * diff --git a/net/wireless/core.c b/net/wireless/core.c index 797f9f2004a6..54a34d8d356e 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1787,6 +1787,62 @@ bool wiphy_delayed_work_pending(struct wiphy *wiphy, } EXPORT_SYMBOL_GPL(wiphy_delayed_work_pending); +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t) +{ + struct wiphy_hrtimer_work *hrwork = + container_of(t, struct wiphy_hrtimer_work, timer); + + wiphy_work_queue(hrwork->wiphy, &hrwork->work); + + return HRTIMER_NORESTART; +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_timer); + +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay) +{ + trace_wiphy_hrtimer_work_queue(wiphy, &hrwork->work, delay); + + if (!delay) { + hrtimer_cancel(&hrwork->timer); + wiphy_work_queue(wiphy, &hrwork->work); + return; + } + + hrwork->wiphy = wiphy; + hrtimer_start_range_ns(&hrwork->timer, delay, + 1000 * NSEC_PER_USEC, HRTIMER_MODE_REL); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_queue); + +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_cancel(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_cancel); + +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_flush(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_flush); + +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + return hrtimer_is_queued(&hrwork->timer); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_pending); + static int __init cfg80211_init(void) { int err; diff --git a/net/wireless/trace.h b/net/wireless/trace.h index 8a4c34112eb5..2b71f1d867a0 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -304,6 +304,27 @@ TRACE_EVENT(wiphy_delayed_work_queue, __entry->delay) ); +TRACE_EVENT(wiphy_hrtimer_work_queue, + TP_PROTO(struct wiphy *wiphy, struct wiphy_work *work, + ktime_t delay), + TP_ARGS(wiphy, work, delay), + TP_STRUCT__entry( + WIPHY_ENTRY + __field(void *, instance) + __field(void *, func) + __field(ktime_t, delay) + ), + TP_fast_assign( + WIPHY_ASSIGN; + __entry->instance = work; + __entry->func = work->func; + __entry->delay = delay; + ), + TP_printk(WIPHY_PR_FMT " instance=%p func=%pS delay=%llu", + WIPHY_PR_ARG, __entry->instance, __entry->func, + __entry->delay) +); + TRACE_EVENT(wiphy_work_worker_start, TP_PROTO(struct wiphy *wiphy), TP_ARGS(wiphy), -- 2.34.1

2 weeks, 6 days

1
0
0 0

[PATCH] phy: ti: omap-usb2: Fix device node reference leak in omap_usb2_probe

by Miaoqian Lin

In omap_usb2_probe(), of_parse_phandle() returns a device node with its reference count incremented. The caller is responsible for releasing this reference when the node is no longer needed. Add of_node_put(control_node) after usage to fix the reference leak. Found via static analysis. Fixes: 478b6c7436c2 ("usb: phy: omap-usb2: Don't use omap_get_control_dev()") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/phy/ti/phy-omap-usb2.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/phy/ti/phy-omap-usb2.c b/drivers/phy/ti/phy-omap-usb2.c index 1eb252604441..660df3181e4f 100644 --- a/drivers/phy/ti/phy-omap-usb2.c +++ b/drivers/phy/ti/phy-omap-usb2.c @@ -426,6 +426,7 @@ static int omap_usb2_probe(struct platform_device *pdev) } control_pdev = of_find_device_by_node(control_node); + of_node_put(control_node); if (!control_pdev) { dev_err(&pdev->dev, "Failed to get control device\n"); return -EINVAL; -- 2.39.5 (Apple Git-154)

2 weeks, 6 days

2
1
0 0

[PATCH v2 1/2] media: mediatek: mdp: fix device leak on probe

by Johan Hovold

Make sure to drop the reference taken when looking up the VPU firmware device during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: c8eb2d7e8202 ("[media] media: Add Mediatek MDP Driver") Cc: stable(a)vger.kernel.org # 4.10 Cc: Minghsiu Tsai <minghsiu.tsai(a)mediatek.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/media/platform/mediatek/mdp/mtk_mdp_core.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c b/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c index 80fdc6ff57e0..5c7dcf4090f4 100644 --- a/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c +++ b/drivers/media/platform/mediatek/mdp/mtk_mdp_core.c @@ -198,7 +198,7 @@ static int mtk_mdp_probe(struct platform_device *pdev) VPU_RST_MDP); if (ret) { dev_err(&pdev->dev, "Failed to register reset handler\n"); - goto err_m2m_register; + goto err_put_vpu; } platform_set_drvdata(pdev, mdp); @@ -206,7 +206,7 @@ static int mtk_mdp_probe(struct platform_device *pdev) ret = vb2_dma_contig_set_max_seg_size(&pdev->dev, DMA_BIT_MASK(32)); if (ret) { dev_err(&pdev->dev, "Failed to set vb2 dma mag seg size\n"); - goto err_m2m_register; + goto err_put_vpu; } pm_runtime_enable(dev); @@ -214,6 +214,8 @@ static int mtk_mdp_probe(struct platform_device *pdev) return 0; +err_put_vpu: + put_device(&mdp->vpu_dev->dev); err_m2m_register: v4l2_device_unregister(&mdp->v4l2_dev); @@ -241,6 +243,7 @@ static void mtk_mdp_remove(struct platform_device *pdev) struct mtk_mdp_comp *comp, *comp_temp; pm_runtime_disable(&pdev->dev); + put_device(&mdp->vpu_dev->dev); vb2_dma_contig_clear_max_seg_size(&pdev->dev); mtk_mdp_unregister_m2m_device(mdp); v4l2_device_unregister(&mdp->v4l2_dev); -- 2.51.0

2 weeks, 6 days

1
0
0 0

[PATCH] drm/meson: Fix reference count leak in meson_encoder_dsi_probe

by Miaoqian Lin

The of_graph_get_remote_node() function returns a device node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Fixes: 42dcf15f901c ("drm/meson: add DSI encoder") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/meson/meson_encoder_dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/meson/meson_encoder_dsi.c b/drivers/gpu/drm/meson/meson_encoder_dsi.c index 6c6624f9ba24..01edf46e30d0 100644 --- a/drivers/gpu/drm/meson/meson_encoder_dsi.c +++ b/drivers/gpu/drm/meson/meson_encoder_dsi.c @@ -121,6 +121,7 @@ int meson_encoder_dsi_probe(struct meson_drm *priv) } meson_encoder_dsi->next_bridge = of_drm_find_bridge(remote); + of_node_put(remote); if (!meson_encoder_dsi->next_bridge) return dev_err_probe(priv->dev, -EPROBE_DEFER, "Failed to find DSI transceiver bridge\n"); -- 2.39.5 (Apple Git-154)

2 weeks, 6 days

2
1
0 0

[PATCH] soc: samsung: exynos-pmu: fix reference count leak in exynos_get_pmu_regmap_by_phandle

by Miaoqian Lin

The driver_find_device_by_of_node() function calls driver_find_device and returns a device with its reference count incremented. Add the missing put_device() call to release this reference after the device is used. Found via static analysis. Fixes: 0b7c6075022c ("soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/soc/samsung/exynos-pmu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/soc/samsung/exynos-pmu.c b/drivers/soc/samsung/exynos-pmu.c index 22c50ca2aa79..a53c1f882e1a 100644 --- a/drivers/soc/samsung/exynos-pmu.c +++ b/drivers/soc/samsung/exynos-pmu.c @@ -346,6 +346,7 @@ struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np, if (!dev) return ERR_PTR(-EPROBE_DEFER); + put_device(dev); return syscon_node_to_regmap(pmu_np); } EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle); -- 2.39.5 (Apple Git-154)

2 weeks, 6 days

3
2
0 0

Hello

by Eric

2 weeks, 6 days

1
0
0 0

[PATCH] cpufreq: nforce2: fix reference count leak in nforce2

by Miaoqian Lin

There are two reference count leaks in this driver: 1. In nforce2_fsb_read(): pci_get_subsys() increases the reference count of the PCI device, but pci_dev_put() is never called to release it, thus leaking the reference. 2. In nforce2_detect_chipset(): pci_get_subsys() gets a reference to the nforce2_dev which is stored in a global variable, but the reference is never released when the module is unloaded. Fix both by: - Adding pci_dev_put(nforce2_sub5) in nforce2_fsb_read() after reading the configuration. - Adding pci_dev_put(nforce2_dev) in nforce2_exit() to release the global device reference. Found via static analysis. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/cpufreq/cpufreq-nforce2.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/cpufreq/cpufreq-nforce2.c b/drivers/cpufreq/cpufreq-nforce2.c index fedad1081973..fbbbe501cf2d 100644 --- a/drivers/cpufreq/cpufreq-nforce2.c +++ b/drivers/cpufreq/cpufreq-nforce2.c @@ -145,6 +145,8 @@ static unsigned int nforce2_fsb_read(int bootfsb) pci_read_config_dword(nforce2_sub5, NFORCE2_BOOTFSB, &fsb); fsb /= 1000000; + pci_dev_put(nforce2_sub5); + /* Check if PLL register is already set */ pci_read_config_byte(nforce2_dev, NFORCE2_PLLENABLE, (u8 *)&temp); @@ -426,6 +428,7 @@ static int __init nforce2_init(void) static void __exit nforce2_exit(void) { cpufreq_unregister_driver(&nforce2_driver); + pci_dev_put(nforce2_dev); } module_init(nforce2_init); -- 2.39.5 (Apple Git-154)

3 weeks

2
1
0 0

[PATCH] net: phy: motorcomm: Fix the issue in the code regarding the incorrect use of time units

by Yi Cong

From: Yi Cong <yicong(a)kylinos.cn> Currently, NS (nanoseconds) is being used, but according to the datasheet, the correct unit should be PS (picoseconds). Fixes: 4869a146cd60 ("net: phy: Add BIT macro for Motorcomm yt8521/yt8531 gigabit ethernet phy") Cc: stable(a)vger.kernel.org Signed-off-by: Yi Cong <yicong(a)kylinos.cn> --- drivers/net/phy/motorcomm.c | 102 ++++++++++++++++++------------------ 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c index a3593e663059..81491c71e75b 100644 --- a/drivers/net/phy/motorcomm.c +++ b/drivers/net/phy/motorcomm.c @@ -171,7 +171,7 @@ * 1b1 enable 1.9ns rxc clock delay */ #define YT8521_CCR_RXC_DLY_EN BIT(8) -#define YT8521_CCR_RXC_DLY_1_900_NS 1900 +#define YT8521_CCR_RXC_DLY_1_900_PS 1900 #define YT8521_CCR_MODE_SEL_MASK (BIT(2) | BIT(1) | BIT(0)) #define YT8521_CCR_MODE_UTP_TO_RGMII 0 @@ -196,22 +196,22 @@ #define YT8521_RC1R_RX_DELAY_MASK GENMASK(13, 10) #define YT8521_RC1R_FE_TX_DELAY_MASK GENMASK(7, 4) #define YT8521_RC1R_GE_TX_DELAY_MASK GENMASK(3, 0) -#define YT8521_RC1R_RGMII_0_000_NS 0 -#define YT8521_RC1R_RGMII_0_150_NS 1 -#define YT8521_RC1R_RGMII_0_300_NS 2 -#define YT8521_RC1R_RGMII_0_450_NS 3 -#define YT8521_RC1R_RGMII_0_600_NS 4 -#define YT8521_RC1R_RGMII_0_750_NS 5 -#define YT8521_RC1R_RGMII_0_900_NS 6 -#define YT8521_RC1R_RGMII_1_050_NS 7 -#define YT8521_RC1R_RGMII_1_200_NS 8 -#define YT8521_RC1R_RGMII_1_350_NS 9 -#define YT8521_RC1R_RGMII_1_500_NS 10 -#define YT8521_RC1R_RGMII_1_650_NS 11 -#define YT8521_RC1R_RGMII_1_800_NS 12 -#define YT8521_RC1R_RGMII_1_950_NS 13 -#define YT8521_RC1R_RGMII_2_100_NS 14 -#define YT8521_RC1R_RGMII_2_250_NS 15 +#define YT8521_RC1R_RGMII_0_000_PS 0 +#define YT8521_RC1R_RGMII_0_150_PS 1 +#define YT8521_RC1R_RGMII_0_300_PS 2 +#define YT8521_RC1R_RGMII_0_450_PS 3 +#define YT8521_RC1R_RGMII_0_600_PS 4 +#define YT8521_RC1R_RGMII_0_750_PS 5 +#define YT8521_RC1R_RGMII_0_900_PS 6 +#define YT8521_RC1R_RGMII_1_050_PS 7 +#define YT8521_RC1R_RGMII_1_200_PS 8 +#define YT8521_RC1R_RGMII_1_350_PS 9 +#define YT8521_RC1R_RGMII_1_500_PS 10 +#define YT8521_RC1R_RGMII_1_650_PS 11 +#define YT8521_RC1R_RGMII_1_800_PS 12 +#define YT8521_RC1R_RGMII_1_950_PS 13 +#define YT8521_RC1R_RGMII_2_100_PS 14 +#define YT8521_RC1R_RGMII_2_250_PS 15 /* LED CONFIG */ #define YT8521_MAX_LEDS 3 @@ -800,40 +800,40 @@ struct ytphy_cfg_reg_map { static const struct ytphy_cfg_reg_map ytphy_rgmii_delays[] = { /* for tx delay / rx delay with YT8521_CCR_RXC_DLY_EN is not set. */ - { 0, YT8521_RC1R_RGMII_0_000_NS }, - { 150, YT8521_RC1R_RGMII_0_150_NS }, - { 300, YT8521_RC1R_RGMII_0_300_NS }, - { 450, YT8521_RC1R_RGMII_0_450_NS }, - { 600, YT8521_RC1R_RGMII_0_600_NS }, - { 750, YT8521_RC1R_RGMII_0_750_NS }, - { 900, YT8521_RC1R_RGMII_0_900_NS }, - { 1050, YT8521_RC1R_RGMII_1_050_NS }, - { 1200, YT8521_RC1R_RGMII_1_200_NS }, - { 1350, YT8521_RC1R_RGMII_1_350_NS }, - { 1500, YT8521_RC1R_RGMII_1_500_NS }, - { 1650, YT8521_RC1R_RGMII_1_650_NS }, - { 1800, YT8521_RC1R_RGMII_1_800_NS }, - { 1950, YT8521_RC1R_RGMII_1_950_NS }, /* default tx/rx delay */ - { 2100, YT8521_RC1R_RGMII_2_100_NS }, - { 2250, YT8521_RC1R_RGMII_2_250_NS }, + { 0, YT8521_RC1R_RGMII_0_000_PS }, + { 150, YT8521_RC1R_RGMII_0_150_PS }, + { 300, YT8521_RC1R_RGMII_0_300_PS }, + { 450, YT8521_RC1R_RGMII_0_450_PS }, + { 600, YT8521_RC1R_RGMII_0_600_PS }, + { 750, YT8521_RC1R_RGMII_0_750_PS }, + { 900, YT8521_RC1R_RGMII_0_900_PS }, + { 1050, YT8521_RC1R_RGMII_1_050_PS }, + { 1200, YT8521_RC1R_RGMII_1_200_PS }, + { 1350, YT8521_RC1R_RGMII_1_350_PS }, + { 1500, YT8521_RC1R_RGMII_1_500_PS }, + { 1650, YT8521_RC1R_RGMII_1_650_PS }, + { 1800, YT8521_RC1R_RGMII_1_800_PS }, + { 1950, YT8521_RC1R_RGMII_1_950_PS }, /* default tx/rx delay */ + { 2100, YT8521_RC1R_RGMII_2_100_PS }, + { 2250, YT8521_RC1R_RGMII_2_250_PS }, /* only for rx delay with YT8521_CCR_RXC_DLY_EN is set. */ - { 0 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_000_NS }, - { 150 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_150_NS }, - { 300 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_300_NS }, - { 450 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_450_NS }, - { 600 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_600_NS }, - { 750 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_750_NS }, - { 900 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_0_900_NS }, - { 1050 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_050_NS }, - { 1200 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_200_NS }, - { 1350 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_350_NS }, - { 1500 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_500_NS }, - { 1650 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_650_NS }, - { 1800 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_800_NS }, - { 1950 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_1_950_NS }, - { 2100 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_2_100_NS }, - { 2250 + YT8521_CCR_RXC_DLY_1_900_NS, YT8521_RC1R_RGMII_2_250_NS } + { 0 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_000_PS }, + { 150 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_150_PS }, + { 300 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_300_PS }, + { 450 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_450_PS }, + { 600 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_600_PS }, + { 750 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_750_PS }, + { 900 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_0_900_PS }, + { 1050 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_050_PS }, + { 1200 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_200_PS }, + { 1350 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_350_PS }, + { 1500 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_500_PS }, + { 1650 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_650_PS }, + { 1800 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_800_PS }, + { 1950 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_1_950_PS }, + { 2100 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_2_100_PS }, + { 2250 + YT8521_CCR_RXC_DLY_1_900_PS, YT8521_RC1R_RGMII_2_250_PS } }; static u32 ytphy_get_delay_reg_value(struct phy_device *phydev, @@ -890,10 +890,10 @@ static int ytphy_rgmii_clk_delay_config(struct phy_device *phydev) rx_reg = ytphy_get_delay_reg_value(phydev, "rx-internal-delay-ps", ytphy_rgmii_delays, tb_size, &rxc_dly_en, - YT8521_RC1R_RGMII_1_950_NS); + YT8521_RC1R_RGMII_1_950_PS); tx_reg = ytphy_get_delay_reg_value(phydev, "tx-internal-delay-ps", ytphy_rgmii_delays, tb_size, NULL, - YT8521_RC1R_RGMII_1_950_NS); + YT8521_RC1R_RGMII_1_950_PS); switch (phydev->interface) { case PHY_INTERFACE_MODE_RGMII: -- 2.25.1

3 weeks

1
0
0 0

[PATCH] clk: rockchip: rk3588: Don't change PLL rates when setting dclk_vop2_src

by Heiko Stuebner

dclk_vop2_src currently has CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT flags set, which is vastly different than dclk_vop0_src or dclk_vop1_src, which have none of those. With these flags in dclk_vop2_src, actually setting the clock then results in a lot of other peripherals breaking, because setting the rate results in the PLL source getting changed: [ 14.898718] clk_core_set_rate_nolock: setting rate for dclk_vop2 to 152840000 [ 15.155017] clk_change_rate: setting rate for pll_gpll to 1680000000 [ clk adjusting every gpll user ] This includes possibly the other vops, i2s, spdif and even the uarts. Among other possible things, this breaks the uart console on a board I use. Sometimes it recovers later on, but there will be a big block of garbled output for a while at least. Shared PLLs should not be changed by individual users, so drop these flags from dclk_vop2_src and make the flags the same as on dclk_vop0 and dclk_vop1. Fixes: f1c506d152ff ("clk: rockchip: add clock controller for the RK3588") Cc: stable(a)vger.kernel.org Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- drivers/clk/rockchip/clk-rk3588.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/rockchip/clk-rk3588.c b/drivers/clk/rockchip/clk-rk3588.c index 1694223f4f84..cf83242d1726 100644 --- a/drivers/clk/rockchip/clk-rk3588.c +++ b/drivers/clk/rockchip/clk-rk3588.c @@ -2094,7 +2094,7 @@ static struct rockchip_clk_branch rk3588_early_clk_branches[] __initdata = { COMPOSITE(DCLK_VOP1_SRC, "dclk_vop1_src", gpll_cpll_v0pll_aupll_p, 0, RK3588_CLKSEL_CON(111), 14, 2, MFLAGS, 9, 5, DFLAGS, RK3588_CLKGATE_CON(52), 11, GFLAGS), - COMPOSITE(DCLK_VOP2_SRC, "dclk_vop2_src", gpll_cpll_v0pll_aupll_p, CLK_SET_RATE_PARENT | CLK_SET_RATE_NO_REPARENT, + COMPOSITE(DCLK_VOP2_SRC, "dclk_vop2_src", gpll_cpll_v0pll_aupll_p, 0, RK3588_CLKSEL_CON(112), 5, 2, MFLAGS, 0, 5, DFLAGS, RK3588_CLKGATE_CON(52), 12, GFLAGS), COMPOSITE_NODIV(DCLK_VOP0, "dclk_vop0", dclk_vop0_p, -- 2.47.2

3 weeks

5
8
0 0

[PATCH net 1/1] batman-adv: Release references to inactive interfaces

by Simon Wunderlich

From: Sven Eckelmann <sven(a)narfation.org> Trying to dump the originators or the neighbors via netlink for a meshif with an inactive primary interface is not allowed. The dump functions were checking this correctly but they didn't handle non-existing primary interfaces and existing _inactive_ interfaces differently. (Primary) batadv_hard_ifaces hold a references to a net_device. And accessing them is only allowed when either being in a RCU/spinlock protected section or when holding a valid reference to them. The netlink dump functions use the latter. But because the missing specific error handling for inactive primary interfaces, the reference was never dropped. This reference counting error was only detected when the interface should have been removed from the system: unregister_netdevice: waiting for batadv_slave_0 to become free. Usage count = 2 Cc: stable(a)vger.kernel.org Fixes: 6ecc4fd6c2f4 ("batman-adv: netlink: reduce duplicate code by returning interfaces") Reported-by: syzbot+881d65229ca4f9ae8c84(a)syzkaller.appspotmail.com Reported-by: Tetsuo Handa <penguin-kernel(a)i-love.sakura.ne.jp> Signed-off-by: Sven Eckelmann <sven(a)narfation.org> Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> --- net/batman-adv/originator.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/net/batman-adv/originator.c b/net/batman-adv/originator.c index a464ff96b9291..ed89d7fd1e7f4 100644 --- a/net/batman-adv/originator.c +++ b/net/batman-adv/originator.c @@ -764,11 +764,16 @@ int batadv_hardif_neigh_dump(struct sk_buff *msg, struct netlink_callback *cb) bat_priv = netdev_priv(mesh_iface); primary_if = batadv_primary_if_get_selected(bat_priv); - if (!primary_if || primary_if->if_status != BATADV_IF_ACTIVE) { + if (!primary_if) { ret = -ENOENT; goto out_put_mesh_iface; } + if (primary_if->if_status != BATADV_IF_ACTIVE) { + ret = -ENOENT; + goto out_put_primary_if; + } + hard_iface = batadv_netlink_get_hardif(bat_priv, cb); if (IS_ERR(hard_iface) && PTR_ERR(hard_iface) != -ENONET) { ret = PTR_ERR(hard_iface); @@ -1333,11 +1338,16 @@ int batadv_orig_dump(struct sk_buff *msg, struct netlink_callback *cb) bat_priv = netdev_priv(mesh_iface); primary_if = batadv_primary_if_get_selected(bat_priv); - if (!primary_if || primary_if->if_status != BATADV_IF_ACTIVE) { + if (!primary_if) { ret = -ENOENT; goto out_put_mesh_iface; } + if (primary_if->if_status != BATADV_IF_ACTIVE) { + ret = -ENOENT; + goto out_put_primary_if; + } + hard_iface = batadv_netlink_get_hardif(bat_priv, cb); if (IS_ERR(hard_iface) && PTR_ERR(hard_iface) != -ENONET) { ret = PTR_ERR(hard_iface); -- 2.47.3

3 weeks

2
1
0 0

[PATCH] riscv: Fix memory leak in module_frob_arch_sections()

by Miaoqian Lin

The current code directly overwrites the scratch pointer with the return value of kvrealloc(). If kvrealloc() fails and returns NULL, the original buffer becomes unreachable, causing a memory leak. Fix this by using a temporary variable to store kvrealloc()'s return value and only update the scratch pointer on success. Found via static anlaysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: be17c0df6795 ("riscv: module: Optimize PLT/GOT entry counting") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/riscv/kernel/module-sections.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/riscv/kernel/module-sections.c b/arch/riscv/kernel/module-sections.c index 75551ac6504c..1675cbad8619 100644 --- a/arch/riscv/kernel/module-sections.c +++ b/arch/riscv/kernel/module-sections.c @@ -119,6 +119,7 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, unsigned int num_plts = 0; unsigned int num_gots = 0; Elf_Rela *scratch = NULL; + Elf_Rela *new_scratch; size_t scratch_size = 0; int i; @@ -168,9 +169,12 @@ int module_frob_arch_sections(Elf_Ehdr *ehdr, Elf_Shdr *sechdrs, scratch_size_needed = (num_scratch_relas + num_relas) * sizeof(*scratch); if (scratch_size_needed > scratch_size) { scratch_size = scratch_size_needed; - scratch = kvrealloc(scratch, scratch_size, GFP_KERNEL); - if (!scratch) + new_scratch = kvrealloc(scratch, scratch_size, GFP_KERNEL); + if (!new_scratch) { + kvfree(scratch); return -ENOMEM; + } + scratch = new_scratch; } for (size_t j = 0; j < num_relas; j++) -- 2.39.5 (Apple Git-154)

3 weeks

2
1
0 0

[PATCH AUTOSEL 6.17-6.1] smb/server: fix possible memory leak in smb2_read()

by Sasha Levin

From: ZhangGuoDong <zhangguodong(a)kylinos.cn> [ Upstream commit 6fced056d2cc8d01b326e6fcfabaacb9850b71a4 ] Memory leak occurs when ksmbd_vfs_read() fails. Fix this by adding the missing kvfree(). Co-developed-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: ChenXiaoSong <chenxiaosong(a)kylinos.cn> Signed-off-by: ZhangGuoDong <zhangguodong(a)kylinos.cn> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## **Backport Status: YES** ### **Extensive Analysis** Based on comprehensive semantic code analysis and repository examination, this commit **should be backported** to stable kernel trees. --- ## **1. Code Change Analysis** The commit adds a single line to fix a memory leak in `fs/smb/server/smb2pdu.c`: ```c nbytes = ksmbd_vfs_read(work, fp, length, &offset, aux_payload_buf); if (nbytes < 0) { + kvfree(aux_payload_buf); // <-- Added line err = nbytes; goto out; } ``` **What was wrong:** Memory allocated at line 6821 (`aux_payload_buf = kvzalloc(ALIGN(length, 8), KSMBD_DEFAULT_GFP)`) was not freed when `ksmbd_vfs_read()` fails, while all other error paths properly call `kvfree()`. --- ## **2. Semantic Analysis Tools Used** ### **Tool 1: mcp__semcode__find_function** - Located `smb2_read()` in `fs/smb/server/smb2pdu.c:6727-6895` - Confirmed it's an SMB2 protocol handler (169 lines, 24 function calls) - Return type: `int` (returns error codes) ### **Tool 2: mcp__semcode__find_callers** - Result: No direct function callers - However, cross-referenced with `smb2ops.c:183` showing `smb2_read` is registered as a handler: `[SMB2_READ_HE] = { .proc = smb2_read }` - **Conclusion:** This is a protocol handler invoked by the SMB2 message dispatcher, meaning it's **directly user-triggerable** via network requests ### **Tool 3: mcp__semcode__find_calls** - Analyzed `ksmbd_vfs_read()` dependencies - Found it can fail with multiple error codes: `-EISDIR`, `-EACCES`, `-EAGAIN`, plus any errors from `kernel_read()` - **All of these failure paths trigger the memory leak** ### **Tool 4: git blame & git log** - Bug introduced: commit `e2f34481b24db2` (2021-03-16) - **4 years old!** - Recent modification: commit `06a025448b572c` (2024-11-30) changed allocation to `ALIGN(length, 8)` but didn't fix the leak - Found 15+ similar "memory leak" fixes in ksmbd history, indicating active maintenance --- ## **3. Impact Scope Analysis** ### **User Exposure: CRITICAL** - **Protocol Handler:** Any SMB client can trigger this by sending SMB2 READ requests - **Network-facing:** ksmbd is a kernel SMB server exposed to network clients - **No authentication required to trigger:** The error path can be reached even with permission errors ### **Trigger Conditions (from VFS analysis):** 1. **-EISDIR**: Client tries to read a directory 2. **-EACCES**: Permission denied (no FILE_READ_DATA or FILE_EXECUTE access) 3. **-EAGAIN**: File is locked by another process 4. **kernel_read() failures**: Various VFS/filesystem errors All of these are **easily triggerable** by malicious or misbehaving clients. ### **Memory Leak Severity: HIGH** - **Allocation size:** `ALIGN(length, 8)` where `length` is client- controlled - **Maximum per leak:** Up to `SMB3_MAX_IOSIZE` = **8 MB** (from smb2pdu.h:28) - **Default size:** `SMB21_DEFAULT_IOSIZE` = **1 MB** (from smb2pdu.h:25) - **Attack scenario:** An attacker could repeatedly: 1. Send READ requests for locked files (triggers -EAGAIN) 2. Each failed request leaks up to 8MB 3. 100 requests = 800MB leaked 4. Can exhaust server memory leading to **DoS** --- ## **4. Regression Risk Analysis** ### **Risk Level: VERY LOW** - **Change size:** Single line addition - **Operation:** Adding missing cleanup (defensive programming) - **No behavior change:** Only affects error path that already returns failure - **Idempotent:** `kvfree()` is safe to call and simply frees allocated memory - **No dependencies:** No API changes or external impact --- ## **5. Stable Tree Compliance** | Criterion | Status | Evidence | |-----------|--------|----------| | Fixes important bug | ✅ YES | Memory leak leading to potential DoS | | Small and contained | ✅ YES | 1 line change, single function | | No new features | ✅ YES | Pure bug fix | | No architectural changes | ✅ YES | No structural modifications | | Low regression risk | ✅ YES | Minimal, defensive change | | Confined to subsystem | ✅ YES | Only affects ksmbd | | User-facing impact | ✅ YES | Affects all ksmbd users | --- ## **6. Comparison with Similar Commits** Recent ksmbd fixes in the repository show similar patterns: - `379510a815cb2`: "fix possible refcount leak in smb2_sess_setup()" - `5929e98f3bb76`: "fix potential double free on smb2_read_pipe() error path" - `e523a26c05672`: "fix passing freed memory 'aux_payload_buf'" - `809d50d36e71b`: "fix memory leak in smb2_lock()" **All these are typical stable tree backport candidates** with similar characteristics (small resource leak fixes). --- ## **7. Missing Stable Tags** **Notable:** The commit lacks explicit stable tree tags: - ❌ No `Cc: stable(a)vger.kernel.org` - ❌ No `Fixes:` tag pointing to the original buggy commit However, this doesn't diminish backport worthiness - the technical merits clearly justify backporting. --- ## **Conclusion** This commit is an **excellent candidate for backporting** because: 1. **Security concern:** Remote memory exhaustion DoS vector 2. **Long-standing bug:** Present since ksmbd's introduction (4+ years) 3. **Wide impact:** Affects all ksmbd deployments 4. **Minimal risk:** Single-line defensive fix 5. **Clear bug fix:** Unambiguous resource leak on error path 6. **Pattern consistency:** Matches other successfully backported ksmbd fixes **Recommendation:** Backport to all active stable trees where ksmbd exists (5.15+). fs/smb/server/smb2pdu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 287200d7c0764..409b85af82e1c 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -6826,6 +6826,7 @@ int smb2_read(struct ksmbd_work *work) nbytes = ksmbd_vfs_read(work, fp, length, &offset, aux_payload_buf); if (nbytes < 0) { + kvfree(aux_payload_buf); err = nbytes; goto out; } -- 2.51.0

3 weeks

1
25
0 0

[PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts

by Ravi Kumar Bandi

The pcie-xilinx-dma-pl driver does not enable INTx interrupts after initializing the port, preventing INTx interrupts from PCIe endpoints from flowing through the Xilinx XDMA root port bridge. This issue affects kernel 6.6.0 and later versions. This patch allows INTx interrupts generated by PCIe endpoints to flow through the root port. Tested the fix on a board with two endpoints generating INTx interrupts. Interrupts are properly detected and serviced. The /proc/interrupts output shows: [...] 32: 320 0 pl_dma:RC-Event 16 Level 400000000.axi-pcie, azdrv 52: 470 0 pl_dma:RC-Event 16 Level 500000000.axi-pcie, azdrv [...] Changes since v1:: - Fixed commit message per reviewer's comments Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Cc: stable(a)vger.kernel.org Signed-off-by: Ravi Kumar Bandi <ravib(a)amazon.com> --- drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c index b037c8f315e4..cc539292d10a 100644 --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c +++ b/drivers/pci/controller/pcie-xilinx-dma-pl.c @@ -659,6 +659,12 @@ static int xilinx_pl_dma_pcie_setup_irq(struct pl_dma_pcie *port) return err; } + /* Enable interrupts */ + pcie_write(port, XILINX_PCIE_DMA_IMR_ALL_MASK, + XILINX_PCIE_DMA_REG_IMR); + pcie_write(port, XILINX_PCIE_DMA_IDRN_MASK, + XILINX_PCIE_DMA_REG_IDRN_MASK); + return 0; } -- 2.47.3

3 weeks

8
31
0 0

[PATCH v3 0/3] Fixes/improvements for SM6350 UFS

by Luca Weiss

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 v3: - Actually pick up tags, sorry about that - Link to v2: https://lore.kernel.org/r/20251023-sm6350-ufs-things-v2-0-799d59178713@fair… 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>

3 weeks

2
2
0 0

+ mm-truncate-unmap-large-folio-on-split-failure.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/truncate: unmap large folio on split failure has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-truncate-unmap-large-folio-on-split-failure.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kiryl Shutsemau <kas(a)kernel.org> Subject: mm/truncate: unmap large folio on split failure Date: Mon, 27 Oct 2025 11:56:36 +0000 Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. This behavior might not be respected on truncation. During truncation, the kernel splits a large folio in order to reclaim memory. As a side effect, it unmaps the folio and destroys PMD mappings of the folio. The folio will be refaulted as PTEs and SIGBUS semantics are preserved. However, if the split fails, PMD mappings are preserved and the user will not receive SIGBUS on any accesses within the PMD. Unmap the folio on split failure. It will lead to refault as PTEs and preserve SIGBUS semantics. Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/20251027115636.82382-3-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau <kas(a)kernel.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: "Darrick J. Wong" <djwong(a)kernel.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/truncate.c | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) --- a/mm/truncate.c~mm-truncate-unmap-large-folio-on-split-failure +++ a/mm/truncate.c @@ -177,6 +177,32 @@ int truncate_inode_folio(struct address_ return 0; } +static int try_folio_split_or_unmap(struct folio *folio, struct page *split_at, + unsigned long min_order) +{ + enum ttu_flags ttu_flags = + TTU_SYNC | + TTU_SPLIT_HUGE_PMD | + TTU_IGNORE_MLOCK; + int ret; + + ret = try_folio_split_to_order(folio, split_at, min_order); + + /* + * If the split fails, unmap the folio, so it will be refaulted + * with PTEs to respect SIGBUS semantics. + * + * Make an exception for shmem/tmpfs that for long time + * intentionally mapped with PMDs across i_size. + */ + if (ret && !shmem_mapping(folio->mapping)) { + try_to_unmap(folio, ttu_flags); + WARN_ON(folio_mapped(folio)); + } + + return ret; +} + /* * Handle partial folios. The folio may be entirely within the * range if a split has raced with us. If not, we zero the part of the @@ -226,7 +252,7 @@ bool truncate_inode_partial_folio(struct min_order = mapping_min_folio_order(folio->mapping); split_at = folio_page(folio, PAGE_ALIGN_DOWN(offset) / PAGE_SIZE); - if (!try_folio_split_to_order(folio, split_at, min_order)) { + if (!try_folio_split_or_unmap(folio, split_at, min_order)) { /* * try to split at offset + length to make sure folios within * the range can be dropped, especially to avoid memory waste @@ -250,13 +276,10 @@ bool truncate_inode_partial_folio(struct if (!folio_trylock(folio2)) goto out; - /* - * make sure folio2 is large and does not change its mapping. - * Its split result does not matter here. - */ + /* make sure folio2 is large and does not change its mapping */ if (folio_test_large(folio2) && folio2->mapping == folio->mapping) - try_folio_split_to_order(folio2, split_at2, min_order); + try_folio_split_or_unmap(folio2, split_at2, min_order); folio_unlock(folio2); out: _ Patches currently in -mm which might be from kas(a)kernel.org are mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch mm-truncate-unmap-large-folio-on-split-failure.patch

3 weeks

1
0
0 0

+ mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memory: do not populate page table entries beyond i_size has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kiryl Shutsemau <kas(a)kernel.org> Subject: mm/memory: do not populate page table entries beyond i_size Date: Mon, 27 Oct 2025 11:56:35 +0000 Patch series "Fix SIGBUS semantics with large folios", v3. Accessing memory within a VMA, but beyond i_size rounded up to the next page size, is supposed to generate SIGBUS. Darrick reported[1] an xfstests regression in v6.18-rc1. generic/749 failed due to missing SIGBUS. This was caused by my recent changes that try to fault in the whole folio where possible: 19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()") 357b92761d94 ("mm/filemap: map entire large folio faultaround") These changes did not consider i_size when setting up PTEs, leading to xfstest breakage. However, the problem has been present in the kernel for a long time - since huge tmpfs was introduced in 2016. The kernel happily maps PMD-sized folios as PMD without checking i_size. And huge=always tmpfs allocates PMD-size folios on any writes. I considered this corner case when I implemented a large tmpfs, and my conclusion was that no one in their right mind should rely on receiving a SIGBUS signal when accessing beyond i_size. I cannot imagine how it could be useful for the workload. But apparently filesystem folks care a lot about preserving strict SIGBUS semantics. Generic/749 was introduced last year with reference to POSIX, but no real workloads were mentioned. It also acknowledged the tmpfs deviation from the test case. POSIX indeed says[3]: References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal. The patchset fixes the regression introduced by recent changes as well as more subtle SIGBUS breakage due to split failure on truncation. This patch (of 2): Accesses within VMA, but beyond i_size rounded up to PAGE_SIZE are supposed to generate SIGBUS. Recent changes attempted to fault in full folio where possible. They did not respect i_size, which led to populating PTEs beyond i_size and breaking SIGBUS semantics. Darrick reported generic/749 breakage because of this. However, the problem existed before the recent changes. With huge=always tmpfs, any write to a file leads to PMD-size allocation. Following the fault-in of the folio will install PMD mapping regardless of i_size. Fix filemap_map_pages() and finish_fault() to not install: - PTEs beyond i_size; - PMD mappings across i_size; Make an exception for shmem/tmpfs that for long time intentionally mapped with PMDs across i_size. Link: https://lkml.kernel.org/r/20251027115636.82382-1-kirill@shutemov.name Link: https://lkml.kernel.org/r/20251027115636.82382-2-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau <kas(a)kernel.org> Fixes: 19773df031bc ("mm/fault: try to map the entire file folio in finish_fault()") Fixes: 357b92761d94 ("mm/filemap: map entire large folio faultaround") Fixes: 01c70267053d ("fs: add a filesystem flag for THPs") Reported-by: "Darrick J. Wong" <djwong(a)kernel.org> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Christian Brauner <brauner(a)kernel.org> Cc: Dave Chinner <david(a)fromorbit.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Rik van Riel <riel(a)surriel.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/filemap.c | 28 ++++++++++++++++++++-------- mm/memory.c | 20 +++++++++++++++++++- 2 files changed, 39 insertions(+), 9 deletions(-) --- a/mm/filemap.c~mm-memory-do-not-populate-page-table-entries-beyond-i_size +++ a/mm/filemap.c @@ -3681,7 +3681,8 @@ skip: static vm_fault_t filemap_map_folio_range(struct vm_fault *vmf, struct folio *folio, unsigned long start, unsigned long addr, unsigned int nr_pages, - unsigned long *rss, unsigned short *mmap_miss) + unsigned long *rss, unsigned short *mmap_miss, + bool can_map_large) { unsigned int ref_from_caller = 1; vm_fault_t ret = 0; @@ -3696,7 +3697,7 @@ static vm_fault_t filemap_map_folio_rang * The folio must not cross VMA or page table boundary. */ addr0 = addr - start * PAGE_SIZE; - if (folio_within_vma(folio, vmf->vma) && + if (can_map_large && folio_within_vma(folio, vmf->vma) && (addr0 & PMD_MASK) == ((addr0 + folio_size(folio) - 1) & PMD_MASK)) { vmf->pte -= start; page -= start; @@ -3811,13 +3812,27 @@ vm_fault_t filemap_map_pages(struct vm_f unsigned long rss = 0; unsigned int nr_pages = 0, folio_type; unsigned short mmap_miss = 0, mmap_miss_saved; + bool can_map_large; rcu_read_lock(); folio = next_uptodate_folio(&xas, mapping, end_pgoff); if (!folio) goto out; - if (filemap_map_pmd(vmf, folio, start_pgoff)) { + file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; + end_pgoff = min(end_pgoff, file_end); + + /* + * Do not allow to map with PTEs beyond i_size and with PMD + * across i_size to preserve SIGBUS semantics. + * + * Make an exception for shmem/tmpfs that for long time + * intentionally mapped with PMDs across i_size. + */ + can_map_large = shmem_mapping(mapping) || + file_end >= folio_next_index(folio); + + if (can_map_large && filemap_map_pmd(vmf, folio, start_pgoff)) { ret = VM_FAULT_NOPAGE; goto out; } @@ -3830,10 +3845,6 @@ vm_fault_t filemap_map_pages(struct vm_f goto out; } - file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1; - if (end_pgoff > file_end) - end_pgoff = file_end; - folio_type = mm_counter_file(folio); do { unsigned long end; @@ -3850,7 +3861,8 @@ vm_fault_t filemap_map_pages(struct vm_f else ret |= filemap_map_folio_range(vmf, folio, xas.xa_index - folio->index, addr, - nr_pages, &rss, &mmap_miss); + nr_pages, &rss, &mmap_miss, + can_map_large); folio_unlock(folio); } while ((folio = next_uptodate_folio(&xas, mapping, end_pgoff)) != NULL); --- a/mm/memory.c~mm-memory-do-not-populate-page-table-entries-beyond-i_size +++ a/mm/memory.c @@ -65,6 +65,7 @@ #include <linux/gfp.h> #include <linux/migrate.h> #include <linux/string.h> +#include <linux/shmem_fs.h> #include <linux/memory-tiers.h> #include <linux/debugfs.h> #include <linux/userfaultfd_k.h> @@ -5501,8 +5502,25 @@ fallback: return ret; } + if (!needs_fallback && vma->vm_file) { + struct address_space *mapping = vma->vm_file->f_mapping; + pgoff_t file_end; + + file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE); + + /* + * Do not allow to map with PTEs beyond i_size and with PMD + * across i_size to preserve SIGBUS semantics. + * + * Make an exception for shmem/tmpfs that for long time + * intentionally mapped with PMDs across i_size. + */ + needs_fallback = !shmem_mapping(mapping) && + file_end < folio_next_index(folio); + } + if (pmd_none(*vmf->pmd)) { - if (folio_test_pmd_mappable(folio)) { + if (!needs_fallback && folio_test_pmd_mappable(folio)) { ret = do_set_pmd(vmf, folio, page); if (ret != VM_FAULT_FALLBACK) return ret; _ Patches currently in -mm which might be from kas(a)kernel.org are mm-memory-do-not-populate-page-table-entries-beyond-i_size.patch mm-truncate-unmap-large-folio-on-split-failure.patch

3 weeks

1
0
0 0

[PATCH] thermal/of: Fix reference count leak in thermal_of_cm_lookup

by Miaoqian Lin

The function calls of_parse_phandle() to get a device node, which increments the reference count of the node. However, the function fails to call of_node_put() to decrement the reference. This leads to a reference count leak. This is found by static analysis and similar to the commit a508e33956b5 ("ipmi:ipmb: Fix refcount leak in ipmi_ipmb_probe") Fixes: 423de5b5bc5b ("thermal/of: Fix cdev lookup in thermal_of_should_bind()") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/thermal/thermal_of.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c index 1a51a4d240ff..932291648683 100644 --- a/drivers/thermal/thermal_of.c +++ b/drivers/thermal/thermal_of.c @@ -284,8 +284,12 @@ static bool thermal_of_cm_lookup(struct device_node *cm_np, int count, i; tr_np = of_parse_phandle(child, "trip", 0); - if (tr_np != trip->priv) + if (tr_np != trip->priv) { + of_node_put(tr_np); continue; + } + + of_node_put(tr_np); /* The trip has been found, look up the cdev. */ count = of_count_phandle_with_args(child, "cooling-device", -- 2.39.5 (Apple Git-154)

3 weeks

2
1
0 0

[PATCH v1] net: phy: dp83867: Disable EEE support as not implemented

by Emanuele Ghidoli

From: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> While the DP83867 PHYs report EEE capability through their feature registers, the actual hardware does not support EEE (see Links). When the connected MAC enables EEE, it causes link instability and communication failures. The issue is reproducible with a iMX8MP and relevant stmmac ethernet port. Since the introduction of phylink-managed EEE support in the stmmac driver, EEE is now enabled by default, leading to issues on systems using the DP83867 PHY. Call phy_disable_eee during phy initialization to prevent EEE from being enabled on DP83867 PHYs. Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1445… Link: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/6586… Fixes: 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy") Cc: stable(a)vger.kernel.org Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli(a)toradex.com> --- drivers/net/phy/dp83867.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c index deeefb962566..36a0c1b7f59c 100644 --- a/drivers/net/phy/dp83867.c +++ b/drivers/net/phy/dp83867.c @@ -738,6 +738,12 @@ static int dp83867_config_init(struct phy_device *phydev) return ret; } + /* Although the DP83867 reports EEE capability through the + * MDIO_PCS_EEE_ABLE and MDIO_AN_EEE_ADV registers, the feature + * is not actually implemented in hardware. + */ + phy_disable_eee(phydev); + if (phy_interface_is_rgmii(phydev) || phydev->interface == PHY_INTERFACE_MODE_SGMII) { val = phy_read(phydev, MII_DP83867_PHYCTRL); -- 2.43.0

3 weeks

6
16
0 0

FAILED: patch "[PATCH] serial: 8250_dw: handle reset control deassert error" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x daeb4037adf7d3349b4a1fb792f4bc9824686a4b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102701-scabby-entrust-a162@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From daeb4037adf7d3349b4a1fb792f4bc9824686a4b Mon Sep 17 00:00:00 2001 From: Artem Shimko <a.shimko.dev(a)gmail.com> Date: Sun, 19 Oct 2025 12:51:31 +0300 Subject: [PATCH] serial: 8250_dw: handle reset control deassert error Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails. Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted. The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics. Fixes: acbdad8dd1ab ("serial: 8250_dw: simplify optional reset handling") Cc: stable <stable(a)kernel.org> Signed-off-by: Artem Shimko <a.shimko.dev(a)gmail.com> Link: https://patch.msgid.link/20251019095131.252848-1-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index a53ba04d9770..710ae4d40aec 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -635,7 +635,9 @@ static int dw8250_probe(struct platform_device *pdev) if (IS_ERR(data->rst)) return PTR_ERR(data->rst); - reset_control_deassert(data->rst); + err = reset_control_deassert(data->rst); + if (err) + return dev_err_probe(dev, err, "failed to deassert resets\n"); err = devm_add_action_or_reset(dev, dw8250_reset_control_assert, data->rst); if (err)

3 weeks

2
3
0 0

[PATCH 03/25] media: i2c: ov01a10: Fix gain range

by Hans de Goede

A maximum gain of 0xffff / 65525 seems unlikely and testing indeed shows that the gain control wraps-around at 4096, so set the maximum gain to 0xfff / 4095. The minimum gain of 0x100 is correct. Setting bits 8-11 to 0x0 results in the same gain values as setting these bits to 0x1, with bits 0-7 still increasing the gain when going from 0x000 - 0x0ff in the exact same range as when going from 0x100 - 0x1ff. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hansg(a)kernel.org> --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 0b1a1ecfffd0..95d6a0f046a0 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -48,7 +48,7 @@ /* analog gain controls */ #define OV01A10_REG_ANALOG_GAIN 0x3508 #define OV01A10_ANAL_GAIN_MIN 0x100 -#define OV01A10_ANAL_GAIN_MAX 0xffff +#define OV01A10_ANAL_GAIN_MAX 0xfff #define OV01A10_ANAL_GAIN_STEP 1 /* digital gain controls */ -- 2.51.0

3 weeks

2
1
0 0

[PATCH 02/25] media: i2c: ov01a10: Fix reported pixel-rate value

by Hans de Goede

CSI lanes are double-clocked so with a single lane at 400MHZ the resulting pixel-rate for 10-bits pixels is 400 MHz * 2 / 10 = 80 MHz, not 40 MHz. This also matches with the observed frame-rate of 60 fps with the default vblank setting: 80000000 / (1488 * 896) = 60. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hansg(a)kernel.org> --- drivers/media/i2c/ov01a10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index e5df01f97978..0b1a1ecfffd0 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -16,7 +16,7 @@ #include <media/v4l2-fwnode.h> #define OV01A10_LINK_FREQ_400MHZ 400000000ULL -#define OV01A10_SCLK 40000000LL +#define OV01A10_SCLK 80000000LL #define OV01A10_DATA_LANES 1 #define OV01A10_REG_CHIP_ID 0x300a -- 2.51.0

3 weeks

2
1
0 0

[PATCH 01/25] media: i2c: ov01a10: Fix the horizontal flip control

by Hans de Goede

During sensor calibration I noticed that with the hflip control set to false/disabled the image was mirrored. So it seems that the horizontal flip control is inverted and needs to be set to 1 to not flip (just like the similar problem recently fixed on the ov08x40 sensor). Invert the hflip control to fix the sensor mirroring by default. As the comment above the newly added OV01A10_MEDIA_BUS_FMT define explains the control being inverted also means that the native Bayer-order of the sensor actually is GBRG not BGGR, but so as to not break userspace the Bayer-order is kept at BGGR. Fixes: 0827b58dabff ("media: i2c: add ov01a10 image sensor driver") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hansg(a)kernel.org> --- drivers/media/i2c/ov01a10.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/drivers/media/i2c/ov01a10.c b/drivers/media/i2c/ov01a10.c index 141cb6f75b55..e5df01f97978 100644 --- a/drivers/media/i2c/ov01a10.c +++ b/drivers/media/i2c/ov01a10.c @@ -75,6 +75,15 @@ #define OV01A10_REG_X_WIN 0x3811 #define OV01A10_REG_Y_WIN 0x3813 +/* + * The native ov01a10 bayer-pattern is GBRG, but there was a driver bug enabling + * hflip/mirroring by default resulting in BGGR. Because of this bug Intel's + * proprietary IPU6 userspace stack expects BGGR. So we report BGGR to not break + * userspace and fix things up by shifting the crop window-x coordinate by 1 + * when hflip is *disabled*. + */ +#define OV01A10_MEDIA_BUS_FMT MEDIA_BUS_FMT_SBGGR10_1X10 + struct ov01a10_reg { u16 address; u8 val; @@ -185,14 +194,14 @@ static const struct ov01a10_reg sensor_1280x800_setting[] = { {0x380e, 0x03}, {0x380f, 0x80}, {0x3810, 0x00}, - {0x3811, 0x08}, + {0x3811, 0x09}, {0x3812, 0x00}, {0x3813, 0x08}, {0x3814, 0x01}, {0x3815, 0x01}, {0x3816, 0x01}, {0x3817, 0x01}, - {0x3820, 0xa0}, + {0x3820, 0xa8}, {0x3822, 0x13}, {0x3832, 0x28}, {0x3833, 0x10}, @@ -411,7 +420,7 @@ static int ov01a10_set_hflip(struct ov01a10 *ov01a10, u32 hflip) int ret; u32 val, offset; - offset = hflip ? 0x9 : 0x8; + offset = hflip ? 0x8 : 0x9; ret = ov01a10_write_reg(ov01a10, OV01A10_REG_X_WIN, 1, offset); if (ret) return ret; @@ -420,8 +429,8 @@ static int ov01a10_set_hflip(struct ov01a10 *ov01a10, u32 hflip) if (ret) return ret; - val = hflip ? val | FIELD_PREP(OV01A10_HFLIP_MASK, 0x1) : - val & ~OV01A10_HFLIP_MASK; + val = hflip ? val & ~OV01A10_HFLIP_MASK : + val | FIELD_PREP(OV01A10_HFLIP_MASK, 0x1); return ov01a10_write_reg(ov01a10, OV01A10_REG_FORMAT1, 1, val); } @@ -610,7 +619,7 @@ static void ov01a10_update_pad_format(const struct ov01a10_mode *mode, { fmt->width = mode->width; fmt->height = mode->height; - fmt->code = MEDIA_BUS_FMT_SBGGR10_1X10; + fmt->code = OV01A10_MEDIA_BUS_FMT; fmt->field = V4L2_FIELD_NONE; fmt->colorspace = V4L2_COLORSPACE_RAW; } @@ -751,7 +760,7 @@ static int ov01a10_enum_mbus_code(struct v4l2_subdev *sd, if (code->index > 0) return -EINVAL; - code->code = MEDIA_BUS_FMT_SBGGR10_1X10; + code->code = OV01A10_MEDIA_BUS_FMT; return 0; } @@ -761,7 +770,7 @@ static int ov01a10_enum_frame_size(struct v4l2_subdev *sd, struct v4l2_subdev_frame_size_enum *fse) { if (fse->index >= ARRAY_SIZE(supported_modes) || - fse->code != MEDIA_BUS_FMT_SBGGR10_1X10) + fse->code != OV01A10_MEDIA_BUS_FMT) return -EINVAL; fse->min_width = supported_modes[fse->index].width; -- 2.51.0

3 weeks

2
1
0 0

FAILED: patch "[PATCH] serial: sc16is7xx: remove useless enable of enhanced features" 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 1c05bf6c0262f946571a37678250193e46b1ff0f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102739-fable-reroute-e6a6@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c05bf6c0262f946571a37678250193e46b1ff0f Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Mon, 6 Oct 2025 10:20:02 -0400 Subject: [PATCH] serial: sc16is7xx: remove useless enable of enhanced features Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that. Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured. Fixes: 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") Cc: stable <stable(a)kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://patch.msgid.link/20251006142002.177475-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 1a2c4c14f6aa..c7435595dce1 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud) div /= prescaler; } - /* Enable enhanced features */ - sc16is7xx_efr_lock(port); - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - sc16is7xx_efr_unlock(port); - /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT,

3 weeks

2
4
0 0

FAILED: patch "[PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 f3d12ec847b945d5d65846c85f062d07d5e73164 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102714-patriot-eel-32c8@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f3d12ec847b945d5d65846c85f062d07d5e73164 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 14 Oct 2025 01:55:41 +0300 Subject: [PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c index 63edf2d8f245..023a8ec6f305 100644 --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -892,7 +892,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) dev_info(dbc->dev, "DbC configured\n"); portsc = readl(&dbc->regs->portsc); writel(portsc, &dbc->regs->portsc); - return EVT_GSER; + ret = EVT_GSER; + break; } return EVT_DONE; @@ -954,7 +955,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) break; case TRB_TYPE(TRB_TRANSFER): dbc_handle_xfer_event(dbc, evt); - ret = EVT_XFER_DONE; + if (ret != EVT_GSER) + ret = EVT_XFER_DONE; break; default: break;

3 weeks

2
6
0 0

FAILED: patch "[PATCH] serial: 8250_dw: handle reset control deassert error" 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 daeb4037adf7d3349b4a1fb792f4bc9824686a4b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102700-sleep-robotics-c9e3@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From daeb4037adf7d3349b4a1fb792f4bc9824686a4b Mon Sep 17 00:00:00 2001 From: Artem Shimko <a.shimko.dev(a)gmail.com> Date: Sun, 19 Oct 2025 12:51:31 +0300 Subject: [PATCH] serial: 8250_dw: handle reset control deassert error Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails. Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted. The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics. Fixes: acbdad8dd1ab ("serial: 8250_dw: simplify optional reset handling") Cc: stable <stable(a)kernel.org> Signed-off-by: Artem Shimko <a.shimko.dev(a)gmail.com> Link: https://patch.msgid.link/20251019095131.252848-1-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index a53ba04d9770..710ae4d40aec 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -635,7 +635,9 @@ static int dw8250_probe(struct platform_device *pdev) if (IS_ERR(data->rst)) return PTR_ERR(data->rst); - reset_control_deassert(data->rst); + err = reset_control_deassert(data->rst); + if (err) + return dev_err_probe(dev, err, "failed to deassert resets\n"); err = devm_add_action_or_reset(dev, dw8250_reset_control_assert, data->rst); if (err)

3 weeks

2
2
0 0

FAILED: patch "[PATCH] serial: sc16is7xx: remove useless enable of enhanced features" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 1c05bf6c0262f946571a37678250193e46b1ff0f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102739-casualty-hankering-f9ab@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c05bf6c0262f946571a37678250193e46b1ff0f Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Mon, 6 Oct 2025 10:20:02 -0400 Subject: [PATCH] serial: sc16is7xx: remove useless enable of enhanced features Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that. Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured. Fixes: 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") Cc: stable <stable(a)kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://patch.msgid.link/20251006142002.177475-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 1a2c4c14f6aa..c7435595dce1 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud) div /= prescaler; } - /* Enable enhanced features */ - sc16is7xx_efr_lock(port); - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - sc16is7xx_efr_unlock(port); - /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT,

3 weeks

2
4
0 0

[[Name]]Alliance Ad

by Almus

3 weeks

1
0
0 0

[PATCH 0/4] drm/tidss: Fixes data edge sampling

by Louis Chauvet

Currently the driver only configure the data edge sampling partially. The AM62 require it to be configured in two distincts registers: one in tidss and one in the general device registers. Introduce a new dt property to link the proper syscon node from the main device registers into the tidss driver. Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem") --- Cc: stable(a)vger.kernel.org Signed-off-by: Louis Chauvet <louis.chauvet(a)bootlin.com> --- Louis Chauvet (4): dt-bindings: display: ti,am65x-dss: Add clk property for data edge synchronization dt-bindings: mfd: syscon: Add ti,am625-dss-clk-ctrl arm64: dts: ti: k3-am62-main: Add tidss clk-ctrl property drm/tidss: Fix sampling edge configuration .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 6 ++++++ Documentation/devicetree/bindings/mfd/syscon.yaml | 3 ++- arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 6 ++++++ drivers/gpu/drm/tidss/tidss_dispc.c | 14 ++++++++++++++ 4 files changed, 28 insertions(+), 1 deletion(-) --- base-commit: 85c23f28905cf20a86ceec3cfd7a0a5572c9eb13 change-id: 20250730-fix-edge-handling-9123f7438910 Best regards, -- Louis Chauvet <louis.chauvet(a)bootlin.com>

3 weeks

6
23
0 0

[PATCH v4 bpf 1/3] ftrace: Fix BPF fexit with livepatch

by Song Liu

When livepatch is attached to the same function as bpf trampoline with a fexit program, bpf trampoline code calls register_ftrace_direct() twice. The first time will fail with -EAGAIN, and the second time it will succeed. This requires register_ftrace_direct() to unregister the address on the first attempt. Otherwise, the bpf trampoline cannot attach. Here is an easy way to reproduce this issue: insmod samples/livepatch/livepatch-sample.ko bpftrace -e 'fexit:cmdline_proc_show {}' ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show... Fix this by cleaning up the hash when register_ftrace_function_nolock hits errors. Also, move the code that resets ops->func and ops->trampoline to the error path of register_ftrace_direct(); and add a helper function reset_direct() in register_ftrace_direct() and unregister_ftrace_direct(). Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Cc: stable(a)vger.kernel.org # v6.6+ Reported-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crow… Cc: Steven Rostedt (Google) <rostedt(a)goodmis.org> Cc: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Signed-off-by: Song Liu <song(a)kernel.org> Reviewed-by: Jiri Olsa <jolsa(a)kernel.org> --- kernel/bpf/trampoline.c | 5 ----- kernel/trace/ftrace.c | 20 ++++++++++++++------ 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c index 5949095e51c3..f2cb0b097093 100644 --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c @@ -479,11 +479,6 @@ static int bpf_trampoline_update(struct bpf_trampoline *tr, bool lock_direct_mut * BPF_TRAMP_F_SHARE_IPMODIFY is set, we can generate the * trampoline again, and retry register. */ - /* reset fops->func and fops->trampoline for re-register */ - tr->fops->func = NULL; - tr->fops->trampoline = 0; - - /* free im memory and reallocate later */ bpf_tramp_image_free(im); goto again; } diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 42bd2ba68a82..cbeb7e833131 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -5953,6 +5953,17 @@ static void register_ftrace_direct_cb(struct rcu_head *rhp) free_ftrace_hash(fhp); } +static void reset_direct(struct ftrace_ops *ops, unsigned long addr) +{ + struct ftrace_hash *hash = ops->func_hash->filter_hash; + + remove_direct_functions_hash(hash, addr); + + /* cleanup for possible another register call */ + ops->func = NULL; + ops->trampoline = 0; +} + /** * register_ftrace_direct - Call a custom trampoline directly * for multiple functions registered in @ops @@ -6048,6 +6059,8 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->direct_call = addr; err = register_ftrace_function_nolock(ops); + if (err) + reset_direct(ops, addr); out_unlock: mutex_unlock(&direct_mutex); @@ -6080,7 +6093,6 @@ EXPORT_SYMBOL_GPL(register_ftrace_direct); int unregister_ftrace_direct(struct ftrace_ops *ops, unsigned long addr, bool free_filters) { - struct ftrace_hash *hash = ops->func_hash->filter_hash; int err; if (check_direct_multi(ops)) @@ -6090,13 +6102,9 @@ int unregister_ftrace_direct(struct ftrace_ops *ops, unsigned long addr, mutex_lock(&direct_mutex); err = unregister_ftrace_function(ops); - remove_direct_functions_hash(hash, addr); + reset_direct(ops, addr); mutex_unlock(&direct_mutex); - /* cleanup for possible another register call */ - ops->func = NULL; - ops->trampoline = 0; - if (free_filters) ftrace_free_filter(ops); return err; -- 2.47.3

3 weeks

1
0
0 0

FAILED: patch "[PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races" 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 f3d12ec847b945d5d65846c85f062d07d5e73164 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102713-cucumber-persevere-aa50@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f3d12ec847b945d5d65846c85f062d07d5e73164 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 14 Oct 2025 01:55:41 +0300 Subject: [PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c index 63edf2d8f245..023a8ec6f305 100644 --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -892,7 +892,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) dev_info(dbc->dev, "DbC configured\n"); portsc = readl(&dbc->regs->portsc); writel(portsc, &dbc->regs->portsc); - return EVT_GSER; + ret = EVT_GSER; + break; } return EVT_DONE; @@ -954,7 +955,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) break; case TRB_TYPE(TRB_TRANSFER): dbc_handle_xfer_event(dbc, evt); - ret = EVT_XFER_DONE; + if (ret != EVT_GSER) + ret = EVT_XFER_DONE; break; default: break;

3 weeks

2
6
0 0

FAILED: patch "[PATCH] serial: 8250_dw: handle reset control deassert error" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 daeb4037adf7d3349b4a1fb792f4bc9824686a4b # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102700-impish-precook-5377@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From daeb4037adf7d3349b4a1fb792f4bc9824686a4b Mon Sep 17 00:00:00 2001 From: Artem Shimko <a.shimko.dev(a)gmail.com> Date: Sun, 19 Oct 2025 12:51:31 +0300 Subject: [PATCH] serial: 8250_dw: handle reset control deassert error Check the return value of reset_control_deassert() in the probe function to prevent continuing probe when reset deassertion fails. Previously, reset_control_deassert() was called without checking its return value, which could lead to probe continuing even when the device reset wasn't properly deasserted. The fix checks the return value and returns an error with dev_err_probe() if reset deassertion fails, providing better error handling and diagnostics. Fixes: acbdad8dd1ab ("serial: 8250_dw: simplify optional reset handling") Cc: stable <stable(a)kernel.org> Signed-off-by: Artem Shimko <a.shimko.dev(a)gmail.com> Link: https://patch.msgid.link/20251019095131.252848-1-a.shimko.dev@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c index a53ba04d9770..710ae4d40aec 100644 --- a/drivers/tty/serial/8250/8250_dw.c +++ b/drivers/tty/serial/8250/8250_dw.c @@ -635,7 +635,9 @@ static int dw8250_probe(struct platform_device *pdev) if (IS_ERR(data->rst)) return PTR_ERR(data->rst); - reset_control_deassert(data->rst); + err = reset_control_deassert(data->rst); + if (err) + return dev_err_probe(dev, err, "failed to deassert resets\n"); err = devm_add_action_or_reset(dev, dw8250_reset_control_assert, data->rst); if (err)

3 weeks

2
2
0 0

[PATCH] PCI/sysfs: enforce single creation of sysfs entry for pdev

by Christian Marangi

In some specific scenario it's possible that the pci_create_resource_files() gets called multiple times and the created entry actually gets wrongly deleted with extreme case of having a NULL pointer dereference when the PCI is removed. This mainly happen due to bad timing where the PCI bus is adding PCI devices and at the same time the sysfs code is adding the entry causing double execution of the pci_create_resource_files function and kernel WARNING. To be more precise there is a race between the late_initcall of pci-sysfs with pci_sysfs_init and PCI bus.c pci_bus_add_device that also call pci_create_sysfs_dev_files. With correct amount of ""luck"" (or better say bad luck) pci_create_sysfs_dev_files in bus.c might be called with pci_sysfs_init is executing the loop. This has been reported multiple times and on multiple system, like imx6 system, ipq806x systems... To address this, imlement multiple improvement to the implementation: 1. Add a bool to pci_dev to flag when sysfs entry are created (sysfs_init) 2. Implement a simple completion to wait pci_sysfs_init execution. 3. Permit additional call of pci_create_sysfs_dev_files only after pci_sysfs_init has finished. With such logic in place, we address al kind of timing problem with minimal change to any driver. A notice worth to mention is that the remove function are not affected by this as the pci_remove_resource_files have enough check in place to always work and it's always called by pci_stop_dev. Cc: stable(a)vger.kernel.org Reported-by: Krzysztof Hałasa <khalasa(a)piap.pl> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=215515 Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com> --- drivers/pci/pci-sysfs.c | 34 +++++++++++++++++++++++++++++----- include/linux/pci.h | 1 + 2 files changed, 30 insertions(+), 5 deletions(-) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 71a36f57ef57..cab3aa27f947 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -14,6 +14,7 @@ */ #include <linux/bitfield.h> +#include <linux/completion.h> #include <linux/kernel.h> #include <linux/sched.h> #include <linux/pci.h> @@ -37,6 +38,7 @@ #endif static int sysfs_initialized; /* = 0 */ +static DECLARE_COMPLETION(sysfs_init_completion); /* show configuration fields */ #define pci_config_attr(field, format_string) \ @@ -1652,12 +1654,32 @@ static const struct attribute_group pci_dev_resource_resize_group = { .is_visible = resource_resize_is_visible, }; +static int __pci_create_sysfs_dev_files(struct pci_dev *pdev) +{ + int ret; + + ret = pci_create_resource_files(pdev); + if (ret) + return ret; + + /* on success set sysfs correctly created */ + pdev->sysfs_init = true; + return 0; +} + int __must_check pci_create_sysfs_dev_files(struct pci_dev *pdev) { if (!sysfs_initialized) return -EACCES; - return pci_create_resource_files(pdev); + /* sysfs entry already created */ + if (pdev->sysfs_init) + return 0; + + /* wait for pci_sysfs_init */ + wait_for_completion(&sysfs_init_completion); + + return __pci_create_sysfs_dev_files(pdev); } /** @@ -1678,21 +1700,23 @@ static int __init pci_sysfs_init(void) { struct pci_dev *pdev = NULL; struct pci_bus *pbus = NULL; - int retval; + int retval = 0; sysfs_initialized = 1; for_each_pci_dev(pdev) { - retval = pci_create_sysfs_dev_files(pdev); + retval = __pci_create_sysfs_dev_files(pdev); if (retval) { pci_dev_put(pdev); - return retval; + goto exit; } } while ((pbus = pci_find_next_bus(pbus))) pci_create_legacy_files(pbus); - return 0; +exit: + complete_all(&sysfs_init_completion); + return retval; } late_initcall(pci_sysfs_init); diff --git a/include/linux/pci.h b/include/linux/pci.h index f3f6d6dee3ae..f417a0528f01 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -480,6 +480,7 @@ struct pci_dev { unsigned int non_mappable_bars:1; /* BARs can't be mapped to user-space */ pci_dev_flags_t dev_flags; atomic_t enable_cnt; /* pci_enable_device has been called */ + bool sysfs_init; /* sysfs entry has been created */ spinlock_t pcie_cap_lock; /* Protects RMW ops in capability accessors */ u32 saved_config_space[16]; /* Config space saved at suspend time */ -- 2.51.0

3 weeks

2
1
0 0

[PATCH v3 bpf 1/3] ftrace: Fix BPF fexit with livepatch

by Song Liu

When livepatch is attached to the same function as bpf trampoline with a fexit program, bpf trampoline code calls register_ftrace_direct() twice. The first time will fail with -EAGAIN, and the second time it will succeed. This requires register_ftrace_direct() to unregister the address on the first attempt. Otherwise, the bpf trampoline cannot attach. Here is an easy way to reproduce this issue: insmod samples/livepatch/livepatch-sample.ko bpftrace -e 'fexit:cmdline_proc_show {}' ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show... Fix this by cleaning up the hash when register_ftrace_function_nolock hits errors. Also, move the code that resets ops->func and ops->trampoline to the error path of register_ftrace_direct(). Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Cc: stable(a)vger.kernel.org # v6.6+ Reported-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crow… Cc: Steven Rostedt (Google) <rostedt(a)goodmis.org> Cc: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Signed-off-by: Song Liu <song(a)kernel.org> --- kernel/bpf/trampoline.c | 5 ----- kernel/trace/ftrace.c | 6 ++++++ 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c index 5949095e51c3..f2cb0b097093 100644 --- a/kernel/bpf/trampoline.c +++ b/kernel/bpf/trampoline.c @@ -479,11 +479,6 @@ static int bpf_trampoline_update(struct bpf_trampoline *tr, bool lock_direct_mut * BPF_TRAMP_F_SHARE_IPMODIFY is set, we can generate the * trampoline again, and retry register. */ - /* reset fops->func and fops->trampoline for re-register */ - tr->fops->func = NULL; - tr->fops->trampoline = 0; - - /* free im memory and reallocate later */ bpf_tramp_image_free(im); goto again; } diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 42bd2ba68a82..725c224fb4e6 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6048,6 +6048,12 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->direct_call = addr; err = register_ftrace_function_nolock(ops); + if (err) { + /* cleanup for possible another register call */ + ops->func = NULL; + ops->trampoline = 0; + remove_direct_functions_hash(hash, addr); + } out_unlock: mutex_unlock(&direct_mutex); -- 2.47.3

3 weeks

4
4
0 0

FAILED: patch "[PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR" 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 e84cb860ac3ce67ec6ecc364433fd5b412c448bc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102642-improper-revered-93ac@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e84cb860ac3ce67ec6ecc364433fd5b412c448bc Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:26 +0200 Subject: [PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR The special C-flag case expects the ADD_ADDR to be received when switching to 'fully-established'. But for various reasons, the ADD_ADDR could be sent after the "4th ACK", and the special case doesn't work. On NIPA, the new test validating this special case for the C-flag failed a few times, e.g. 102 default limits, server deny join id 0 syn rx [FAIL] got 0 JOIN[s] syn rx expected 2 Server ns stats (...) MPTcpExtAddAddrTx 1 MPTcpExtEchoAdd 1 Client ns stats (...) MPTcpExtAddAddr 1 MPTcpExtEchoAddTx 1 synack rx [FAIL] got 0 JOIN[s] synack rx expected 2 ack rx [FAIL] got 0 JOIN[s] ack rx expected 2 join Rx [FAIL] see above syn tx [FAIL] got 0 JOIN[s] syn tx expected 2 join Tx [FAIL] see above I had a suspicion about what the issue could be: the ADD_ADDR might have been received after the switch to the 'fully-established' state. The issue was not easy to reproduce. The packet capture shown that the ADD_ADDR can indeed be sent with a delay, and the client would not try to establish subflows to it as expected. A simple fix is not to mark the endpoints as 'used' in the C-flag case, when looking at creating subflows to the remote initial IP address and port. In this case, there is no need to try. Note: newly added fullmesh endpoints will still continue to be used as expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case. Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index e0f44dc232aa..2ae95476dba3 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -370,6 +370,10 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) } subflow: + /* No need to try establishing subflows to remote id0 if not allowed */ + if (mptcp_pm_add_addr_c_flag_case(msk)) + goto exit; + /* check if should create a new subflow */ while (msk->pm.local_addr_used < endp_subflow_max && msk->pm.extra_subflows < limit_extra_subflows) { @@ -401,6 +405,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) __mptcp_subflow_connect(sk, &local, &addrs[i]); spin_lock_bh(&msk->pm.lock); } + +exit: mptcp_pm_nl_check_work_pending(msk); }

3 weeks

2
1
0 0

FAILED: patch "[PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 f3d12ec847b945d5d65846c85f062d07d5e73164 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102712-unearned-duplicate-8c3b@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f3d12ec847b945d5d65846c85f062d07d5e73164 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 14 Oct 2025 01:55:41 +0300 Subject: [PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c index 63edf2d8f245..023a8ec6f305 100644 --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -892,7 +892,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) dev_info(dbc->dev, "DbC configured\n"); portsc = readl(&dbc->regs->portsc); writel(portsc, &dbc->regs->portsc); - return EVT_GSER; + ret = EVT_GSER; + break; } return EVT_DONE; @@ -954,7 +955,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) break; case TRB_TYPE(TRB_TRANSFER): dbc_handle_xfer_event(dbc, evt); - ret = EVT_XFER_DONE; + if (ret != EVT_GSER) + ret = EVT_XFER_DONE; break; default: break;

3 weeks

2
5
0 0

FAILED: patch "[PATCH] dt-bindings: usb: dwc3-imx8mp: dma-range is required only for" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 268eb6fb908bc82ce479e4dba9a2cad11f536c9c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102701-congrats-attire-807b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 268eb6fb908bc82ce479e4dba9a2cad11f536c9c Mon Sep 17 00:00:00 2001 From: Xu Yang <xu.yang_2(a)nxp.com> Date: Fri, 19 Sep 2025 14:25:34 +0800 Subject: [PATCH] dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp Only i.MX8MP need dma-range property to let USB controller work properly. Remove dma-range from required list and add limitation for imx8mp. Fixes: d2a704e29711 ("dt-bindings: usb: dwc3-imx8mp: add imx8mp dwc3 glue bindings") Cc: stable <stable(a)kernel.org> Reviewed-by: Jun Li <jun.li(a)nxp.com> Signed-off-by: Xu Yang <xu.yang_2(a)nxp.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Acked-by: Conor Dooley <conor.dooley(a)microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml index baf130669c38..73e7a60a0060 100644 --- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml @@ -89,13 +89,21 @@ required: - reg - "#address-cells" - "#size-cells" - - dma-ranges - ranges - clocks - clock-names - interrupts - power-domains +allOf: + - if: + properties: + compatible: + const: fsl,imx8mp-dwc3 + then: + required: + - dma-ranges + additionalProperties: false examples:

3 weeks

2
1
0 0

FAILED: patch "[PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 e84cb860ac3ce67ec6ecc364433fd5b412c448bc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102638-brewery-wanting-8089@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e84cb860ac3ce67ec6ecc364433fd5b412c448bc Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:26 +0200 Subject: [PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR The special C-flag case expects the ADD_ADDR to be received when switching to 'fully-established'. But for various reasons, the ADD_ADDR could be sent after the "4th ACK", and the special case doesn't work. On NIPA, the new test validating this special case for the C-flag failed a few times, e.g. 102 default limits, server deny join id 0 syn rx [FAIL] got 0 JOIN[s] syn rx expected 2 Server ns stats (...) MPTcpExtAddAddrTx 1 MPTcpExtEchoAdd 1 Client ns stats (...) MPTcpExtAddAddr 1 MPTcpExtEchoAddTx 1 synack rx [FAIL] got 0 JOIN[s] synack rx expected 2 ack rx [FAIL] got 0 JOIN[s] ack rx expected 2 join Rx [FAIL] see above syn tx [FAIL] got 0 JOIN[s] syn tx expected 2 join Tx [FAIL] see above I had a suspicion about what the issue could be: the ADD_ADDR might have been received after the switch to the 'fully-established' state. The issue was not easy to reproduce. The packet capture shown that the ADD_ADDR can indeed be sent with a delay, and the client would not try to establish subflows to it as expected. A simple fix is not to mark the endpoints as 'used' in the C-flag case, when looking at creating subflows to the remote initial IP address and port. In this case, there is no need to try. Note: newly added fullmesh endpoints will still continue to be used as expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case. Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index e0f44dc232aa..2ae95476dba3 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -370,6 +370,10 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) } subflow: + /* No need to try establishing subflows to remote id0 if not allowed */ + if (mptcp_pm_add_addr_c_flag_case(msk)) + goto exit; + /* check if should create a new subflow */ while (msk->pm.local_addr_used < endp_subflow_max && msk->pm.extra_subflows < limit_extra_subflows) { @@ -401,6 +405,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) __mptcp_subflow_connect(sk, &local, &addrs[i]); spin_lock_bh(&msk->pm.lock); } + +exit: mptcp_pm_nl_check_work_pending(msk); }

3 weeks

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102645-oblivion-whoopee-576c@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

3 weeks

3
2
0 0

, conoce mejor a tu candidato antes de contratar

by Valeria Pérez

Evaluaciones Psicométricas para RR.HH. 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; } Mejora tus procesos de selección con evaluaciones psicométricas fáciles y confiables. Hola, , Sabemos que encontrar al candidato ideal va más allá del currículum. Por eso quiero contarte brevemente sobre PsicoSmart, una plataforma que ayuda a equipos de RR.HH. a evaluar talento con pruebas psicométricas rápidas, confiables y fáciles de aplicar. Con PsicoSmart puedes: Aplicar evaluaciones psicométricas 100% en línea. Elegir entre más de 31 pruebas psicométricas Generar reportes automáticos, visuales y fáciles de interpretar. Comparar resultados entre candidatos en segundos. Ahorrar horas valiosas del proceso de selección. Si estás buscando mejorar tus contrataciones, te lo recomiendo muchísimo. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. 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=yiwtsrewisppyseup">click aquí</a>

3 weeks

1
0
0 0

, el clima laboral también se gestiona

by Daniel Rodríguez

Mejora el clima organizacional 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; } Diagnostica el clima y cultura de tu organización con Vorecol Work Environment. Hola, , El desempeño de un equipo no solo depende del talento individual, también del entorno en el que trabaja. Muchas veces, los problemas de rotación o bajo compromiso tienen raíces invisibles... hasta que se miden. Por eso quiero presentarte Vorecol Work Environment, una herramienta diseñada para ayudarte a comprender mejor cómo se vive la cultura y el clima dentro de tu organización. Con Vorecol puedes: Aplicar evaluaciones periódicas de clima y cultura organizacional, personalizadas a tu contexto. Obtener resultados organizados por áreas, con alertas sobre temas críticos como liderazgo, carga laboral o reconocimiento. Acceder a paneles dinámicos que te permiten visualizar tendencias, puntos de mejora y fortalezas de forma clara. Ideal para organizaciones que quieren escuchar más, reaccionar mejor y construir un entorno donde las personas quieran quedarse. Si estás buscando mejorar tu ambiente laboral, vale la pena considerarlo. Si quieres conocer más puedes responder este correo o simplemente contactarme, mis datos están abajo. Saludos, -------------- Atte.: Daniel Rodríguez 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=yiwtsrewisppuseup">click aquí</a>

3 weeks

1
0
0 0

[PATCH] media: c8sectpfe: fix probe device leaks

by Johan Hovold

Make sure to drop the references taken to the I2C adapters during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Cc: stable(a)vger.kernel.org # 4.3 Cc: Peter Griffin <peter.griffin(a)linaro.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- .../media/platform/st/sti/c8sectpfe/c8sectpfe-core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c b/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c index 89bd15a4d26a..3f94d9b4ef1e 100644 --- a/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c +++ b/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c @@ -655,6 +655,13 @@ static irqreturn_t c8sectpfe_error_irq_handler(int irq, void *priv) return IRQ_HANDLED; } +static void c8sectpfe_put_device(void *_dev) +{ + struct device *dev = _dev; + + put_device(dev); +} + static int c8sectpfe_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -799,6 +806,11 @@ static int c8sectpfe_probe(struct platform_device *pdev) return -ENODEV; } + ret = devm_add_action_or_reset(dev, c8sectpfe_put_device, + &tsin->i2c_adapter->dev); + if (ret) + return ret; + /* Acquire reset GPIO and activate it */ tsin->rst_gpio = devm_fwnode_gpiod_get(dev, of_fwnode_handle(child), -- 2.49.1

3 weeks

3
4
0 0

FAILED: patch "[PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x e84cb860ac3ce67ec6ecc364433fd5b412c448bc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102634-cache-seventeen-becb@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e84cb860ac3ce67ec6ecc364433fd5b412c448bc Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:26 +0200 Subject: [PATCH] mptcp: pm: in-kernel: C-flag: handle late ADD_ADDR The special C-flag case expects the ADD_ADDR to be received when switching to 'fully-established'. But for various reasons, the ADD_ADDR could be sent after the "4th ACK", and the special case doesn't work. On NIPA, the new test validating this special case for the C-flag failed a few times, e.g. 102 default limits, server deny join id 0 syn rx [FAIL] got 0 JOIN[s] syn rx expected 2 Server ns stats (...) MPTcpExtAddAddrTx 1 MPTcpExtEchoAdd 1 Client ns stats (...) MPTcpExtAddAddr 1 MPTcpExtEchoAddTx 1 synack rx [FAIL] got 0 JOIN[s] synack rx expected 2 ack rx [FAIL] got 0 JOIN[s] ack rx expected 2 join Rx [FAIL] see above syn tx [FAIL] got 0 JOIN[s] syn tx expected 2 join Tx [FAIL] see above I had a suspicion about what the issue could be: the ADD_ADDR might have been received after the switch to the 'fully-established' state. The issue was not easy to reproduce. The packet capture shown that the ADD_ADDR can indeed be sent with a delay, and the client would not try to establish subflows to it as expected. A simple fix is not to mark the endpoints as 'used' in the C-flag case, when looking at creating subflows to the remote initial IP address and port. In this case, there is no need to try. Note: newly added fullmesh endpoints will still continue to be used as expected, thanks to the conditions behind mptcp_pm_add_addr_c_flag_case. Fixes: 4b1ff850e0c1 ("mptcp: pm: in-kernel: usable client side with C-flag") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-1-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/net/mptcp/pm_kernel.c b/net/mptcp/pm_kernel.c index e0f44dc232aa..2ae95476dba3 100644 --- a/net/mptcp/pm_kernel.c +++ b/net/mptcp/pm_kernel.c @@ -370,6 +370,10 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) } subflow: + /* No need to try establishing subflows to remote id0 if not allowed */ + if (mptcp_pm_add_addr_c_flag_case(msk)) + goto exit; + /* check if should create a new subflow */ while (msk->pm.local_addr_used < endp_subflow_max && msk->pm.extra_subflows < limit_extra_subflows) { @@ -401,6 +405,8 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) __mptcp_subflow_connect(sk, &local, &addrs[i]); spin_lock_bh(&msk->pm.lock); } + +exit: mptcp_pm_nl_check_work_pending(msk); }

3 weeks

2
1
0 0

FAILED: patch "[PATCH] dt-bindings: usb: dwc3-imx8mp: dma-range is required only for" 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 268eb6fb908bc82ce479e4dba9a2cad11f536c9c # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102701-refinish-carrot-c75e@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 268eb6fb908bc82ce479e4dba9a2cad11f536c9c Mon Sep 17 00:00:00 2001 From: Xu Yang <xu.yang_2(a)nxp.com> Date: Fri, 19 Sep 2025 14:25:34 +0800 Subject: [PATCH] dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp Only i.MX8MP need dma-range property to let USB controller work properly. Remove dma-range from required list and add limitation for imx8mp. Fixes: d2a704e29711 ("dt-bindings: usb: dwc3-imx8mp: add imx8mp dwc3 glue bindings") Cc: stable <stable(a)kernel.org> Reviewed-by: Jun Li <jun.li(a)nxp.com> Signed-off-by: Xu Yang <xu.yang_2(a)nxp.com> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Acked-by: Conor Dooley <conor.dooley(a)microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml index baf130669c38..73e7a60a0060 100644 --- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml @@ -89,13 +89,21 @@ required: - reg - "#address-cells" - "#size-cells" - - dma-ranges - ranges - clocks - clock-names - interrupts - power-domains +allOf: + - if: + properties: + compatible: + const: fsl,imx8mp-dwc3 + then: + required: + - dma-ranges + additionalProperties: false examples:

3 weeks

2
1
0 0

[PATCH] amba: tegra-ahb: fix reference count leak in tegra_ahb_enable_smmu

by Miaoqian Lin

The driver_find_device_by_of_node() function returns a device with its reference count incremented. driver_find_device_by_of_node() is an inline wrapper that calls driver_find_device(), which calls get_device(dev) and returns the found device with an incremented reference count. Fix this by adding the missing put_device() call after the device operations are completed. Found via static analysis. Fixes: 89c788bab1f0 ("ARM: tegra: Add SMMU enabler in AHB") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/amba/tegra-ahb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/amba/tegra-ahb.c b/drivers/amba/tegra-ahb.c index c0e8b765522d..6c306d017b67 100644 --- a/drivers/amba/tegra-ahb.c +++ b/drivers/amba/tegra-ahb.c @@ -147,6 +147,7 @@ int tegra_ahb_enable_smmu(struct device_node *dn) val = gizmo_readl(ahb, AHB_ARBITRATION_XBAR_CTRL); val |= AHB_ARBITRATION_XBAR_CTRL_SMMU_INIT_DONE; gizmo_writel(ahb, val, AHB_ARBITRATION_XBAR_CTRL); + put_device(dev); return 0; } EXPORT_SYMBOL(tegra_ahb_enable_smmu); -- 2.39.5 (Apple Git-154)

3 weeks

1
0
0 0

[PATCH v2] s390/mm: Fix memory leak in add_marker() when kvrealloc fails

by Miaoqian Lin

The function has a memory leak when kvrealloc() fails. The function directly assigns NULL to the markers pointer, losing the reference to the previously allocated memory. This causes kvfree() in pt_dump_init() to free NULL instead of the leaked memory. Fix by: 1. Using kvrealloc() uniformly for all allocations 2. Using a temporary variable to preserve the original pointer until allocation succeeds 3. Removing the error path that sets markers_cnt=0 to keep consistency between markers and markers_cnt Found via static analysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- changes in v2: - update the fixing logic to prevent memory leak in v1 v1 link: https://lore.kernel.org/all/20251026091351.36275-1-linmq006@gmail.com/ --- arch/s390/mm/dump_pagetables.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c index 9af2aae0a515..ab0c1fcf2782 100644 --- a/arch/s390/mm/dump_pagetables.c +++ b/arch/s390/mm/dump_pagetables.c @@ -291,16 +291,15 @@ static int ptdump_cmp(const void *a, const void *b) static int add_marker(unsigned long start, unsigned long end, const char *name) { - size_t oldsize, newsize; - - oldsize = markers_cnt * sizeof(*markers); - newsize = oldsize + 2 * sizeof(*markers); - if (!oldsize) - markers = kvmalloc(newsize, GFP_KERNEL); - else - markers = kvrealloc(markers, newsize, GFP_KERNEL); - if (!markers) - goto error; + struct addr_marker *new_markers; + size_t newsize; + + newsize = (markers_cnt + 2) * sizeof(*markers); + new_markers = kvrealloc(markers, newsize, GFP_KERNEL); + if (!new_markers) + return -ENOMEM; + + markers = new_markers; markers[markers_cnt].is_start = 1; markers[markers_cnt].start_address = start; markers[markers_cnt].size = end - start; @@ -312,9 +311,6 @@ static int add_marker(unsigned long start, unsigned long end, const char *name) markers[markers_cnt].name = name; markers_cnt++; return 0; -error: - markers_cnt = 0; - return -ENOMEM; } static int pt_dump_init(void) -- 2.39.5 (Apple Git-154)

3 weeks

2
1
0 0

[PATCH net v5] virtio-net: fix received length check in big packets

by Bui Quang Minh

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 v5: - Move the length check to receive_big - Link to v4: https://lore.kernel.org/netdev/20251022160623.51191-1-minhquangbui99@gmail.… Changes in v4: - Remove unrelated changes, add more comments - Link to v3: https://lore.kernel.org/netdev/20251021154534.53045-1-minhquangbui99@gmail.… Changes in v3: - Convert BUG_ON to WARN_ON_ONCE - Link to v2: https://lore.kernel.org/netdev/20250708144206.95091-1-minhquangbui99@gmail.… Changes in v2: - Remove incorrect give_pages call - Link to v1: https://lore.kernel.org/netdev/20250706141150.25344-1-minhquangbui99@gmail.… --- drivers/net/virtio_net.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index a757cbcab87f..2c3f544add5e 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -910,17 +910,6 @@ static struct sk_buff *page_to_skb(struct virtnet_info *vi, goto ok; } - /* - * Verify that we can indeed put this data into a skb. - * 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. - */ - if (unlikely(len > MAX_SKB_FRAGS * PAGE_SIZE)) { - 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); @@ -2107,9 +2096,19 @@ static struct sk_buff *receive_big(struct net_device *dev, struct virtnet_rq_stats *stats) { struct page *page = buf; - struct sk_buff *skb = - page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, 0); + struct sk_buff *skb; + + /* Make sure that len does not exceed the allocated size in + * add_recvbuf_big. + */ + if (unlikely(len > vi->big_packets_num_skbfrags * PAGE_SIZE)) { + pr_debug("%s: rx error: len %u exceeds allocate size %lu\n", + dev->name, len, + vi->big_packets_num_skbfrags * PAGE_SIZE); + goto err; + } + skb = page_to_skb(vi, rq, page, 0, len, PAGE_SIZE, 0); u64_stats_add(&stats->bytes, len - vi->hdr_len); if (unlikely(!skb)) goto err; -- 2.43.0

3 weeks

3
7
0 0

[PATCH] serial: amba-pl011: prefer dma_mapping_error() over explicit address checking

by Miaoqian Lin

Check for returned DMA addresses using specialized dma_mapping_error() helper which is generally recommended for this purpose by Documentation/core-api/dma-api.rst: "In some circumstances dma_map_single(), ... will fail to create a mapping. A driver can check for these errors by testing the returned DMA address with dma_mapping_error()." Found via static analysis and this is similar to commit fa0308134d26 ("ALSA: memalloc: prefer dma_mapping_error() over explicit address checking") Fixes: 58ac1b379979 ("ARM: PL011: Fix DMA support") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/tty/serial/amba-pl011.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index 22939841b1de..7f17d288c807 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -628,7 +628,7 @@ static int pl011_dma_tx_refill(struct uart_amba_port *uap) dmatx->len = count; dmatx->dma = dma_map_single(dma_dev->dev, dmatx->buf, count, DMA_TO_DEVICE); - if (dmatx->dma == DMA_MAPPING_ERROR) { + if (dma_mapping_error(dma_dev->dev, dmatx->dma)) { uap->dmatx.queued = false; dev_dbg(uap->port.dev, "unable to map TX DMA\n"); return -EBUSY; -- 2.39.5 (Apple Git-154)

3 weeks

2
1
0 0

[PATCH 0/2] drm/xe: Fix some rebar issues

by Lucas De Marchi

Our implementation for BAR2 (lmembar) resize works at the xe_vram layer and only releases that BAR before resizing. That is not always sufficient. If the parent bridge needs to move, the BAR0 also needs to be released, otherwise the resize fails. This is the case of not having enough space allocated from the beginning. Also, there's a BAR0 in the upstream port of the pcie switch in BMG preventing the resize to propagate to the bridge as previously discussed in https://lore.kernel.org/intel-xe/20250721173057.867829-1-uwu@icenowy.me/ and https://lore.kernel.org/intel-xe/wqukxnxni2dbpdhri3cbvlrzsefgdanesgskzmxi5s… I'm bringing that commit from Ilpo here so this can be tested with the xe changes and propagate to stable. Note that the use of a pci fixup is not ideal, but without intrusive changes on resource fitting it's possibly the best alternative. I also have confirmation from HW folks that the BAR in the upstream port has no production use. I have more cleanups on top on the xe side, but those conflict with some refactors Ilpo is working on as prep for the resource fitting, so I will wait things settle to submit again. I propose to take this through the drm tree. With this I could resize the lmembar on some problematic hosts and after doing an SBR, with one caveat: the audio device also prevents the BAR from moving and it needs to be manually removed before resizing. With the PCI refactors and BAR fitting logic that Ilpo is working on, it's expected that it won't be needed for a long time. Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- Ilpo Järvinen (1): PCI: Release BAR0 of an integrated bridge to allow GPU BAR resize Lucas De Marchi (1): drm/xe: Move rebar to be done earlier drivers/gpu/drm/xe/xe_pci.c | 2 ++ drivers/gpu/drm/xe/xe_vram.c | 34 ++++++++++++++++++++++++++-------- drivers/gpu/drm/xe/xe_vram.h | 1 + drivers/pci/quirks.c | 23 +++++++++++++++++++++++ 4 files changed, 52 insertions(+), 8 deletions(-) base-commit: 8031d70dbb4201841897de480cec1f9750d4a5dc change-id: 20250917-xe-pci-rebar-2-c0fe2f04c879 Lucas De Marchi

3 weeks

3
9
0 0

FAILED: patch "[PATCH] net: ravb: Enforce descriptor type ordering" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 5370c31e84b0e0999c7b5ff949f4e104def35584 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102624-direness-catalyze-d721@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5370c31e84b0e0999c7b5ff949f4e104def35584 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Date: Fri, 17 Oct 2025 16:18:29 +0100 Subject: [PATCH] net: ravb: Enforce descriptor type ordering MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ensure the TX descriptor type fields are published in a safe order so the DMA engine never begins processing a descriptor chain before all descriptor fields are fully initialised. For multi-descriptor transmits the driver writes DT_FEND into the last descriptor and DT_FSTART into the first. The DMA engine begins processing when it observes DT_FSTART. Move the dma_wmb() barrier so it executes immediately after DT_FEND and immediately before writing DT_FSTART (and before DT_FSINGLE in the single-descriptor case). This guarantees that all prior CPU writes to the descriptor memory are visible to the device before DT_FSTART is seen. This avoids a situation where compiler/CPU reordering could publish DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to start on a partially initialised chain and causing corrupted transmissions or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as transmit queue timeouts and device resets. Fixes: 2f45d1902acf ("ravb: minimize TX data copying") Cc: stable(a)vger.kernel.org Co-developed-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Link: https://patch.msgid.link/20251017151830.171062-4-prabhakar.mahadev-lad.rj@b… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c index 9d3bd65b85ff..044ee83c63bb 100644 --- a/drivers/net/ethernet/renesas/ravb_main.c +++ b/drivers/net/ethernet/renesas/ravb_main.c @@ -2211,13 +2211,25 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev) skb_tx_timestamp(skb); } - /* Descriptor type must be set after all the above writes */ - dma_wmb(); + if (num_tx_desc > 1) { desc->die_dt = DT_FEND; desc--; + /* When using multi-descriptors, DT_FEND needs to get written + * before DT_FSTART, but the compiler may reorder the memory + * writes in an attempt to optimize the code. + * Use a dma_wmb() barrier to make sure DT_FEND and DT_FSTART + * are written exactly in the order shown in the code. + * This is particularly important for cases where the DMA engine + * is already running when we are running this code. If the DMA + * sees DT_FSTART without the corresponding DT_FEND it will enter + * an error condition. + */ + dma_wmb(); desc->die_dt = DT_FSTART; } else { + /* Descriptor type must be set after all the above writes */ + dma_wmb(); desc->die_dt = DT_FSINGLE; } ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);

3 weeks

2
1
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: mark 'delete re-add signal' as" 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 c3496c052ac36ea98ec4f8e95ae6285a425a2457 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102628-overrun-runny-87fb@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c3496c052ac36ea98ec4f8e95ae6285a425a2457 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:29 +0200 Subject: [PATCH] selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported The call to 'continue_if' was missing: it properly marks a subtest as 'skipped' if the attached condition is not valid. Without that, the test is wrongly marked as passed on older kernels. Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-4-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index d98f8f8905b9..b2a8c51a3969 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -4040,7 +4040,7 @@ endpoint_tests() # remove and re-add if reset_with_events "delete re-add signal" && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=0 pm_nl_set_limits $ns1 0 3 pm_nl_set_limits $ns2 3 3

3 weeks

2
2
0 0

FAILED: patch "[PATCH] net: ravb: Enforce descriptor type ordering" 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 5370c31e84b0e0999c7b5ff949f4e104def35584 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102624-thirsty-otter-d285@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5370c31e84b0e0999c7b5ff949f4e104def35584 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Date: Fri, 17 Oct 2025 16:18:29 +0100 Subject: [PATCH] net: ravb: Enforce descriptor type ordering MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ensure the TX descriptor type fields are published in a safe order so the DMA engine never begins processing a descriptor chain before all descriptor fields are fully initialised. For multi-descriptor transmits the driver writes DT_FEND into the last descriptor and DT_FSTART into the first. The DMA engine begins processing when it observes DT_FSTART. Move the dma_wmb() barrier so it executes immediately after DT_FEND and immediately before writing DT_FSTART (and before DT_FSINGLE in the single-descriptor case). This guarantees that all prior CPU writes to the descriptor memory are visible to the device before DT_FSTART is seen. This avoids a situation where compiler/CPU reordering could publish DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to start on a partially initialised chain and causing corrupted transmissions or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as transmit queue timeouts and device resets. Fixes: 2f45d1902acf ("ravb: minimize TX data copying") Cc: stable(a)vger.kernel.org Co-developed-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Link: https://patch.msgid.link/20251017151830.171062-4-prabhakar.mahadev-lad.rj@b… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c index 9d3bd65b85ff..044ee83c63bb 100644 --- a/drivers/net/ethernet/renesas/ravb_main.c +++ b/drivers/net/ethernet/renesas/ravb_main.c @@ -2211,13 +2211,25 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev) skb_tx_timestamp(skb); } - /* Descriptor type must be set after all the above writes */ - dma_wmb(); + if (num_tx_desc > 1) { desc->die_dt = DT_FEND; desc--; + /* When using multi-descriptors, DT_FEND needs to get written + * before DT_FSTART, but the compiler may reorder the memory + * writes in an attempt to optimize the code. + * Use a dma_wmb() barrier to make sure DT_FEND and DT_FSTART + * are written exactly in the order shown in the code. + * This is particularly important for cases where the DMA engine + * is already running when we are running this code. If the DMA + * sees DT_FSTART without the corresponding DT_FEND it will enter + * an error condition. + */ + dma_wmb(); desc->die_dt = DT_FSTART; } else { + /* Descriptor type must be set after all the above writes */ + dma_wmb(); desc->die_dt = DT_FSINGLE; } ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);

3 weeks

2
1
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: mark 'delete re-add signal' as" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 c3496c052ac36ea98ec4f8e95ae6285a425a2457 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102627-tug-sabbath-3edb@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c3496c052ac36ea98ec4f8e95ae6285a425a2457 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:29 +0200 Subject: [PATCH] selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported The call to 'continue_if' was missing: it properly marks a subtest as 'skipped' if the attached condition is not valid. Without that, the test is wrongly marked as passed on older kernels. Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-4-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index d98f8f8905b9..b2a8c51a3969 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -4040,7 +4040,7 @@ endpoint_tests() # remove and re-add if reset_with_events "delete re-add signal" && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=0 pm_nl_set_limits $ns1 0 3 pm_nl_set_limits $ns2 3 3

3 weeks

2
2
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: mark 'delete re-add signal' as" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x c3496c052ac36ea98ec4f8e95ae6285a425a2457 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102627-enclosure-issue-a264@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c3496c052ac36ea98ec4f8e95ae6285a425a2457 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:29 +0200 Subject: [PATCH] selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported The call to 'continue_if' was missing: it properly marks a subtest as 'skipped' if the attached condition is not valid. Without that, the test is wrongly marked as passed on older kernels. Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-4-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index d98f8f8905b9..b2a8c51a3969 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -4040,7 +4040,7 @@ endpoint_tests() # remove and re-add if reset_with_events "delete re-add signal" && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=0 pm_nl_set_limits $ns1 0 3 pm_nl_set_limits $ns2 3 3

3 weeks

2
2
0 0

[PATCH] soc: qcom: gsbi: fix double disable caused by devm

by Haotian Zhang

In the commit referenced by the Fixes tag, devm_clk_get_enabled() was introduced to replace devm_clk_get() and clk_prepare_enable(). While the clk_disable_unprepare() call in the error path was correctly removed, the one in the remove function was overlooked, leading to a double disable issue. Remove the redundant clk_disable_unprepare() call from gsbi_remove() to fix this issue. Since all resources are now managed by devres and will be automatically released, the remove function serves no purpose and can be deleted entirely. Fixes: 489d7a8cc286 ("soc: qcom: use devm_clk_get_enabled() in gsbi_probe()") Signed-off-by: Haotian Zhang <vulab(a)iscas.ac.cn> --- drivers/soc/qcom/qcom_gsbi.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/soc/qcom/qcom_gsbi.c b/drivers/soc/qcom/qcom_gsbi.c index 8f1158e0c631..a25d1de592f0 100644 --- a/drivers/soc/qcom/qcom_gsbi.c +++ b/drivers/soc/qcom/qcom_gsbi.c @@ -212,13 +212,6 @@ static int gsbi_probe(struct platform_device *pdev) return of_platform_populate(node, NULL, NULL, &pdev->dev); } -static void gsbi_remove(struct platform_device *pdev) -{ - struct gsbi_info *gsbi = platform_get_drvdata(pdev); - - clk_disable_unprepare(gsbi->hclk); -} - static const struct of_device_id gsbi_dt_match[] = { { .compatible = "qcom,gsbi-v1.0.0", }, { }, @@ -232,7 +225,6 @@ static struct platform_driver gsbi_driver = { .of_match_table = gsbi_dt_match, }, .probe = gsbi_probe, - .remove = gsbi_remove, }; module_platform_driver(gsbi_driver); -- 2.25.1

3 weeks

4
3
0 0

[PATCH 0/2] Kconfig fixes for QCOM clk drivers when targeting ARCH=arm

by Nathan Chancellor

Hi all, This series resolves two new Kconfig warnings that I see in my test framework from an ARM configuration getting bumped to 6.17 and enabling these configurations in the process. --- Nathan Chancellor (2): clk: qcom: Fix SM_VIDEOCC_6350 dependencies clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615 drivers/clk/qcom/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) --- base-commit: 30bf3ec8cb6b2d2e2f8715388395cbd27cbe4fc9 change-id: 20250930-clk-qcom-kconfig-fixes-arm-3611dec03c3e Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

3 weeks

4
7
0 0

[PATCH v2] usb: renesas_usbhs: Fix synchronous external abort on unbind

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo "0x1d6b" > idVendor echo "0x0104" > idProduct mkdir -p strings/0x409 echo "0123456789" > strings/0x409/serialnumber echo "Renesas." > strings/0x409/manufacturer echo "Ethernet Gadget" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo "ECM" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove. Cc: stable(a)vger.kernel.org Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- Changes in v2: - moved usbhsc_clk_put() before pm_runtime_disable() Patch was tested with continuous unbind/bind and the configuration sequence described above on the boards with the following device trees: - r8a774a1-hihope-rzg2m-ex.dts - r8a774b1-hihope-rzg2n-ex.dts - r8a774e1-hihope-rzg2h-ex.dts - r9a07g043u11-smarc.dts - r9a07g044c2-smarc.dts - r9a07g044l2-smarc.dts - r9a07g054l2-smarc.dts drivers/usb/renesas_usbhs/common.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index 8f536f2c500f..dc2fec9168b7 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -813,18 +813,18 @@ static void usbhs_remove(struct platform_device *pdev) flush_delayed_work(&priv->notify_hotplug_work); - /* power off */ - if (!usbhs_get_dparam(priv, runtime_pwctrl)) - usbhsc_power_ctrl(priv, 0); - - pm_runtime_disable(&pdev->dev); - usbhs_platform_call(priv, hardware_exit, pdev); - usbhsc_clk_put(priv); reset_control_assert(priv->rsts); usbhs_mod_remove(priv); usbhs_fifo_remove(priv); usbhs_pipe_remove(priv); + + /* power off */ + if (!usbhs_get_dparam(priv, runtime_pwctrl)) + usbhsc_power_ctrl(priv, 0); + + usbhsc_clk_put(priv); + pm_runtime_disable(&pdev->dev); } static int usbhsc_suspend(struct device *dev) -- 2.43.0

3 weeks

1
0
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘of_get_cpu_node’? [-Werror=implicit-function-declaration] in arch/riscv/kernel/cpu.o (arch/riscv/kernel/cpu.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:aa2fc1f4fdbcaf13e029f04263806fde636d74fd - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 7288ed51fe2777d083b6cb13bd2d18f368fa425d Log excerpt: ===================================================== arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘of_get_cpu_node’? [-Werror=implicit-function-declaration] 24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0); | ^~~~~~~~~~~~~~~ | of_get_cpu_node AR init/built-in.a CC kernel/locking/mutex.o CC arch/riscv/mm/fault.o cc1: some warnings being treated as errors ===================================================== # Builds where the incident occurred: ## defconfig on (riscv): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-riscv-68ff66e51198e7d4c92ca056/.co… - dashboard: https://d.kernelci.org/build/maestro:68ff66e51198e7d4c92ca056 #kernelci issue maestro:aa2fc1f4fdbcaf13e029f04263806fde636d74fd Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) unused variable ‘ext_end’ [-Wunused-variable] in arch/riscv/kernel...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- unused variable ‘ext_end’ [-Wunused-variable] in arch/riscv/kernel/cpu.o (arch/riscv/kernel/cpufeature.c) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:5135288c90855e0205f0a76b012c159c9f2e4f97 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 2e86ed6526626d22b225d03a7faf8bd09dca2a5b Log excerpt: ===================================================== arch/riscv/kernel/cpufeature.c:107:37: warning: unused variable ‘ext_end’ [-Wunused-variable] 107 | const char *ext_end = isa; | ^~~~~~~ arch/riscv/kernel/cpu.c: In function ‘riscv_of_processor_hartid’: arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘of_get_cpu_node’? [-Werror=implicit-function-declaration] 24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0); | ^~~~~~~~~~~~~~~ | of_get_cpu_node cc1: some warnings being treated as errors ===================================================== # Builds where the incident occurred: ## defconfig on (riscv): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-riscv-68ff67651198e7d4c92ca10f/.co… - dashboard: https://d.kernelci.org/build/maestro:68ff67651198e7d4c92ca10f ## nommu_k210_defconfig on (riscv): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-riscv-nommu_k210_defconfig-68ff66e… - dashboard: https://d.kernelci.org/build/maestro:68ff66e91198e7d4c92ca077 #kernelci issue maestro:5135288c90855e0205f0a76b012c159c9f2e4f97 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

3 weeks

1
0
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102625-cringing-unstuck-790a@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

3 weeks

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" 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 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102617-untrimmed-ideally-b80b@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

3 weeks

2
1
0 0

FAILED: patch "[PATCH] net: ravb: Enforce descriptor type ordering" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 5370c31e84b0e0999c7b5ff949f4e104def35584 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102623-footless-outcast-b793@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5370c31e84b0e0999c7b5ff949f4e104def35584 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Date: Fri, 17 Oct 2025 16:18:29 +0100 Subject: [PATCH] net: ravb: Enforce descriptor type ordering MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ensure the TX descriptor type fields are published in a safe order so the DMA engine never begins processing a descriptor chain before all descriptor fields are fully initialised. For multi-descriptor transmits the driver writes DT_FEND into the last descriptor and DT_FSTART into the first. The DMA engine begins processing when it observes DT_FSTART. Move the dma_wmb() barrier so it executes immediately after DT_FEND and immediately before writing DT_FSTART (and before DT_FSINGLE in the single-descriptor case). This guarantees that all prior CPU writes to the descriptor memory are visible to the device before DT_FSTART is seen. This avoids a situation where compiler/CPU reordering could publish DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to start on a partially initialised chain and causing corrupted transmissions or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as transmit queue timeouts and device resets. Fixes: 2f45d1902acf ("ravb: minimize TX data copying") Cc: stable(a)vger.kernel.org Co-developed-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Link: https://patch.msgid.link/20251017151830.171062-4-prabhakar.mahadev-lad.rj@b… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c index 9d3bd65b85ff..044ee83c63bb 100644 --- a/drivers/net/ethernet/renesas/ravb_main.c +++ b/drivers/net/ethernet/renesas/ravb_main.c @@ -2211,13 +2211,25 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev) skb_tx_timestamp(skb); } - /* Descriptor type must be set after all the above writes */ - dma_wmb(); + if (num_tx_desc > 1) { desc->die_dt = DT_FEND; desc--; + /* When using multi-descriptors, DT_FEND needs to get written + * before DT_FSTART, but the compiler may reorder the memory + * writes in an attempt to optimize the code. + * Use a dma_wmb() barrier to make sure DT_FEND and DT_FSTART + * are written exactly in the order shown in the code. + * This is particularly important for cases where the DMA engine + * is already running when we are running this code. If the DMA + * sees DT_FSTART without the corresponding DT_FEND it will enter + * an error condition. + */ + dma_wmb(); desc->die_dt = DT_FSTART; } else { + /* Descriptor type must be set after all the above writes */ + dma_wmb(); desc->die_dt = DT_FSINGLE; } ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);

3 weeks

2
2
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" 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 a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102624-aspect-stumble-aea9@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

3 weeks

2
1
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102041-mounting-pursuit-e9d3@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

3 weeks

3
4
0 0

[PATCH] drm/nouveau: Fix race in nouveau_sched_fini()

by Philipp Stanner

nouveau_sched_fini() uses a memory barrier before wait_event(). wait_event(), however, is a macro which expands to a loop which might check the passed condition several times. The barrier would only take effect for the first check. Replace the barrier with a function which takes the spinlock. Cc: stable(a)vger.kernel.org # v6.8+ Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- drivers/gpu/drm/nouveau/nouveau_sched.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c b/drivers/gpu/drm/nouveau/nouveau_sched.c index e60f7892f5ce..a7bf539e5d86 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sched.c +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c @@ -482,6 +482,17 @@ nouveau_sched_create(struct nouveau_sched **psched, struct nouveau_drm *drm, return 0; } +static bool +nouveau_sched_job_list_empty(struct nouveau_sched *sched) +{ + bool empty; + + spin_lock(&sched->job.list.lock); + empty = list_empty(&sched->job.list.head); + spin_unlock(&sched->job.list.lock); + + return empty; +} static void nouveau_sched_fini(struct nouveau_sched *sched) @@ -489,8 +500,7 @@ nouveau_sched_fini(struct nouveau_sched *sched) struct drm_gpu_scheduler *drm_sched = &sched->base; struct drm_sched_entity *entity = &sched->entity; - rmb(); /* for list_empty to work without lock */ - wait_event(sched->job.wq, list_empty(&sched->job.list.head)); + wait_event(sched->job.wq, nouveau_sched_job_list_empty(sched)); drm_sched_entity_fini(entity); drm_sched_fini(drm_sched); -- 2.49.0

3 weeks

3
2
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" 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 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102040-unusual-concur-90e9@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

3 weeks

3
6
0 0

[PATCH] drm/sched: Fix race in drm_sched_entity_select_rq()

by Philipp Stanner

In a past bug fix it was forgotten that entity access must be protected by the entity lock. That's a data race and potentially UB. Move the spin_unlock() to the appropriate position. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- drivers/gpu/drm/scheduler/sched_entity.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 5a4697f636f2..aa222166de58 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -552,10 +552,11 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) drm_sched_rq_remove_entity(entity->rq, entity); entity->rq = rq; } - spin_unlock(&entity->lock); if (entity->num_sched_list == 1) entity->sched_list = NULL; + + spin_unlock(&entity->lock); } /** -- 2.49.0

3 weeks

3
2
0 0

[PATCH] scripts/quilt-mail: add my new email address

by Slade Watkins

My old email address is no longer valid and was bouncing. Add my new one instead. Signed-off-by: Slade Watkins <sr(a)sladewatkins.com> --- scripts/quilt-mail | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/quilt-mail b/scripts/quilt-mail index 9790b65f0f..7ef3f2fdbc 100755 --- a/scripts/quilt-mail +++ b/scripts/quilt-mail @@ -181,7 +181,8 @@ CC_NAMES=("linux-kernel(a)vger\.kernel\.org" "conor(a)kernel\.org" "hargar(a)microsoft\.com" "broonie(a)kernel\.org" - "achill(a)achill\.org") + "achill(a)achill\.org" + "sr(a)sladewatkins\.com") #CC_LIST="stable(a)vger\.kernel\.org" CC_LIST="patches(a)lists.linux.dev" -- 2.50.1 (Apple Git-155)

3 weeks

2
1
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102039-detoxify-trustee-aa22@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

3 weeks

3
4
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" 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 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102038-outsource-awhile-6150@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

3 weeks

3
4
0 0

[PATCH wireless-next v3 1/4] wifi: cfg80211: add an hrtimer based delayed work item

by Miri Korenblit

From: Benjamin Berg <benjamin.berg(a)intel.com> The normal timer mechanism assume that timeout further in the future need a lower accuracy. As an example, the granularity for a timer scheduled 4096 ms in the future on a 1000 Hz system is already 512 ms. This granularity is perfectly sufficient for e.g. timeouts, but there are other types of events that will happen at a future point in time and require a higher accuracy. Add a new wiphy_hrtimer_work type that uses an hrtimer internally. The API is almost identical to the existing wiphy_delayed_work and it can be used as a drop-in replacement after minor adjustments. The work will be scheduled relative to the current time with a slack of 1 millisecond. CC: stable(a)vger.kernel.org # 6.4+ Signed-off-by: Benjamin Berg <benjamin.berg(a)intel.com> Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> --- include/net/cfg80211.h | 78 ++++++++++++++++++++++++++++++++++++++++++ net/wireless/core.c | 56 ++++++++++++++++++++++++++++++ net/wireless/trace.h | 21 ++++++++++++ 3 files changed, 155 insertions(+) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 53490eb04e87..f2e8963cfaac 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -6440,6 +6440,11 @@ static inline void wiphy_delayed_work_init(struct wiphy_delayed_work *dwork, * after wiphy_lock() was called. Therefore, wiphy_cancel_work() can * use just cancel_work() instead of cancel_work_sync(), it requires * being in a section protected by wiphy_lock(). + * + * Note that these are scheduled with a timer where the accuracy + * becomes less the longer in the future the scheduled timer is. Use + * wiphy_hrtimer_work_queue() if the timer must be not be late by more + * than approximately 10 percent. */ void wiphy_delayed_work_queue(struct wiphy *wiphy, struct wiphy_delayed_work *dwork, @@ -6511,6 +6516,79 @@ void wiphy_delayed_work_flush(struct wiphy *wiphy, bool wiphy_delayed_work_pending(struct wiphy *wiphy, struct wiphy_delayed_work *dwork); +struct wiphy_hrtimer_work { + struct wiphy_work work; + struct wiphy *wiphy; + struct hrtimer timer; +}; + +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t); + +static inline void wiphy_hrtimer_work_init(struct wiphy_hrtimer_work *hrwork, + wiphy_work_func_t func) +{ + hrtimer_setup(&hrwork->timer, wiphy_hrtimer_work_timer, + CLOCK_BOOTTIME, HRTIMER_MODE_REL); + wiphy_work_init(&hrwork->work, func); +} + +/** + * wiphy_hrtimer_work_queue - queue hrtimer work for the wiphy + * @wiphy: the wiphy to queue for + * @hrwork: the high resolution timer worker + * @delay: the delay given as a ktime_t + * + * Please refer to wiphy_delayed_work_queue(). The difference is that + * the hrtimer work uses a high resolution timer for scheduling. This + * may be needed if timeouts might be scheduled further in the future + * and the accuracy of the normal timer is not sufficient. + * + * Expect a delay of a few milliseconds as the timer is scheduled + * with some slack and some more time may pass between queueing the + * work and its start. + */ +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay); + +/** + * wiphy_hrtimer_work_cancel - cancel previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrtimer: the hrtimer work to cancel + * + * Cancel the work *without* waiting for it, this assumes being + * called under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrtimer); + +/** + * wiphy_hrtimer_work_flush - flush previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work to flush + * + * Flush the work (i.e. run it if pending). This must be called + * under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + +/** + * wiphy_hrtimer_work_pending - Find out whether a wiphy hrtimer + * work item is currently pending. + * + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work in question + * + * Return: true if timer is pending, false otherwise + * + * Please refer to the wiphy_delayed_work_pending() documentation as + * this is the equivalent function for hrtimer based delayed work + * items. + */ +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + /** * enum ieee80211_ap_reg_power - regulatory power for an Access Point * diff --git a/net/wireless/core.c b/net/wireless/core.c index f3568eb5e592..9f858a83e912 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1802,6 +1802,62 @@ bool wiphy_delayed_work_pending(struct wiphy *wiphy, } EXPORT_SYMBOL_GPL(wiphy_delayed_work_pending); +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t) +{ + struct wiphy_hrtimer_work *hrwork = + container_of(t, struct wiphy_hrtimer_work, timer); + + wiphy_work_queue(hrwork->wiphy, &hrwork->work); + + return HRTIMER_NORESTART; +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_timer); + +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay) +{ + trace_wiphy_hrtimer_work_queue(wiphy, &hrwork->work, delay); + + if (!delay) { + hrtimer_cancel(&hrwork->timer); + wiphy_work_queue(wiphy, &hrwork->work); + return; + } + + hrwork->wiphy = wiphy; + hrtimer_start_range_ns(&hrwork->timer, delay, + 1000 * NSEC_PER_USEC, HRTIMER_MODE_REL); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_queue); + +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_cancel(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_cancel); + +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_flush(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_flush); + +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + return hrtimer_is_queued(&hrwork->timer); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_pending); + static int __init cfg80211_init(void) { int err; diff --git a/net/wireless/trace.h b/net/wireless/trace.h index 8a4c34112eb5..2b71f1d867a0 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -304,6 +304,27 @@ TRACE_EVENT(wiphy_delayed_work_queue, __entry->delay) ); +TRACE_EVENT(wiphy_hrtimer_work_queue, + TP_PROTO(struct wiphy *wiphy, struct wiphy_work *work, + ktime_t delay), + TP_ARGS(wiphy, work, delay), + TP_STRUCT__entry( + WIPHY_ENTRY + __field(void *, instance) + __field(void *, func) + __field(ktime_t, delay) + ), + TP_fast_assign( + WIPHY_ASSIGN; + __entry->instance = work; + __entry->func = work->func; + __entry->delay = delay; + ), + TP_printk(WIPHY_PR_FMT " instance=%p func=%pS delay=%llu", + WIPHY_PR_ARG, __entry->instance, __entry->func, + __entry->delay) +); + TRACE_EVENT(wiphy_work_worker_start, TP_PROTO(struct wiphy *wiphy), TP_ARGS(wiphy), -- 2.34.1

3 weeks

1
0
0 0

[PATCH] s390/mm: Fix memory leak in add_marker() when kvrealloc fails

by Miaoqian Lin

When kvrealloc() fails, the original markers memory is leaked because the function directly assigns the NULL to the markers pointer, losing the reference to the original memory. As a result, the kvfree() in pt_dump_init() ends up freeing NULL instead of the previously allocated memory. Fix this by using a temporary variable to store kvrealloc()'s return value and only update the markers pointer on success. Found via static anlaysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/s390/mm/dump_pagetables.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c index 9af2aae0a515..0f2e0c93a1e0 100644 --- a/arch/s390/mm/dump_pagetables.c +++ b/arch/s390/mm/dump_pagetables.c @@ -291,16 +291,19 @@ static int ptdump_cmp(const void *a, const void *b) static int add_marker(unsigned long start, unsigned long end, const char *name) { + struct addr_marker *new_markers; size_t oldsize, newsize; oldsize = markers_cnt * sizeof(*markers); newsize = oldsize + 2 * sizeof(*markers); if (!oldsize) - markers = kvmalloc(newsize, GFP_KERNEL); + new_markers = kvmalloc(newsize, GFP_KERNEL); else - markers = kvrealloc(markers, newsize, GFP_KERNEL); - if (!markers) + new_markers = kvrealloc(markers, newsize, GFP_KERNEL); + if (!new_markers) goto error; + + markers = new_markers; markers[markers_cnt].is_start = 1; markers[markers_cnt].start_address = start; markers[markers_cnt].size = end - start; -- 2.39.5 (Apple Git-154)

3 weeks

3
3
0 0

[PATCH] dma-fence: Fix safe access wrapper to call timeline name method

by Akash Goel

This commit fixes the wrapper function dma_fence_timeline_name(), that was added for safe access, to actually call the timeline name method of dma_fence_ops. Cc: <stable(a)vger.kernel.org> # v6.17+ Signed-off-by: Akash Goel <akash.goel(a)arm.com> --- drivers/dma-buf/dma-fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 3f78c56b58dc..39e6f93dc310 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1141,7 +1141,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) "RCU protection is required for safe access to returned string"); if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) - return fence->ops->get_driver_name(fence); + return fence->ops->get_timeline_name(fence); else return "signaled-timeline"; } -- 2.25.1

3 weeks

3
2
0 0

FAILED: patch "[PATCH] vsock: fix lock inversion in vsock_assign_transport()" 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 f7c877e7535260cc7a21484c994e8ce7e8cb6780 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102616-navy-creatable-7fad@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f7c877e7535260cc7a21484c994e8ce7e8cb6780 Mon Sep 17 00:00:00 2001 From: Stefano Garzarella <sgarzare(a)redhat.com> Date: Tue, 21 Oct 2025 14:17:18 +0200 Subject: [PATCH] vsock: fix lock inversion in vsock_assign_transport() 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> Link: https://patch.msgid.link/20251021121718.137668-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> 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)) {

3 weeks

2
1
0 0

[REGRESSION] 6.16 fae58d0155 prevents boot of google-tomato (mt8195)

by ninelore

Hi, starting with the bisected commit fae58d0155a979a8c414bbc12db09dd4b2f910d0 ("[v2] drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv") on 6.16.y my chromebook codenamed google-tomato with the SoC MT8195 seems to hang while initializing drm. Kernel messages over serial show CPU stalls some minutes later. I am attaching the full kernel logs below. This issue is present in 6.16.7, however not in v6.17-rc6 This is my first time reporting a bug here. Please let me know if you need additional information. Thanks and kind regards Ingo Reitz -------- Booting Linux on physical CPU 0x0000000000 [0x412fd050] Linux version 6.16.4 (nixbld@localhost) (aarch64-unknown-linux-gnu-gcc (GCC) 14.3.0, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP Tue Jan 1 00:00:00 UTC 1980 Machine model: Acer Tomato (rev3 - 4) board Reserved memory: created DMA memory pool at 0x0000000050000000, size 41 MiB OF: reserved mem: initialized node memory@50000000, compatible id shared-dma-pool OF: reserved mem: 0x0000000050000000..0x00000000528fffff (41984 KiB) nomap non-reusable memory@50000000 Reserved memory: created DMA memory pool at 0x0000000060000000, size 13 MiB OF: reserved mem: initialized node memory@60000000, compatible id shared-dma-pool OF: reserved mem: 0x0000000060000000..0x0000000060d7ffff (13824 KiB) nomap non-reusable memory@60000000 Reserved memory: created DMA memory pool at 0x0000000060d80000, size 1 MiB OF: reserved mem: initialized node memory@60d80000, compatible id shared-dma-pool OF: reserved mem: 0x0000000060d80000..0x0000000060e7ffff (1024 KiB) nomap non-reusable memory@60d80000 Reserved memory: created DMA memory pool at 0x0000000060e80000, size 2 MiB OF: reserved mem: initialized node memory@60e80000, compatible id shared-dma-pool OF: reserved mem: 0x0000000060e80000..0x00000000610fffff (2560 KiB) nomap non-reusable memory@60e80000 Zone ranges: Normal [mem 0x0000000040000000-0x000000023fffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000040000000-0x000000004fffffff] node 0: [mem 0x0000000050000000-0x00000000528fffff] node 0: [mem 0x0000000052900000-0x00000000545fffff] node 0: [mem 0x0000000054660000-0x000000005fffffff] node 0: [mem 0x0000000060000000-0x00000000610fffff] node 0: [mem 0x0000000061100000-0x00000000fffdafff] node 0: [mem 0x0000000100000000-0x000000023fffffff] Initmem setup node 0 [mem 0x0000000040000000-0x000000023fffffff] On node 0, zone Normal: 96 pages in unavailable ranges On node 0, zone Normal: 37 pages in unavailable ranges psci: probing for conduit method from DT. psci: PSCIv1.1 detected in firmware. psci: Using standard PSCI v0.2 function IDs psci: MIGRATE_INFO_TYPE not supported. psci: SMC Calling Convention v1.5 percpu: Embedded 17 pages/cpu s40608 r0 d29024 u69632 pcpu-alloc: s40608 r0 d29024 u69632 alloc=17*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 Detected VIPT I-cache on CPU0 CPU features: detected: GIC system register CPU interface CPU features: detected: Virtualization Host Extensions CPU features: kernel page table isolation disabled by kernel configuration alternatives: applying boot alternatives Kernel command line: console=tty0 console=ttyS0,115200n8 loglevel=15 printk: log buffer data + meta data: 131072 + 458752 = 589824 bytes Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) software IO TLB: SWIOTLB bounce buffer size adjusted to 8MB software IO TLB: area num 8. software IO TLB: mapped [mem 0x0000000236a00000-0x0000000237200000] (8MB) Built 1 zonelists, mobility grouping on. Total pages: 2097019 mem auto-init: stack:all(zero), heap alloc:off, heap free:off SLUB: HWalign=64, Order=0-1, MinObjects=0, CPUs=8, Nodes=1 rcu: Hierarchical RCU implementation. rcu: RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=8. rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 GICv3: GIC: Using split EOI/Deactivate mode GICv3: 864 SPIs implemented GICv3: 0 Extended SPIs implemented Root IRQ handler: 0xffff80008001007c GICv3: GICv3 features: 16 PPIs GICv3: GICD_CTRL.DS=0, SCR_EL3.FIQ=0 GICv3: CPU0: found redistributor 0 region 0:0x000000000c040000 GICv3: GIC: PPI partition interrupt-partition-0[0] { /cpus/cpu@0[0] /cpus/cpu@100[1] /cpus/cpu@200[2] /cpus/cpu@300[3] } GICv3: GIC: PPI partition interrupt-partition-1[1] { /cpus/cpu@400[4] /cpus/cpu@500[5] /cpus/cpu@600[6] /cpus/cpu@700[7] } rcu: srcu_init: Setting srcu_struct sizes based on contention. arch_timer: cp15 timer(s) running at 13.00MHz (phys). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x2ff89eacb, max_idle_ns: 440795202429 ns sched_clock: 56 bits at 13MHz, resolution 76ns, wraps every 4398046511101ns Console: colour dummy device 80x25 printk: legacy console [tty0] enabled Calibrating delay loop (skipped), value calculated using timer frequency.. 26.00 BogoMIPS (lpj=52000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) rcu: Hierarchical SRCU implementation. rcu: Max phase no-delay instances is 1000. smp: Bringing up secondary CPUs ... Detected VIPT I-cache on CPU1 GICv3: CPU1: found redistributor 100 region 0:0x000000000c060000 CPU1: Booted secondary processor 0x0000000100 [0x412fd050] Detected VIPT I-cache on CPU2 GICv3: CPU2: found redistributor 200 region 0:0x000000000c080000 CPU2: Booted secondary processor 0x0000000200 [0x412fd050] Detected VIPT I-cache on CPU3 GICv3: CPU3: found redistributor 300 region 0:0x000000000c0a0000 CPU3: Booted secondary processor 0x0000000300 [0x412fd050] CPU features: detected: Spectre-v4 CPU features: detected: Spectre-BHB Detected PIPT I-cache on CPU4 GICv3: CPU4: found redistributor 400 region 0:0x000000000c0c0000 CPU4: Booted secondary processor 0x0000000400 [0x411fd410] Detected PIPT I-cache on CPU5 GICv3: CPU5: found redistributor 500 region 0:0x000000000c0e0000 CPU5: Booted secondary processor 0x0000000500 [0x411fd410] Detected PIPT I-cache on CPU6 GICv3: CPU6: found redistributor 600 region 0:0x000000000c100000 CPU6: Booted secondary processor 0x0000000600 [0x411fd410] Detected PIPT I-cache on CPU7 GICv3: CPU7: found redistributor 700 region 0:0x000000000c120000 CPU7: Booted secondary processor 0x0000000700 [0x411fd410] smp: Brought up 1 node, 8 CPUs SMP: Total of 8 processors activated. CPU: All CPU(s) started at EL2 CPU features: detected: 32-bit EL0 Support CPU features: detected: Data cache clean to the PoU not required for I/D coherence CPU features: detected: Common not Private translations CPU features: detected: CRC32 instructions CPU features: detected: Data cache clean to Point of Persistence CPU features: detected: RCpc load-acquire (LDAPR) CPU features: detected: LSE atomic instructions CPU features: detected: PMUv3 CPU features: detected: RAS Extension Support CPU features: detected: Speculative Store Bypassing Safe (SSBS) spectre-bhb mitigation disabled by compile time option spectre-bhb mitigation disabled by compile time option alternatives: applying system-wide alternatives CPU features: detected: Hardware dirty bit management on CPU0-7 Memory: 8159184K/8388076K available (4928K kernel code, 924K rwdata, 1800K rodata, 896K init, 479K bss, 224752K reserved, 0K cma-reserved) devtmpfs: initialized clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns futex hash table entries: 2048 (131072 bytes on 1 NUMA nodes, total 128 KiB, linear). pinctrl core: initialized pinctrl subsystem DMA: preallocated 1024 KiB GFP_KERNEL pool for atomic allocations thermal_sys: Registered thermal governor 'step_wise' thermal_sys: Registered thermal governor 'power_allocator' hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. ASID allocator initialised with 65536 entries Serial: AMBA PL011 UART driver /soc/interrupt-controller@c000000: Fixed dependency cycle(s) with /soc/interrupt-controller@c000000 /soc/syscon@1c01a000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/syscon@1c100000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/dp-tx@1c600000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000/aux-bus/panel /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/edp-tx@1c500000/aux-bus/panel: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-tx@1c600000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/pinctrl@10005000: Fixed dependency cycle(s) with /soc/pinctrl@10005000/pio-default-pins /soc/pcie@112f8000: Fixed dependency cycle(s) with /soc/pcie@112f8000/interrupt-controller /soc/syscon@1c01a000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/syscon@1c01a000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/syscon@1c100000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/dp-tx@1c600000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/syscon@1c100000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000/aux-bus/panel /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/edp-tx@1c500000/aux-bus/panel: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/dp-tx@1c600000 /soc/dp-tx@1c600000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 HugeTLB: allocation took 0ms with hugepage_allocation_threads=2 HugeTLB: allocation took 0ms with hugepage_allocation_threads=2 HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page iommu: Default domain type: Translated iommu: DMA domain TLB invalidation policy: strict mode SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb vgaarb: loaded clocksource: Switched to clocksource arch_sys_counter PCI: CLS 0 bytes, default 64 Unpacking initramfs... workingset: timestamp_bits=62 max_order=21 bucket_order=0 squashfs: version 4.0 (2009/01/31) Phillip Lougher Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) io scheduler mq-deadline registered io scheduler kyber registered io scheduler bfq registered Freeing initrd memory: 2996K cannot find "mediatek,mt8195-fhctl" mtk-socinfo mtk-socinfo.0.auto: MediaTek Kompanio 1380 (MT8195) SoC detected. Serial: 8250/16550 driver, 32 ports, IRQ sharing disabled printk: legacy console [ttyS0] disabled 11001100.serial: ttyS0 at MMIO 0x11001100 (irq = 253, base_baud = 1625000) is a ST16650V2 printk: legacy console [ttyS0] enabled Serial: AMBA driver loop: module loaded mt6359-keys: Failed to locate of_node [id: -1] mt6359-accdet: Failed to locate of_node [id: -1] mtk-spi-nor 1132c000.spi: spi frequency: 52000000 Hz usbcore: registered new interface driver usb-storage mt6397-rtc mt6359-rtc: registered as rtc0 mt6397-rtc mt6359-rtc: setting system clock to 2025-09-15T22:15:30 UTC (1757974530) mtk-lvts-thermal 1100b000.thermal-sensor: golden temp=60 vgpu11_sshub: Bringing 400000uV into 550000-550000uV thermal thermal_zone0: power_allocator: sustainable_power will be estimated thermal thermal_zone1: power_allocator: sustainable_power will be estimated thermal thermal_zone2: power_allocator: sustainable_power will be estimated thermal thermal_zone3: power_allocator: sustainable_power will be estimated thermal thermal_zone4: power_allocator: sustainable_power will be estimated thermal thermal_zone5: power_allocator: sustainable_power will be estimated thermal thermal_zone6: power_allocator: sustainable_power will be estimated thermal thermal_zone7: power_allocator: sustainable_power will be estimated thermal thermal_zone8: power_allocator: sustainable_power will be estimated mtk-lvts-thermal 11278000.thermal-sensor: golden temp=60 thermal thermal_zone9: power_allocator: sustainable_power will be estimated thermal thermal_zone10: power_allocator: sustainable_power will be estimated thermal thermal_zone11: power_allocator: sustainable_power will be estimated thermal thermal_zone12: power_allocator: sustainable_power will be estimated thermal thermal_zone13: power_allocator: sustainable_power will be estimated thermal thermal_zone14: power_allocator: sustainable_power will be estimated thermal thermal_zone15: power_allocator: sustainable_power will be estimated thermal thermal_zone16: power_allocator: sustainable_power will be estimated cpu cpu0: EM: created perf domain cpu cpu4: EM: created perf domain coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 hid: raw HID events driver (C) Jiri Kosina usbcore: registered new interface driver usbhid usbhid: USB HID core driver spi_master spi0: will run message pump with realtime priority hw perfevents: enabled with armv8_cortex_a55 PMU driver, 7 (0,8000003f) counters available hw perfevents: enabled with armv8_cortex_a78 PMU driver, 7 (0,8000003f) counters available mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/ovl@1c000000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/rdma@1c002000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/color@1c003000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/ccorr@1c004000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/aal@1c005000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/gamma@1c006000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/merge@1c014000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/dp-intf@1c015000 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Failed to get id. type: 2, alias: -19 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Skipping unknown component /soc/merge@1c014000 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Failed to get id. type: 2, alias: 5 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Skipping unknown component /soc/vpp-merge@1c110000 mediatek-drm mediatek-drm.14.auto: Adding component match for /soc/vpp-merge@1c110000 mediatek-drm mediatek-drm.14.auto: Adding component match for /soc/dp-intf@1c113000 mtk-msdc 11230000.mmc: Final PAD_DS_TUNE: 0x15011 mtk-power-controller 10006000.syscon:power-controller: /soc/syscon@10006000/power-controller/power-domain@15/power-domain@16/power-domain@18/power-domain@20: A default off power domain has been ON input: cros_ec as /devices/platform/soc/1100a000.spi/spi_master/spi0/spi0.0/1100a000.spi:ec@0:keyboard-controller/input/input0 mmc0: Host Software Queue enabled mmc0: new HS400 MMC card at address 0001 mmcblk0: mmc0:0001 DA4128 116 GiB mmcblk0: p1 p2 p3 mmcblk0boot0: mmc0:0001 DA4128 4.00 MiB mmcblk0boot1: mmc0:0001 DA4128 4.00 MiB mmcblk0rpmb: mmc0:0001 DA4128 16.0 MiB, chardev (249:0) input: cros_ec_buttons as /devices/platform/soc/1100a000.spi/spi_master/spi0/spi0.0/1100a000.spi:ec@0:keyboard-controller/input/input1 /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000/aux-bus/panel /soc/edp-tx@1c500000/aux-bus/panel: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 cros-ec-spi spi0.0: Chrome EC device registered mtu3 11201000.usb: uwk - reg:0x400, version:103 mtu3 11201000.usb: dr_mode: 1, drd: auto mtu3 11201000.usb: u2p_dis_msk: 0, u3p_dis_msk: 0 mtu3 11201000.usb: usb3-drd: 1 xhci-mtk 11200000.usb: supply vusb33 not found, using dummy regulator xhci-mtk 11200000.usb: xHCI Host Controller xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 1 xhci-mtk 11200000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000000200010 xhci-mtk 11200000.usb: irq 287, io mem 0x11200000 xhci-mtk 11200000.usb: xHCI Host Controller xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 2 xhci-mtk 11200000.usb: Host supports USB 3.2 Enhanced SuperSpeed usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: xHCI Host Controller usb usb1: Manufacturer: Linux 6.16.4 xhci-hcd usb usb1: SerialNumber: 11200000.usb hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.16 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: xHCI Host Controller usb usb2: Manufacturer: Linux 6.16.4 xhci-hcd usb usb2: SerialNumber: 11200000.usb hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected mtu3 11201000.usb: xHCI platform device register success... mtu3 112a1000.usb: uwk - reg:0x400, version:105 mtu3 112a1000.usb: dr_mode: 1, drd: auto mtu3 112a1000.usb: u2p_dis_msk: 0, u3p_dis_msk: 0 mtu3 112a1000.usb: usb3-drd: 0 xhci-mtk 112a0000.usb: supply vusb33 not found, using dummy regulator xhci-mtk 112a0000.usb: xHCI Host Controller xhci-mtk 112a0000.usb: new USB bus registered, assigned bus number 3 xhci-mtk 112a0000.usb: USB3 root hub has no ports xhci-mtk 112a0000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000000200010 xhci-mtk 112a0000.usb: irq 288, io mem 0x112a0000 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: xHCI Host Controller usb usb3: Manufacturer: Linux 6.16.4 xhci-hcd usb usb3: SerialNumber: 112a0000.usb hub 3-0:1.0: USB hub found hub 3-0:1.0: 1 port detected mtu3 112a1000.usb: xHCI platform device register success... mtu3 112b1000.usb: uwk - reg:0x400, version:106 mtu3 112b1000.usb: dr_mode: 1, drd: auto mtu3 112b1000.usb: u2p_dis_msk: 0, u3p_dis_msk: 0 mtu3 112b1000.usb: usb3-drd: 0 xhci-mtk 112b0000.usb: supply vusb33 not found, using dummy regulator xhci-mtk 112b0000.usb: xHCI Host Controller xhci-mtk 112b0000.usb: new USB bus registered, assigned bus number 4 xhci-mtk 112b0000.usb: USB3 root hub has no ports xhci-mtk 112b0000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000020200010 xhci-mtk 112b0000.usb: irq 289, io mem 0x112b0000 usb usb4: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: xHCI Host Controller usb usb4: Manufacturer: Linux 6.16.4 xhci-hcd usb usb4: SerialNumber: 112b0000.usb hub 4-0:1.0: USB hub found hub 4-0:1.0: 1 port detected mtu3 112b1000.usb: xHCI platform device register success... thermal thermal_zone17: power_allocator: sustainable_power will be estimated thermal thermal_zone18: power_allocator: sustainable_power will be estimated mtk-msdc 11240000.mmc: Got CD GPIO usb 1-1: new high-speed USB device number 2 using xhci-mtk usb 3-1: new high-speed USB device number 2 using xhci-mtk usb 1-1: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=65.02 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: Product: USB2.1 Hub usb 1-1: Manufacturer: GenesysLogic hub 1-1:1.0: USB hub found hub 1-1:1.0: 3 ports detected usb 4-1: new high-speed USB device number 2 using xhci-mtk usb 2-1: new SuperSpeed USB device number 2 using xhci-mtk usb 2-1: New USB device found, idVendor=05e3, idProduct=0620, bcdDevice=65.02 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: USB3.2 Hub usb 2-1: Manufacturer: GenesysLogic hub 2-1:1.0: USB hub found hub 2-1:1.0: 3 ports detected usb 3-1: New USB device found, idVendor=0408, idProduct=4034, bcdDevice= 0.02 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: ACER HD User Facing usb 3-1: Manufacturer: Quanta usb 3-1: SerialNumber: 01.00.00 usb 4-1: New USB device found, idVendor=04ca, idProduct=3802, bcdDevice= 1.00 usb 4-1: New USB device strings: Mfr=5, Product=6, SerialNumber=7 usb 4-1: Product: Wireless_Device usb 4-1: Manufacturer: MediaTek Inc. usb 4-1: SerialNumber: 000000000 panel-simple-dp-aux aux-1c500000.edp-tx: Detected BOE NE135FBM-N41 v8.1 (0x095f) xhci-mtk 11290000.usb: uwk - reg:0x400, version:104 xhci-mtk 11290000.usb: xHCI Host Controller xhci-mtk 11290000.usb: new USB bus registered, assigned bus number 5 xhci-mtk 11290000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000000200010 xhci-mtk 11290000.usb: irq 291, io mem 0x11290000 xhci-mtk 11290000.usb: xHCI Host Controller xhci-mtk 11290000.usb: new USB bus registered, assigned bus number 6 xhci-mtk 11290000.usb: Host supports USB 3.2 Enhanced SuperSpeed usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: xHCI Host Controller usb usb5: Manufacturer: Linux 6.16.4 xhci-hcd usb usb5: SerialNumber: 11290000.usb hub 5-0:1.0: USB hub found hub 5-0:1.0: 1 port detected usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.16 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: xHCI Host Controller usb usb6: Manufacturer: Linux 6.16.4 xhci-hcd usb usb6: SerialNumber: 11290000.usb hub 6-0:1.0: USB hub found hub 6-0:1.0: 1 port detected i2c_hid_of 4-0010: supply vddl not found, using dummy regulator platform 14001000.dma-controller: Adding to iommu group 0 platform 14009000.display: Adding to iommu group 0 platform 1400c000.dma-controller: Adding to iommu group 0 platform 14f0a000.dma-controller: Adding to iommu group 0 platform 14f25000.dma-controller: Adding to iommu group 0 platform soc:jpgenc-master: Adding to iommu group 1 i2c_hid_of 4-0010: i2c_hid_get_input: IRQ triggered but there's no data platform 1c105000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 Touchscreen as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input2 platform 1c107000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input3 platform 1c109000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input4 platform 1c10b000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 Stylus as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input5 platform 1c114000.hdr-engine: Adding to iommu group 2 hid-generic 0018:04F3:4040.0001: input,hidraw0: I2C HID v1.00 Device [hid-over-i2c 04F3:4040] on 4-0010 mtk-iommu 14018000.iommu: bound 1c019000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1c103000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 14013000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 14f03000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 14e05000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 15340000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16002000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16012000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 17201000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1b010000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1803e000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1800e000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16142000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16014000.larb (ops 0xffff800080611fb8) platform 14f08000.dma-controller: Adding to iommu group 0 platform 14f09000.dma-controller: Adding to iommu group 0 platform 14f1f000.display: Adding to iommu group 0 platform 14f23000.dma-controller: Adding to iommu group 0 platform 14f24000.dma-controller: Adding to iommu group 0 platform 18000000.video-codec: Adding to iommu group 1 platform 1a020000.video-codec: Adding to iommu group 1 platform soc:jpgdec-master: Adding to iommu group 1 platform 1c000000.ovl: Adding to iommu group 2 platform 1c002000.rdma: Adding to iommu group 2 platform 1c104000.dma-controller: Adding to iommu group 2 platform 1c106000.dma-controller: Adding to iommu group 2 platform 1c108000.dma-controller: Adding to iommu group 2 platform 1c10a000.dma-controller: Adding to iommu group 2 mtk-iommu 1c01f000.iommu: bound 1c018000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1c102000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 14f02000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 14e04000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 15001000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 15120000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 15230000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16001000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16013000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1a010000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1802e000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1800d000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16141000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16015000.larb (ops 0xffff800080611fb8) rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=1751 rcu: (detected by 0, t=5252 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=6170 rcu: (detected by 0, t=21007 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=10589 rcu: (detected by 0, t=36762 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=15008 rcu: (detected by 0, t=52517 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=19427 rcu: (detected by 0, t=68272 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=23846 rcu: (detected by 0, t=84027 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=28265 rcu: (detected by 0, t=99782 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=32684 rcu: (detected by 0, t=115537 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=37103 rcu: (detected by 0, t=131292 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=41522 rcu: (detected by 0, t=147047 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=45941 rcu: (detected by 0, t=162802 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=50360 rcu: (detected by 0, t=178557 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=54779 rcu: (detected by 0, t=194312 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: random: crng init done rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=59198 rcu: (detected by 0, t=210067 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=63617 rcu: (detected by 0, t=225822 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=68036 rcu: (detected by 0, t=241577 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=72455 rcu: (detected by 0, t=257332 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=76874 rcu: (detected by 0, t=273087 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=81293 rcu: (detected by 0, t=288842 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=85712 rcu: (detected by 0, t=304597 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=90131 rcu: (detected by 0, t=320352 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=94550 rcu: (detected by 0, t=336107 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=98969 rcu: (detected by 0, t=351862 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=103388 rcu: (detected by 0, t=367617 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=107807 rcu: (detected by 0, t=383372 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=112226 rcu: (detected by 0, t=399127 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=116645 rcu: (detected by 0, t=414882 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=121064 rcu: (detected by 0, t=430637 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=125483 rcu: (detected by 0, t=446392 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=129902 rcu: (detected by 0, t=462147 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=134321 rcu: (detected by 0, t=477902 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=138740 rcu: (detected by 0, t=493657 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=143159 rcu: (detected by 0, t=509412 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5:

3 weeks

3
2
0 0

[PATCH] drm/tegra: Fix reference count leak in tegra_dc_couple

by Miaoqian Lin

The driver_find_device() function returns a device with its reference count incremented. The caller is responsible for calling put_device() to release this reference when done. Fix this leak by adding the missing put_device() call. Found via static analysis. Fixes: f68ba6912bd2 ("drm/tegra: dc: Link DC1 to DC0 on Tegra20") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/tegra/dc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 59d5c1ba145a..6c84bd69b11f 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -3148,6 +3148,7 @@ static int tegra_dc_couple(struct tegra_dc *dc) dc->client.parent = &parent->client; dev_dbg(dc->dev, "coupled to %s\n", dev_name(companion)); + put_device(companion); } return 0; -- 2.39.5 (Apple Git-154)

3 weeks

1
0
0 0

[PATCH 5.10] scsi: target: target_core_configfs: Add length check to avoid buffer overflow

by Andrey Troshin

From: Wang Haoran <haoranwangsec(a)gmail.com> commit 27e06650a5eafe832a90fd2604f0c5e920857fae upstream. A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow. Reported-by: Wang Haoran <haoranwangsec(a)gmail.com> Reported-by: ziiiro <yuanmingbuaa(a)gmail.com> Signed-off-by: Wang Haoran <haoranwangsec(a)gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> [Andrey Troshin: patch adaptation for linux-5.10] Signed-off-by: Andrey Troshin <drtrosh(a)yandex-team.ru> --- Backport fix for CVE-2025-39998 Link: https://nvd.nist.gov/vuln/detail/CVE-2025-39998 --- drivers/target/target_core_configfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c index 4d2fbe1429b6..e6996428c07d 100644 --- a/drivers/target/target_core_configfs.c +++ b/drivers/target/target_core_configfs.c @@ -2637,7 +2637,7 @@ static ssize_t target_lu_gp_members_show(struct config_item *item, char *page) config_item_name(&dev->dev_group.cg_item)); cur_len++; /* Extra byte for NULL terminator */ - if ((cur_len + len) > PAGE_SIZE) { + if ((cur_len + len) > PAGE_SIZE || cur_len > LU_GROUP_NAME_BUF) { pr_warn("Ran out of lu_gp_show_attr" "_members buffer\n"); break; -- 2.34.1

3 weeks

1
0
0 0

Fixing Mistakes: How to Change Your Name on a Play Airlines Reservation

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Play Airlines customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Play Airlines and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Play Airlines offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Play Airlines. 📋 Play Airlines Name Correction Policy: The Basics Play Airlines does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Play Airlines ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Play Airlines Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Play Airlines at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Play Airlines, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

How to Make a Name Change on Aer Lingus: A Quick and Easy Guide

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Aer Lingus customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Aer Lingus and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Aer Lingus offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Aer Lingus. 📋 Aer Lingus Name Correction Policy: The Basics Aer Lingus does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Aer Lingus ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Aer Lingus Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Aer Lingus at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Aer Lingus, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

FAILED: patch "[PATCH] serial: sc16is7xx: remove useless enable of enhanced features" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x 1c05bf6c0262f946571a37678250193e46b1ff0f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102740-dumpster-clapper-519c@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c05bf6c0262f946571a37678250193e46b1ff0f Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Mon, 6 Oct 2025 10:20:02 -0400 Subject: [PATCH] serial: sc16is7xx: remove useless enable of enhanced features Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that. Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured. Fixes: 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") Cc: stable <stable(a)kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://patch.msgid.link/20251006142002.177475-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 1a2c4c14f6aa..c7435595dce1 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud) div /= prescaler; } - /* Enable enhanced features */ - sc16is7xx_efr_lock(port); - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - sc16is7xx_efr_unlock(port); - /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT,

3 weeks

1
0
0 0

FAILED: patch "[PATCH] serial: sc16is7xx: remove useless enable of enhanced features" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 1c05bf6c0262f946571a37678250193e46b1ff0f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102740-stiffly-recolor-e335@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c05bf6c0262f946571a37678250193e46b1ff0f Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Mon, 6 Oct 2025 10:20:02 -0400 Subject: [PATCH] serial: sc16is7xx: remove useless enable of enhanced features Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that. Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured. Fixes: 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") Cc: stable <stable(a)kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://patch.msgid.link/20251006142002.177475-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 1a2c4c14f6aa..c7435595dce1 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud) div /= prescaler; } - /* Enable enhanced features */ - sc16is7xx_efr_lock(port); - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - sc16is7xx_efr_unlock(port); - /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT,

3 weeks

1
0
0 0

FAILED: patch "[PATCH] serial: sc16is7xx: remove useless enable of enhanced features" 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 1c05bf6c0262f946571a37678250193e46b1ff0f # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102740-umpire-tactile-9042@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1c05bf6c0262f946571a37678250193e46b1ff0f Mon Sep 17 00:00:00 2001 From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Date: Mon, 6 Oct 2025 10:20:02 -0400 Subject: [PATCH] serial: sc16is7xx: remove useless enable of enhanced features Commit 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") permanently enabled access to the enhanced features in sc16is7xx_probe(), and it is never disabled after that. Therefore, remove re-enable of enhanced features in sc16is7xx_set_baud(). This eliminates a potential useless read + write cycle each time the baud rate is reconfigured. Fixes: 43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed") Cc: stable <stable(a)kernel.org> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> Link: https://patch.msgid.link/20251006142002.177475-1-hugo@hugovil.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c index 1a2c4c14f6aa..c7435595dce1 100644 --- a/drivers/tty/serial/sc16is7xx.c +++ b/drivers/tty/serial/sc16is7xx.c @@ -588,13 +588,6 @@ static int sc16is7xx_set_baud(struct uart_port *port, int baud) div /= prescaler; } - /* Enable enhanced features */ - sc16is7xx_efr_lock(port); - sc16is7xx_port_update(port, SC16IS7XX_EFR_REG, - SC16IS7XX_EFR_ENABLE_BIT, - SC16IS7XX_EFR_ENABLE_BIT); - sc16is7xx_efr_unlock(port); - /* If bit MCR_CLKSEL is set, the divide by 4 prescaler is activated. */ sc16is7xx_port_update(port, SC16IS7XX_MCR_REG, SC16IS7XX_MCR_CLKSEL_BIT,

3 weeks

1
0
0 0

How to Speak to a Live Person Malaysia Airlines: Tips and Tricks

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Malaysia Airlines? Calling Malaysia Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Malaysia Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Malaysia Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Malaysia Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Malaysia Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Malaysia Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Vietnam Airlines Name Change: How to Update Your Flight Details with Ease

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Vietnam Airlines customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Vietnam Airlines and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Vietnam Airlines offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Vietnam Airlines. 📋 Vietnam Airlines Name Correction Policy: The Basics Vietnam Airlines does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Vietnam Airlines ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Vietnam Airlines Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Vietnam Airlines at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Vietnam Airlines, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

Updating Your Flight Details with Etihad Airways: A Simple Name Change Guide

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Etihad Airways customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Etihad Airways and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Etihad Airways offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Etihad Airways. 📋 Etihad Airways Name Correction Policy: The Basics Etihad Airways does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Etihad Airways ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Etihad Airways Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Etihad Airways at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Etihad Airways, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent LATAM Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person LATAM Airlines? Calling LATAM Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real LATAM Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach LATAM Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM LATAM Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the LATAM Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to LATAM Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Frontier Airlines: Tips and Tricks

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Frontier Airlines? Calling Frontier Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Frontier Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Frontier Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Frontier Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Frontier Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Frontier Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Get in Touch with a Live Representative ExpressJet Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person ExpressJet Airlines? Calling ExpressJet Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real ExpressJet Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach ExpressJet Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM ExpressJet Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the ExpressJet Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to ExpressJet Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Easily Contact a Live Agent Copa Airlines for Help

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Copa Airlines? Calling Copa Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Copa Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Copa Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Copa Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Copa Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Copa Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Quickly Reach a Live Agent for Assistance Contour Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Contour Airlines? Calling Contour Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Contour Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Contour Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Contour Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Contour Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Contour Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Step-by-Step Guide: How to Speak with a Live Agent Condor Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Condor Airlines? Calling Condor Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Condor Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Condor Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Condor Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Condor Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Condor Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

FAILED: patch "[PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x f3d12ec847b945d5d65846c85f062d07d5e73164 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102716-flop-splendor-1e95@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f3d12ec847b945d5d65846c85f062d07d5e73164 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 14 Oct 2025 01:55:41 +0300 Subject: [PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c index 63edf2d8f245..023a8ec6f305 100644 --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -892,7 +892,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) dev_info(dbc->dev, "DbC configured\n"); portsc = readl(&dbc->regs->portsc); writel(portsc, &dbc->regs->portsc); - return EVT_GSER; + ret = EVT_GSER; + break; } return EVT_DONE; @@ -954,7 +955,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) break; case TRB_TYPE(TRB_TRANSFER): dbc_handle_xfer_event(dbc, evt); - ret = EVT_XFER_DONE; + if (ret != EVT_GSER) + ret = EVT_XFER_DONE; break; default: break;

3 weeks

1
0
0 0

FAILED: patch "[PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races" 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 f3d12ec847b945d5d65846c85f062d07d5e73164 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102715-bagginess-civic-022b@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f3d12ec847b945d5d65846c85f062d07d5e73164 Mon Sep 17 00:00:00 2001 From: Mathias Nyman <mathias.nyman(a)linux.intel.com> Date: Tue, 14 Oct 2025 01:55:41 +0300 Subject: [PATCH] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable <stable(a)kernel.org> Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-dbgcap.c b/drivers/usb/host/xhci-dbgcap.c index 63edf2d8f245..023a8ec6f305 100644 --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -892,7 +892,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) dev_info(dbc->dev, "DbC configured\n"); portsc = readl(&dbc->regs->portsc); writel(portsc, &dbc->regs->portsc); - return EVT_GSER; + ret = EVT_GSER; + break; } return EVT_DONE; @@ -954,7 +955,8 @@ static enum evtreturn xhci_dbc_do_handle_events(struct xhci_dbc *dbc) break; case TRB_TYPE(TRB_TRANSFER): dbc_handle_xfer_event(dbc, evt); - ret = EVT_XFER_DONE; + if (ret != EVT_GSER) + ret = EVT_XFER_DONE; break; default: break;

3 weeks

1
0
0 0

How to Speak to a Live Person China Eastern Airlines: Tips and Tricks

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person China Eastern Airlines? Calling China Eastern Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real China Eastern Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach China Eastern Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM China Eastern Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the China Eastern Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to China Eastern Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Get in Touch with a Live Representative Caribbean Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Caribbean Airlines? Calling Caribbean Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Caribbean Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Caribbean Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Caribbean Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Caribbean Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Caribbean Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Avelo Airlines: Tips and Tricks

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Avelo Airlines? Calling Avelo Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Avelo Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Avelo Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Avelo Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Avelo Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Avelo Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Connect with a Live Customer Service Agent Alaska Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Alaska Airlines? Calling Alaska Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Alaska Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Alaska Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Alaska Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Alaska Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Alaska Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent Aeroméxico Airlines

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Aeroméxico Airlines? Calling Aeroméxico Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Aeroméxico Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Aeroméxico Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Aeroméxico Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Aeroméxico Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Aeroméxico Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Easily Contact a Live Agent Air Transat for Help

by scottgar.cia.727.69＠gmail.com

Need to talk to a real person Air Transat? Calling Air Transat directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Air Transat representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Air Transat (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Air Transat on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Air Transat App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Air Transat, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Scandinavian Airlines Name Change: A Simple Guide to Correcting Your Flight Details

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Scandinavian Airlines customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Scandinavian Airlines and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Scandinavian Airlines offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Scandinavian Airlines. 📋 Scandinavian Airlines Name Correction Policy: The Basics Scandinavian Airlines does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Scandinavian Airlines ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Scandinavian Airlines Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Scandinavian Airlines at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Scandinavian Airlines, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

How to Speak to a Live Person Air Canada: Tips and Tricks

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Air Canada? Calling Air Canada directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Air Canada representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Air Canada (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Air Canada on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Air Canada App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Air Canada, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Get Customer Support from a Live Agent Air Algérie

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Air Algérie? Calling Air Algérie directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Air Algérie representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Air Algérie (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Air Algérie on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Air Algérie App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Air Algérie, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Finnair: Tips and Tricks

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Finnair? Calling Finnair directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Finnair representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Finnair (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Finnair on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Finnair App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Finnair, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Mistaken Name on Your Cape Air Ticket? Here’s How to Fix It

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Cape Air customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Cape Air and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Cape Air offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Cape Air. 📋 Cape Air Name Correction Policy: The Basics Cape Air does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Cape Air ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Cape Air Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Cape Air at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Cape Air, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

How to Easily Contact a Live Agent Scoot for Help

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Scoot? Calling Scoot directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Scoot representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Scoot (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Scoot on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Scoot App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Scoot, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Easily Contact a Live Agent Horizon Air for Help

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Horizon Air? Calling Horizon Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Horizon Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Horizon Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Horizon Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Horizon Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Horizon Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

The Easiest Way to Talk to a Live Agent Flydubai

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Flydubai? Calling Flydubai directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Flydubai representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Flydubai (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Flydubai on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Flydubai App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Flydubai, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent Envoy Air

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Envoy Air? Calling Envoy Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Envoy Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Envoy Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Envoy Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Envoy Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Envoy Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Easily Contact a Live Agent Envoy Air for Help

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Envoy Air? Calling Envoy Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Envoy Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Envoy Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Envoy Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Envoy Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Envoy Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Endeavor Air: Tips and Tricks

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Endeavor Air? Calling Endeavor Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Endeavor Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Endeavor Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Endeavor Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Endeavor Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Endeavor Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Get Customer Support from a Live Agent CommuteAir

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person CommuteAir? Calling CommuteAir directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real CommuteAir representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach CommuteAir (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM CommuteAir on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the CommuteAir App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to CommuteAir, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Batik Air: Tips and Tricks

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Batik Air? Calling Batik Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Batik Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Batik Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Batik Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Batik Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Batik Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Breeze Airways: Tips and Tricks

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Breeze Airways? Calling Breeze Airways directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Breeze Airways representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Breeze Airways (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Breeze Airways on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Breeze Airways App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Breeze Airways, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Your Inbox linux-stable-mirror@lists.linaro.org have 27 pending messages

by lists.linaro.org Server Administrator

3 weeks

1
0
0 0

How to Get Customer Support from a Live Agent Flair Airlines

by laurasan.ms.311.9.8.9＠gmail.com

Need to talk to a real person Flair Airlines? Calling Flair Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Flair Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Flair Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Flair Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Flair Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Flair Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Mistaken Name on Your Cape Air Ticket? Here’s How to Fix It

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Cape Air customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Cape Air and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Cape Air offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Cape Air. 📋 Cape Air Name Correction Policy: The Basics Cape Air does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Cape Air ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Cape Air Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Cape Air at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Cape Air, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

+ headers-add-check-for-c-standard-version.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: headers: add check for C standard version has been added to the -mm mm-hotfixes-unstable branch. Its filename is headers-add-check-for-c-standard-version.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Hanne-Lotta M��enp�� <hannelotta(a)gmail.com> Subject: headers: add check for C standard version Date: Sun, 26 Oct 2025 21:58:46 +0200 Compiling the kernel with GCC 15 results in errors, as with GCC 15 the default language version for C compilation has been changed from -std=gnu17 to -std=gnu23 - unless the language version has been changed using KBUILD_CFLAGS += -std=gnu17 or earlier. C23 includes new keywords 'bool', 'true' and 'false', which cause compilation errors in Linux headers: ./include/linux/types.h:30:33: error: `bool' cannot be defined via `typedef' ./include/linux/stddef.h:11:9: error: cannot use keyword `false' as enumeration constant Add check for C Standard's version in the header files to be able to compile the kernel with C23. Link: https://lkml.kernel.org/r/20251026195846.69740-1-hannelotta@gmail.com Signed-off-by: Hanne-Lotta M��enp�� <hannelotta(a)gmail.com> Cc: David Hunter <david.hunter.linux(a)gmail.com> Cc: "Gustavo A. R. Silva" <gustavoars(a)kernel.org> Cc: Kees Cook <kees(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/stddef.h | 2 ++ include/linux/types.h | 2 ++ 2 files changed, 4 insertions(+) --- a/include/linux/stddef.h~headers-add-check-for-c-standard-version +++ a/include/linux/stddef.h @@ -7,10 +7,12 @@ #undef NULL #define NULL ((void *)0) +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L enum { false = 0, true = 1 }; +#endif #undef offsetof #define offsetof(TYPE, MEMBER) __builtin_offsetof(TYPE, MEMBER) --- a/include/linux/types.h~headers-add-check-for-c-standard-version +++ a/include/linux/types.h @@ -32,7 +32,9 @@ typedef __kernel_timer_t timer_t; typedef __kernel_clockid_t clockid_t; typedef __kernel_mqd_t mqd_t; +#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 202311L typedef _Bool bool; +#endif typedef __kernel_uid32_t uid_t; typedef __kernel_gid32_t gid_t; _ Patches currently in -mm which might be from hannelotta(a)gmail.com are headers-add-check-for-c-standard-version.patch

3 weeks

3
2
0 0

Need Customer Service? Here’s How to Talk to a Live Agent Eurowings

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Eurowings? Calling Eurowings directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Eurowings representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Eurowings (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Eurowings on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Eurowings App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Eurowings, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent XiamenAir

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person XiamenAir? Calling XiamenAir directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real XiamenAir representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach XiamenAir (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM XiamenAir on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the XiamenAir App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to XiamenAir, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Connecting with a Western Air Live Agent: A Step-by-Step Guide

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Western Air? Calling Western Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Western Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Western Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Western Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Western Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Western Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent Viva Aerobus

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Viva Aerobus? Calling Viva Aerobus directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Viva Aerobus representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Viva Aerobus (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Viva Aerobus on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Viva Aerobus App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Viva Aerobus, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Step-by-Step Guide: How to Speak with a Live Agent VietJet Air

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person VietJet Air? Calling VietJet Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real VietJet Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach VietJet Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM VietJet Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the VietJet Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to VietJet Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Copa Airlines Name Change: How to Update Your Flight Details with Ease

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Copa Airlines customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Copa Airlines and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Copa Airlines offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Copa Airlines. 📋 Copa Airlines Name Correction Policy: The Basics Copa Airlines does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Copa Airlines ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Copa Airlines Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Copa Airlines at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Copa Airlines, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

How to Contact a Live Agent Korean Air for Assistance

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Korean Air? Calling Korean Air directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Korean Air representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Korean Air (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Korean Air on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Korean Air App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Korean Air, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Get in Touch with a Live Representative Transavia France

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Transavia France? Calling Transavia France directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Transavia France representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Transavia France (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Transavia France on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Transavia France App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Transavia France, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Tap Air Name Change Made Easy: A Quick Guide to Updating Your Booking

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Tap Air customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Tap Air and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Tap Air offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Tap Air. 📋 Tap Air Name Correction Policy: The Basics Tap Air does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Tap Air ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Tap Air Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Tap Air at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Tap Air, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

How to Easily Contact a Live Agent PSA Airlines for Help

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person PSA Airlines? Calling PSA Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real PSA Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach PSA Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM PSA Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the PSA Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to PSA Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Help with Piedmont Airlines? Here’s How to Speak to a Live Agent

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Piedmont Airlines? Calling Piedmont Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Piedmont Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Piedmont Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Piedmont Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Piedmont Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Piedmont Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Contact a Live Agent Norse Atlantic Airways for Assistance

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Norse Atlantic Airways? Calling Norse Atlantic Airways directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Norse Atlantic Airways representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Norse Atlantic Airways (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Norse Atlantic Airways on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Norse Atlantic Airways App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Norse Atlantic Airways, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person New Pacific Airlines: Tips and Tricks

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person New Pacific Airlines? Calling New Pacific Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real New Pacific Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach New Pacific Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM New Pacific Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the New Pacific Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to New Pacific Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Step-by-Step Guide: How to Speak with a Live Agent Kuwait Airways

by phillipstep.hens.7.823＠gmail.com

Need to talk to a real person Kuwait Airways? Calling Kuwait Airways directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Kuwait Airways representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Kuwait Airways (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Kuwait Airways on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Kuwait Airways App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Kuwait Airways, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Thai Airways Name Change: A Simple Guide to Correcting Your Flight Details

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Thai Airways customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Thai Airways and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Thai Airways offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Thai Airways. 📋 Thai Airways Name Correction Policy: The Basics Thai Airways does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Thai Airways ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Thai Airways Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Thai Airways at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Thai Airways, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

[PATCH 5.10] scsi: target: target_core_configfs: Add length check to avoid buffer overflow

by Andrey Troshin

scsi: target: target_core_configfs: Add length check to avoid buffer overflow A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow. Reported-by: Wang Haoran <haoranwangsec(a)gmail.com> Reported-by: ziiiro <yuanmingbuaa(a)gmail.com> Signed-off-by: Wang Haoran <haoranwangsec(a)gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> [Andrey Troshin: patch adaptation for linux-5.10] Signed-off-by: Andrey Troshin <drtrosh(a)yandex-team.ru> --- Backport fix for CVE-2025-39998 Link: https://nvd.nist.gov/vuln/detail/CVE-2025-39998 --- drivers/target/target_core_configfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c index 4d2fbe1429b6..e6996428c07d 100644 --- a/drivers/target/target_core_configfs.c +++ b/drivers/target/target_core_configfs.c @@ -2637,7 +2637,7 @@ static ssize_t target_lu_gp_members_show(struct config_item *item, char *page) config_item_name(&dev->dev_group.cg_item)); cur_len++; /* Extra byte for NULL terminator */ - if ((cur_len + len) > PAGE_SIZE) { + if ((cur_len + len) > PAGE_SIZE || cur_len > LU_GROUP_NAME_BUF) { pr_warn("Ran out of lu_gp_show_attr" "_members buffer\n"); break; -- 2.34.1

3 weeks

2
1
0 0

Vueling Airlines Name Change Made Easy: A Quick Guide to Updating Your Booking

by 8j42c2cspn＠mrotzis.com

📞 For the fastest help, call Vueling Airlines customer support at 1-866-284-3022. Their agents are trained to assist with name corrections. ✍️ Did you book a flight with Vueling Airlines and realize your name is misspelled or needs updating? Whether it is a minor typo or a legal name change, it is essential to correct your flight details before travel to avoid problems at check-in. Fortunately, Vueling Airlines offers options for name changes or corrections — and we are here to guide you through the process, step by step. 📌 Why Name Corrections Matter Airlines require that the name on your ticket exactly matches the name on your government-issued ID or passport. Even a small typo can result in: ❌ Denied boarding ❌ TSA security issues ❌ Non-refundable tickets going to waste That is why it is important to act quickly if you notice an error. 👉 Pro Tip: As soon as you spot an issue with your name, call 1-866-284-3022 to fix it directly with Vueling Airlines. 📋 Vueling Airlines Name Correction Policy: The Basics Vueling Airlines does allow name corrections and changes, but there are specific rules based on the type and extent of the correction. ✏️ Minor Name Corrections If your correction is minor (e.g., spelling mistake, missing middle name, or nickname to legal name), it is usually easy to fix. Examples: • “Jonh” to “John” • “Liz” to “Elizabeth” • Missing middle name or incorrect initials 🟢 These are typically allowed once per passenger. Call 📞 1-866-284-3022 to request a minor correction. You may need to provide identification or legal documentation. 🔄 Major Name Changes For legal name changes due to: • Marriage 👰 • Divorce 💔 • Legal court order 📄 You will likely be required to submit legal documents (e.g., marriage certificate, divorce decree, or court papers). Important: Name changes are different from transferring your ticket to someone else — Sun Country does not allow name transfers. The passenger must remain the same person. 📞 For clarity and assistance, it is best to speak to a representative at 1-866-284-3022. 💰 Are There Any Fees for Name Changes? Yes, in most cases, Sun Country charges a name change or correction fee, which may vary depending on: • The type of fare you purchased • How close it is to your departure date • Whether the change is made online or via customer service Fees can range from $75 to $150, though minor corrections may be less, especially if made within 24 hours of booking. 🎯 To get an accurate quote and understand your options, call 1-866-284-3022 and speak with a Sun Country agent. 🌐 How to Request a Name Correction There are two main ways to request a name correction on your Vueling Airlines ticket: ✅ 1. Call Customer Support (Recommended) 📞 Dial 1-866-284-3022 📄 Provide your confirmation number, full incorrect name, and the correct name 🧾 Have a valid ID or legal document ready, if needed 🎟️ The agent will process the change and send you an updated itinerary Calling ensures faster processing and personalized help. 💻 2. Manage Booking Online While not all name changes can be made online, you can attempt to: 1. Visit official Sun Country website 2. Click on "My Trips" 3. Enter your last name and confirmation code 4. Look for an option to edit passenger details 📌 If you cannot make changes online, revert to calling 📞 1-866-284-3022. ⏱️ Time-Sensitive Corrections: Act Fast! If your flight is within 24 to 48 hours, do not delay. Last-minute changes can be harder to process and may result in additional fees or denied boarding. 🚨 Urgent situations? Call 📞 1-866-284-3022 immediately. Sun Country's support team can walk you through your options quickly. ✍️ Final Checklist Before You Travel ✅ Name on your ticket matches your ID ✅ You've received an updated confirmation email ✅ You've saved all receipts and documents related to the name correction ✅ You have confirmed there are no other errors in your booking (dates, destinations, etc.) 📞 Need Help? Call Vueling Airlines Anytime Whether you are unsure if your change qualifies or you just want confirmation, don’t hesitate to call Vueling Airlines at 1-866-284-3022. Their support agents are available to: • Handle name corrections • Answer policy questions • Assist with legal document submissions • Avoid unnecessary delays or cancellations 🧳 In Summary Mistakes happen — but with Vueling Airlines, correcting a name on your flight reservation does not have to be stressful. The key is to act fast, follow the policy, and use the right contact channels. 🛑 Do NOT ignore a misspelled name 📞 ALWAYS call 1-866-284-3022 for support 📧 Double-check your confirmation email 📅 Fix issues well before your travel date Safe travels — and smooth corrections!

3 weeks

1
0
0 0

How to Speak to a Live Person Jazz Aviation: Tips and Tricks

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Jazz Aviation? Calling Jazz Aviation directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Jazz Aviation representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Jazz Aviation (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Jazz Aviation on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Jazz Aviation App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Jazz Aviation, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person ITA Airways: Tips and Tricks

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person ITA Airways? Calling ITA Airways directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real ITA Airways representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach ITA Airways (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM ITA Airways on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the ITA Airways App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to ITA Airways, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Connect with a Live Customer Service Agent Hainan Airlines

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Hainan Airlines? Calling Hainan Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Hainan Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Hainan Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Hainan Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Hainan Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Hainan Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person GoJet Airlines: Tips and Tricks

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person GoJet Airlines? Calling GoJet Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real GoJet Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach GoJet Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM GoJet Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the GoJet Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to GoJet Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Get Customer Support from a Live Agent EL AL Israel Airlines

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person EL AL Israel Airlines? Calling EL AL Israel Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real EL AL Israel Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach EL AL Israel Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM EL AL Israel Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the EL AL Israel Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to EL AL Israel Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Cayman Airways: Tips and Tricks

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Cayman Airways? Calling Cayman Airways directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Cayman Airways representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Cayman Airways (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Cayman Airways on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Cayman Airways App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Cayman Airways, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

The Easiest Way to Talk to a Live Agent Azul Brazilian Airlines

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Azul Brazilian Airlines? Calling Azul Brazilian Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Azul Brazilian Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Azul Brazilian Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Azul Brazilian Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Azul Brazilian Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Azul Brazilian Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent Austrian Airlines

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Austrian Airlines? Calling Austrian Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Austrian Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Austrian Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Austrian Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Austrian Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Austrian Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Speak to a Live Person Asiana Airlines: Tips and Tricks

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Asiana Airlines? Calling Asiana Airlines directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Asiana Airlines representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Asiana Airlines (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Asiana Airlines on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Asiana Airlines App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Asiana Airlines, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

Need Customer Service? Here’s How to Talk to a Live Agent Air Mauritius

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Air Mauritius? Calling Air Mauritius directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Air Mauritius representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Air Mauritius (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Air Mauritius on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Air Mauritius App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Air Mauritius, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Contact a Live Agent Air Wisconsin for Assistance

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Air Wisconsin? Calling Air Wisconsin directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Air Wisconsin representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Air Wisconsin (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Air Wisconsin on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Air Wisconsin App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Air Wisconsin, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

How to Easily Contact a Live Agent Air Seychelles for Help

by jacquelinegonza.lez3316.1＠gmail.com

Need to talk to a real person Air Seychelles? Calling Air Seychelles directly at 📞 1-866-284-3022. Whether you are trying to make a flight change, cancel your booking, ask about baggage, or resolve a booking issue, reaching a live agent can save you time, stress, and confusion. While automated systems are useful for simple tasks, some situations just need a human touch. In this guide, we will walk you through exactly how to reach a live person, what to prepare before calling, and alternate methods if the phone lines are busy. ☎️ First Things First: Call 1-866-284-3022 The most direct and reliable way to speak with a real Air Seychelles representative is by calling 📞 1-866-284-3022. This is Frontier’s official customer service number and should be your go-to for: ✈️ Flight changes or cancellations 🧾 Refund or credit questions 🛄 Baggage issues 🔁 Name corrections 🛑 Check-in or boarding problems 💺 Seat selection and upgrades Pro Tip: When calling, try to do so during non-peak hours — early mornings or late evenings — to reduce your hold time. 🎧 How to Navigate the Automated Menu When you call 1-866-284-3022, you will first hear an automated system. To get through to a live person faster, follow these steps: Dial 1-866-284-3022 Wait for the automated greeting to begin Press “1” for English (or “2” for Spanish) Press “2” for existing reservations Press “0” to speak with an agent (you may need to press "0" more than once) 👉 If “0” does not work immediately, stay on the line. Sometimes the system transfers you to an agent after a brief wait without needing more input. If the lines are busy and you are placed on hold, do not hang up — wait times vary, but you will eventually reach someone. 🧾 What to Have Ready Before You Call To help the agent assist you faster, make sure you have the following details on hand: 📌 Your confirmation code or booking number 📌 The full name on the reservation 📌 Your flight date and destination 📌 Any relevant documents (ID, credit card, etc.) 📌 A notepad for writing down instructions or confirmation numbers If you are calling to fix a mistake or request a refund, be prepared to briefly explain the issue and possibly provide documentation via email upon request. ⏰ Best Times to Call 1-866-284-3022 Customer service lines can be busy, especially during: ⚠️ Holidays ⚠️ Severe weather or flight delays ⚠️ Early morning flight hours 🎯 For the best chance at a short wait, try calling during these times: 🕔 5:00 AM – 7:00 AM (EST) 🕘 9:00 PM – 11:00 PM (EST) 📅 Midweek (Tuesdays and Wednesdays) Avoid Mondays if possible — it is the busiest day for airlines. 🧑‍💻 Alternative Ways to Reach Air Seychelles (If Phone Fails) If calling 📞 1-866-284-3022 does not work or you are stuck in a long queue, here are a few alternate ways to get help: 💬 1. Online Chat (Limited Availability) Visit www.flyfrontier.com Scroll down and look for the “Let’s Chat” option. This can connect you to a live agent or AI assistant, depending on availability. 📧 2. Email Support You can also submit a help request through their Customer Support Form online. Use this for non-urgent matters like refund requests or documentation review. 📱 3. Social Media Tweet or DM Air Seychelles on platforms like Twitter/X (@FlyFrontier) or send a message via Facebook. Sometimes social media agents respond faster than the phone team during high-volume periods. 📲 4. Mobile App Download the Air Seychelles App, log in, and navigate to “My Trips” or “Support” for quick options. While this will not guarantee a live agent, you might find answers to basic questions faster. ❗ Common Issues That Require a Live Agent While many tasks can be done online, certain problems are best resolved with a real person at 1-866-284-3022: 🛑 Double charges or billing issues 🔄 Complex flight changes involving multiple passengers 🛄 Lost or delayed baggage ✍️ Legal name changes (marriage, divorce, etc.) 🧑‍⚕️ Medical or accessibility needs during travel In these cases, avoid wasting time — call directly and ask for a live agent. 🚨 Beware of Fake Numbers and Scams Only use the official number: 📞 1-866-284-3022. Scammers often post fake “Frontier support” numbers online, asking for credit card info or login credentials. 🛡️ Never share your full credit card number or personal information with an unverified source. ✅ Final Thoughts Talking to a live person at an airline should not be this hard — but when it comes to Air Seychelles, knowing the right steps and phone number makes all the difference. 🧠 Remember: Dial 📞 1-866-284-3022 Press 0 to reach a live agent Call during off-peak hours Have your booking info ready Use alternative methods if the line is too busy 💡 The sooner you reach out, the more options you'll have to resolve your issue. ✈️ Whether you are rebooking, fixing an error, or checking a flight, calling 1-866-284-3022 connects you with someone who can truly help.

3 weeks

1
0
0 0

[PATCH] virtio: vdpa: Fix reference count leak in octep_sriov_enable()

by Miaoqian Lin

pci_get_device() will increase the reference count for the returned pci_dev, and also decrease the reference count for the input parameter from if it is not NULL. If we break the loop in with 'vf_pdev' not NULL. We need to call pci_dev_put() to decrease the reference count. Found via static anlaysis and this is similar to commit c508eb042d97 ("perf/x86/intel/uncore: Fix reference count leak in sad_cfg_iio_topology()") Fixes: 8b6c724cdab8 ("virtio: vdpa: vDPA driver for Marvell OCTEON DPU devices") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/vdpa/octeon_ep/octep_vdpa_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/vdpa/octeon_ep/octep_vdpa_main.c b/drivers/vdpa/octeon_ep/octep_vdpa_main.c index 9e8d07078606..31a02e7fd7f2 100644 --- a/drivers/vdpa/octeon_ep/octep_vdpa_main.c +++ b/drivers/vdpa/octeon_ep/octep_vdpa_main.c @@ -736,6 +736,7 @@ static int octep_sriov_enable(struct pci_dev *pdev, int num_vfs) octep_vdpa_assign_barspace(vf_pdev, pdev, index); if (++index == num_vfs) { done = true; + pci_dev_put(vf_pdev); break; } } -- 2.39.5 (Apple Git-154)

3 weeks

1
0
0 0

[PATCH] usb: cdns3: Fix double resource release in cdns3_pci_probe

by Miaoqian Lin

The driver uses pcim_enable_device() to enable the PCI device, the device will be automatically disabled on driver detach through the managed device framework. The manual pci_disable_device() calls in the error paths are therefore redundant and should be removed. Found via static anlaysis and this is similar to commit 99ca0b57e49f ("thermal: intel: int340x: processor: Fix warning during module unload"). Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/usb/cdns3/cdns3-pci-wrap.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/usb/cdns3/cdns3-pci-wrap.c b/drivers/usb/cdns3/cdns3-pci-wrap.c index 3b3b3dc75f35..57f57c24c663 100644 --- a/drivers/usb/cdns3/cdns3-pci-wrap.c +++ b/drivers/usb/cdns3/cdns3-pci-wrap.c @@ -98,10 +98,8 @@ static int cdns3_pci_probe(struct pci_dev *pdev, wrap = pci_get_drvdata(func); } else { wrap = kzalloc(sizeof(*wrap), GFP_KERNEL); - if (!wrap) { - pci_disable_device(pdev); + if (!wrap) return -ENOMEM; - } } res = wrap->dev_res; @@ -160,7 +158,6 @@ static int cdns3_pci_probe(struct pci_dev *pdev, /* register platform device */ wrap->plat_dev = platform_device_register_full(&plat_info); if (IS_ERR(wrap->plat_dev)) { - pci_disable_device(pdev); err = PTR_ERR(wrap->plat_dev); kfree(wrap); return err; -- 2.39.5 (Apple Git-154)

3 weeks, 1 day

2
1
0 0

[PATCH] perf: arm_cspmu: fix device leak in arm_cspmu_impl_unregister

by Ma Ke

arm_cspmu_impl_unregister() utilizes driver_find_device() to locate matching devices. driver_find_device() increments the ref count of the found device by calling get_device(), but arm_cspmu_impl_unregister() fails to call put_device() to decrement the reference count after processing each device. This results in a reference count leak of the device objects, which prevents devices from being properly released and causes a memory leak. Fix the leak by adding put_device() after device_release_driver() in the while loop. Found by code review. Cc: stable(a)vger.kernel.org Fixes: bfc653aa89cb ("perf: arm_cspmu: Separate Arm and vendor module") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/perf/arm_cspmu/arm_cspmu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c index efa9b229e701..e0d4293f06f9 100644 --- a/drivers/perf/arm_cspmu/arm_cspmu.c +++ b/drivers/perf/arm_cspmu/arm_cspmu.c @@ -1365,8 +1365,10 @@ void arm_cspmu_impl_unregister(const struct arm_cspmu_impl_match *impl_match) /* Unbind the driver from all matching backend devices. */ while ((dev = driver_find_device(&arm_cspmu_driver.driver, NULL, - match, arm_cspmu_match_device))) + match, arm_cspmu_match_device))) { device_release_driver(dev); + put_device(dev); + } mutex_lock(&arm_cspmu_lock); -- 2.17.1

3 weeks, 1 day

1
0
0 0

[PATCH] ARM: tegra: fix device leak on tegra ahb lookup

by Ma Ke

tegra_ahb_enable_smmu() utilizes driver_find_device_by_of_node() which internally calls driver_find_device() to locate the matching device. driver_find_device() increments the ref count of the found device by calling get_device(), but tegra_ahb_enable_smmu() fails to call put_device() to decrement the reference count before returning. This results in a reference count leak of the device, 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: 89c788bab1f0 ("ARM: tegra: Add SMMU enabler in AHB") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/amba/tegra-ahb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/amba/tegra-ahb.c b/drivers/amba/tegra-ahb.c index c0e8b765522d..6c306d017b67 100644 --- a/drivers/amba/tegra-ahb.c +++ b/drivers/amba/tegra-ahb.c @@ -147,6 +147,7 @@ int tegra_ahb_enable_smmu(struct device_node *dn) val = gizmo_readl(ahb, AHB_ARBITRATION_XBAR_CTRL); val |= AHB_ARBITRATION_XBAR_CTRL_SMMU_INIT_DONE; gizmo_writel(ahb, val, AHB_ARBITRATION_XBAR_CTRL); + put_device(dev); return 0; } EXPORT_SYMBOL(tegra_ahb_enable_smmu); -- 2.17.1

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102623-science-evergreen-c201@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" 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 a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102622-alibi-unloved-94ad@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

3 weeks, 1 day

2
1
0 0

Qualcomm Supply Chain - Sinldo Technology

by Alan Ye

[Sinldo Technology] Company Profile Hong Kong Sinldo Technology Co., Ltd. was established in 2009 and focuses on the supply chain of Qualcomm chips. As a leading supplier in the industry, We have established solid cooperative relationships with many internationally renowned manufacturers and are committed to providing customers with high-quality and reliable chip products. Business Scope： Import and distribution of Qualcomm chips Management and bidding for excess electronic components Provide high-quality customer service and technical support Mission Stable supply Vision Mutual benefit and Triumph Value Reduce Fees and increase efficiency Environment The company is located in the core business district, with convenient transportation, elegant environment and complete surrounding supporting facilities, which facilitates the travel and business exchanges of employees and customers. Milestones 2025 2020 2015 2009 It is expected to complete the upgrade strategic planning, further increase market share, and strive for sustainable development The company implemented a digital management system and began to actively develop online Deals channels The company has added multiple 4G Qualcomm chips and established partnerships with more OEM customers。 The company was formally established in Shenzhen and initially established cooperative relationships with global suppliers Company Environment Coastal Huanqing Building Office Area storehouse [Qualcomm]Company Spot [ WIFI6 - IPQ5018 Kits ] IPQ5018-0-MRQFN232-MT-01-0 QCN6102-0-DRQFN116-TR-01-0 QCA8337-AL3C Snapdragon SDM-450-B Kits SDM-450-B-792NSP-TR-01-0-AA WTR-2965-0-59F0WNSP-TR-07-1 PMI-8952-0-144WLNSP-TR-02-0-00 WCN-3680B-0-79BWLNSP-TR-05-1 PM-8953-0-187F0WNSP-TR-01-1 MDM9x07 Kits MDM-9607-0-328PSP-TR-00-0 MDM-9207-0-328PSP-TR-00-0 WTR-2965-0-59F0WNSP-TR-07-1 PMD-9607-0-94WLNSP-TR-04-2 [Sinldo Technology Co., Ltd.] Email：yesunjian888(a)gmail.com Skype：625285556(a)qq.com Address：Room 2305, Hai'an Huanqing Building, Futian Road, Futian District, Shenzhen Wechat Hit subscribe now to receive regular updates and our product’s latest features! Subscribe If you don't want to receive our emails, you can easily unsubscribe here. Alan Ye Purchasing Manager ：+86 136 0651 6680 QUALCOMM Supply chain : yesunjian888(a)gmail.com

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] vmw_balloon: indicate success when effectively deflating" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 4ba5a8a7faa647ada8eae61a36517cf369f5bbe4 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102655-unequal-disown-9615@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 4ba5a8a7faa647ada8eae61a36517cf369f5bbe4 Mon Sep 17 00:00:00 2001 From: David Hildenbrand <david(a)redhat.com> Date: Tue, 14 Oct 2025 14:44:55 +0200 Subject: [PATCH] vmw_balloon: indicate success when effectively deflating during migration When migrating a balloon page, we first deflate the old page to then inflate the new page. However, if inflating the new page succeeded, we effectively deflated the old page, reducing the balloon size. In that case, the migration actually worked: similar to migrating+ immediately deflating the new page. The old page will be freed back to the buddy. Right now, the core will leave the page be marked as isolated (as we returned an error). When later trying to putback that page, we will run into the WARN_ON_ONCE() in balloon_page_putback(). That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction: stop using __ClearPageMovable()"); before that change, we would have tolerated that way of handling it. To fix it, let's just return 0 in that case, making the core effectively just clear the "isolated" flag + freeing it back to the buddy as if the migration succeeded. Note that the new page will also get freed when the core puts the last reference. Note that this also makes it all be more consistent: we will no longer unisolate the page in the balloon driver while keeping it marked as being isolated in migration core. This was found by code inspection. Link: https://lkml.kernel.org/r/20251014124455.478345-1-david@redhat.com Fixes: 3544c4faccb8 ("mm/balloon_compaction: stop using __ClearPageMovable()") Signed-off-by: David Hildenbrand <david(a)redhat.com> Cc: Jerrin Shaji George <jerrin.shaji-george(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c index 6df51ee8db62..cc1d18b3df5c 100644 --- a/drivers/misc/vmw_balloon.c +++ b/drivers/misc/vmw_balloon.c @@ -1737,7 +1737,7 @@ static int vmballoon_migratepage(struct balloon_dev_info *b_dev_info, { unsigned long status, flags; struct vmballoon *b; - int ret; + int ret = 0; b = container_of(b_dev_info, struct vmballoon, b_dev_info); @@ -1796,17 +1796,15 @@ static int vmballoon_migratepage(struct balloon_dev_info *b_dev_info, * A failure happened. While we can deflate the page we just * inflated, this deflation can also encounter an error. Instead * we will decrease the size of the balloon to reflect the - * change and report failure. + * change. */ atomic64_dec(&b->size); - ret = -EBUSY; } else { /* * Success. Take a reference for the page, and we will add it to * the list after acquiring the lock. */ get_page(newpage); - ret = 0; } /* Update the balloon list under the @pages_lock */ @@ -1817,7 +1815,7 @@ static int vmballoon_migratepage(struct balloon_dev_info *b_dev_info, * If we succeed just insert it to the list and update the statistics * under the lock. */ - if (!ret) { + if (status == VMW_BALLOON_SUCCESS) { balloon_page_insert(&b->b_dev_info, newpage); __count_vm_event(BALLOON_MIGRATE); }

3 weeks, 1 day

2
3
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102621-apply-napping-0bd1@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102646-groggy-overbid-913f@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" 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 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102645-gesture-rebuttal-ebca@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102621-setup-uniformly-7ae5@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102645-pretty-shrewdly-3727@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] arm64: mte: Do not warn if the page is already tagged in" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x b98c94eed4a975e0c80b7e90a649a46967376f58 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102649-rebirth-stray-74d8@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From b98c94eed4a975e0c80b7e90a649a46967376f58 Mon Sep 17 00:00:00 2001 From: Catalin Marinas <catalin.marinas(a)arm.com> Date: Wed, 22 Oct 2025 11:09:14 +0100 Subject: [PATCH] arm64: mte: Do not warn if the page is already tagged in copy_highpage() The arm64 copy_highpage() assumes that the destination page is newly allocated and not MTE-tagged (PG_mte_tagged unset) and warns accordingly. However, following commit 060913999d7a ("mm: migrate: support poisoned recover from migrate folio"), folio_mc_copy() is called before __folio_migrate_mapping(). If the latter fails (-EAGAIN), the copy will be done again to the same destination page. Since copy_highpage() already set the PG_mte_tagged flag, this second copy will warn. Replace the WARN_ON_ONCE(page already tagged) in the arm64 copy_highpage() with a comment. Reported-by: syzbot+d1974fc28545a3e6218b(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/r/68dda1ae.a00a0220.102ee.0065.GAE@google.com Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Will Deacon <will(a)kernel.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: stable(a)vger.kernel.org # 6.12.x Reviewed-by: Yang Shi <yang(a)os.amperecomputing.com> Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com> diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c index a86c897017df..cd5912ba617b 100644 --- a/arch/arm64/mm/copypage.c +++ b/arch/arm64/mm/copypage.c @@ -35,7 +35,7 @@ void copy_highpage(struct page *to, struct page *from) from != folio_page(src, 0)) return; - WARN_ON_ONCE(!folio_try_hugetlb_mte_tagging(dst)); + folio_try_hugetlb_mte_tagging(dst); /* * Populate tags for all subpages. @@ -51,8 +51,13 @@ void copy_highpage(struct page *to, struct page *from) } folio_set_hugetlb_mte_tagged(dst); } else if (page_mte_tagged(from)) { - /* It's a new page, shouldn't have been tagged yet */ - WARN_ON_ONCE(!try_page_mte_tagging(to)); + /* + * Most of the time it's a new page that shouldn't have been + * tagged yet. However, folio migration can end up reusing the + * same page without untagging it. Ignore the warning if the + * page is already tagged. + */ + try_page_mte_tagging(to); mte_copy_page_tags(kto, kfrom); set_page_mte_tagged(to);

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102644-leverage-whiny-afee@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] arch_topology: Fix incorrect error check in" 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 2eead19334516c8e9927c11b448fbe512b1f18a1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102641-epilogue-pronto-38c8@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2eead19334516c8e9927c11b448fbe512b1f18a1 Mon Sep 17 00:00:00 2001 From: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Date: Tue, 23 Sep 2025 23:13:08 +0530 Subject: [PATCH] arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise." This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate(). Cc: stable <stable(a)kernel.org> Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com> Fixes: b8fe128dad8f ("arch_topology: Adjust initial CPU capacities with current freq") Link: https://patch.msgid.link/20250923174308.1771906-1-kaushlendra.kumar@intel.c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 1037169abb45..e1eff05bea4a 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -292,7 +292,7 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) * frequency (by keeping the initial capacity_freq_ref value). */ cpu_clk = of_clk_get(cpu_node, 0); - if (!PTR_ERR_OR_ZERO(cpu_clk)) { + if (!IS_ERR_OR_NULL(cpu_clk)) { per_cpu(capacity_freq_ref, cpu) = clk_get_rate(cpu_clk) / HZ_PER_KHZ; clk_put(cpu_clk);

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] gpio: idio-16: Define fixed direction of the GPIO lines" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 2ba5772e530f73eb847fb96ce6c4017894869552 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102610-dissuade-tamer-7d92@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2ba5772e530f73eb847fb96ce6c4017894869552 Mon Sep 17 00:00:00 2001 From: William Breathitt Gray <wbg(a)kernel.org> Date: Mon, 20 Oct 2025 17:51:46 +0900 Subject: [PATCH] gpio: idio-16: Define fixed direction of the GPIO lines The direction of the IDIO-16 GPIO lines is fixed with the first 16 lines as output and the remaining 16 lines as input. Set the gpio_config fixed_direction_output member to represent the fixed direction of the GPIO lines. Fixes: db02247827ef ("gpio: idio-16: Migrate to the regmap API") Reported-by: Mark Cave-Ayland <mark.caveayland(a)nutanix.com> Closes: https://lore.kernel.org/r/9b0375fd-235f-4ee1-a7fa-daca296ef6bf@nutanix.com Suggested-by: Michael Walle <mwalle(a)kernel.org> Cc: stable(a)vger.kernel.org # ae495810cffe: gpio: regmap: add the .fixed_direction_output configuration parameter Cc: stable(a)vger.kernel.org Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: William Breathitt Gray <wbg(a)kernel.org> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Link: https://lore.kernel.org/r/20251020-fix-gpio-idio-16-regmap-v2-3-ebeb50e93c3… Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> diff --git a/drivers/gpio/gpio-idio-16.c b/drivers/gpio/gpio-idio-16.c index 0103be977c66..4fbae6f6a497 100644 --- a/drivers/gpio/gpio-idio-16.c +++ b/drivers/gpio/gpio-idio-16.c @@ -6,6 +6,7 @@ #define DEFAULT_SYMBOL_NAMESPACE "GPIO_IDIO_16" +#include <linux/bitmap.h> #include <linux/bits.h> #include <linux/device.h> #include <linux/err.h> @@ -107,6 +108,7 @@ int devm_idio_16_regmap_register(struct device *const dev, struct idio_16_data *data; struct regmap_irq_chip *chip; struct regmap_irq_chip_data *chip_data; + DECLARE_BITMAP(fixed_direction_output, IDIO_16_NGPIO); if (!config->parent) return -EINVAL; @@ -164,6 +166,9 @@ int devm_idio_16_regmap_register(struct device *const dev, gpio_config.irq_domain = regmap_irq_get_domain(chip_data); gpio_config.reg_mask_xlate = idio_16_reg_mask_xlate; + bitmap_from_u64(fixed_direction_output, GENMASK_U64(15, 0)); + gpio_config.fixed_direction_output = fixed_direction_output; + return PTR_ERR_OR_ZERO(devm_gpio_regmap_register(dev, &gpio_config)); } EXPORT_SYMBOL_GPL(devm_idio_16_regmap_register);

3 weeks, 1 day

2
3
0 0

FAILED: patch "[PATCH] arch_topology: Fix incorrect error check in" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 2eead19334516c8e9927c11b448fbe512b1f18a1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102641-hydrant-wake-e29d@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2eead19334516c8e9927c11b448fbe512b1f18a1 Mon Sep 17 00:00:00 2001 From: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Date: Tue, 23 Sep 2025 23:13:08 +0530 Subject: [PATCH] arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise." This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate(). Cc: stable <stable(a)kernel.org> Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com> Fixes: b8fe128dad8f ("arch_topology: Adjust initial CPU capacities with current freq") Link: https://patch.msgid.link/20250923174308.1771906-1-kaushlendra.kumar@intel.c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 1037169abb45..e1eff05bea4a 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -292,7 +292,7 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) * frequency (by keeping the initial capacity_freq_ref value). */ cpu_clk = of_clk_get(cpu_node, 0); - if (!PTR_ERR_OR_ZERO(cpu_clk)) { + if (!IS_ERR_OR_NULL(cpu_clk)) { per_cpu(capacity_freq_ref, cpu) = clk_get_rate(cpu_clk) / HZ_PER_KHZ; clk_put(cpu_clk);

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] gpio: idio-16: Define fixed direction of the GPIO lines" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 2ba5772e530f73eb847fb96ce6c4017894869552 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102645-grueling-ramrod-c231@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2ba5772e530f73eb847fb96ce6c4017894869552 Mon Sep 17 00:00:00 2001 From: William Breathitt Gray <wbg(a)kernel.org> Date: Mon, 20 Oct 2025 17:51:46 +0900 Subject: [PATCH] gpio: idio-16: Define fixed direction of the GPIO lines The direction of the IDIO-16 GPIO lines is fixed with the first 16 lines as output and the remaining 16 lines as input. Set the gpio_config fixed_direction_output member to represent the fixed direction of the GPIO lines. Fixes: db02247827ef ("gpio: idio-16: Migrate to the regmap API") Reported-by: Mark Cave-Ayland <mark.caveayland(a)nutanix.com> Closes: https://lore.kernel.org/r/9b0375fd-235f-4ee1-a7fa-daca296ef6bf@nutanix.com Suggested-by: Michael Walle <mwalle(a)kernel.org> Cc: stable(a)vger.kernel.org # ae495810cffe: gpio: regmap: add the .fixed_direction_output configuration parameter Cc: stable(a)vger.kernel.org Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: William Breathitt Gray <wbg(a)kernel.org> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Link: https://lore.kernel.org/r/20251020-fix-gpio-idio-16-regmap-v2-3-ebeb50e93c3… Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> diff --git a/drivers/gpio/gpio-idio-16.c b/drivers/gpio/gpio-idio-16.c index 0103be977c66..4fbae6f6a497 100644 --- a/drivers/gpio/gpio-idio-16.c +++ b/drivers/gpio/gpio-idio-16.c @@ -6,6 +6,7 @@ #define DEFAULT_SYMBOL_NAMESPACE "GPIO_IDIO_16" +#include <linux/bitmap.h> #include <linux/bits.h> #include <linux/device.h> #include <linux/err.h> @@ -107,6 +108,7 @@ int devm_idio_16_regmap_register(struct device *const dev, struct idio_16_data *data; struct regmap_irq_chip *chip; struct regmap_irq_chip_data *chip_data; + DECLARE_BITMAP(fixed_direction_output, IDIO_16_NGPIO); if (!config->parent) return -EINVAL; @@ -164,6 +166,9 @@ int devm_idio_16_regmap_register(struct device *const dev, gpio_config.irq_domain = regmap_irq_get_domain(chip_data); gpio_config.reg_mask_xlate = idio_16_reg_mask_xlate; + bitmap_from_u64(fixed_direction_output, GENMASK_U64(15, 0)); + gpio_config.fixed_direction_output = fixed_direction_output; + return PTR_ERR_OR_ZERO(devm_gpio_regmap_register(dev, &gpio_config)); } EXPORT_SYMBOL_GPL(devm_idio_16_regmap_register);

3 weeks, 1 day

2
3
0 0

FAILED: patch "[PATCH] fs/notify: call exportfs_encode_fid with s_umount" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 a7c4bb43bfdc2b9f06ee9d036028ed13a83df42a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102612-kissing-atrocious-4949@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a7c4bb43bfdc2b9f06ee9d036028ed13a83df42a Mon Sep 17 00:00:00 2001 From: Jakub Acs <acsjakub(a)amazon.de> Date: Wed, 1 Oct 2025 10:09:55 +0000 Subject: [PATCH] fs/notify: call exportfs_encode_fid with s_umount Calling intotify_show_fdinfo() on fd watching an overlayfs inode, while the overlayfs is being unmounted, can lead to dereferencing NULL ptr. This issue was found by syzkaller. Race Condition Diagram: Thread 1 Thread 2 -------- -------- generic_shutdown_super() shrink_dcache_for_umount sb->s_root = NULL | | vfs_read() | inotify_fdinfo() | * inode get from mark * | show_mark_fhandle(m, inode) | exportfs_encode_fid(inode, ..) | ovl_encode_fh(inode, ..) | ovl_check_encode_origin(inode) | * deref i_sb->s_root * | | v fsnotify_sb_delete(sb) Which then leads to: [ 32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none) <snip registers, unreliable trace> [ 32.143353] Call Trace: [ 32.143732] ovl_encode_fh+0xd5/0x170 [ 32.144031] exportfs_encode_inode_fh+0x12f/0x300 [ 32.144425] show_mark_fhandle+0xbe/0x1f0 [ 32.145805] inotify_fdinfo+0x226/0x2d0 [ 32.146442] inotify_show_fdinfo+0x1c5/0x350 [ 32.147168] seq_show+0x530/0x6f0 [ 32.147449] seq_read_iter+0x503/0x12a0 [ 32.148419] seq_read+0x31f/0x410 [ 32.150714] vfs_read+0x1f0/0x9e0 [ 32.152297] ksys_read+0x125/0x240 IOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set to NULL in the unmount path. Fix it by protecting calling exportfs_encode_fid() from show_mark_fhandle() with s_umount lock. This form of fix was suggested by Amir in [1]. [1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJ… Fixes: c45beebfde34 ("ovl: support encoding fid from inode with no alias") Signed-off-by: Jakub Acs <acsjakub(a)amazon.de> Cc: Jan Kara <jack(a)suse.cz> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: Miklos Szeredi <miklos(a)szeredi.hu> Cc: Christian Brauner <brauner(a)kernel.org> Cc: linux-unionfs(a)vger.kernel.org Cc: linux-fsdevel(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Signed-off-by: Jan Kara <jack(a)suse.cz> diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c index 1161eabf11ee..9cc7eb863643 100644 --- a/fs/notify/fdinfo.c +++ b/fs/notify/fdinfo.c @@ -17,6 +17,7 @@ #include "fanotify/fanotify.h" #include "fdinfo.h" #include "fsnotify.h" +#include "../internal.h" #if defined(CONFIG_PROC_FS) @@ -46,7 +47,12 @@ static void show_mark_fhandle(struct seq_file *m, struct inode *inode) size = f->handle_bytes >> 2; + if (!super_trylock_shared(inode->i_sb)) + return; + ret = exportfs_encode_fid(inode, (struct fid *)f->f_handle, &size); + up_read(&inode->i_sb->s_umount); + if ((ret == FILEID_INVALID) || (ret < 0)) return;

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] arch_topology: Fix incorrect error check in" 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 2eead19334516c8e9927c11b448fbe512b1f18a1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102641-derail-shine-9dd5@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2eead19334516c8e9927c11b448fbe512b1f18a1 Mon Sep 17 00:00:00 2001 From: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Date: Tue, 23 Sep 2025 23:13:08 +0530 Subject: [PATCH] arch_topology: Fix incorrect error check in topology_parse_cpu_capacity() Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate(). Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise." This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL. Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate(). Cc: stable <stable(a)kernel.org> Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Reviewed-by: Sudeep Holla <sudeep.holla(a)arm.com> Fixes: b8fe128dad8f ("arch_topology: Adjust initial CPU capacities with current freq") Link: https://patch.msgid.link/20250923174308.1771906-1-kaushlendra.kumar@intel.c… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c index 1037169abb45..e1eff05bea4a 100644 --- a/drivers/base/arch_topology.c +++ b/drivers/base/arch_topology.c @@ -292,7 +292,7 @@ bool __init topology_parse_cpu_capacity(struct device_node *cpu_node, int cpu) * frequency (by keeping the initial capacity_freq_ref value). */ cpu_clk = of_clk_get(cpu_node, 0); - if (!PTR_ERR_OR_ZERO(cpu_clk)) { + if (!IS_ERR_OR_NULL(cpu_clk)) { per_cpu(capacity_freq_ref, cpu) = clk_get_rate(cpu_clk) / HZ_PER_KHZ; clk_put(cpu_clk);

3 weeks, 1 day

2
1
0 0

Re: Patch "binfmt_elf: preserve original ELF e_flags for core dumps" has been added to the 6.17-stable tree

by Kees Cook

On Thu, Oct 23, 2025 at 11:24:08AM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > binfmt_elf: preserve original ELF e_flags for core dumps > > to the 6.17-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: > binfmt_elf-preserve-original-elf-e_flags-for-core-du.patch > and it can be found in the queue-6.17 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. No, I asked that it not be backported: https://lore.kernel.org/all/202510020856.736F028D@keescook/ > -- Kees Cook

3 weeks, 1 day

2
1
0 0

Please apply commit d88a8bb8bbbe ("Bluetooth: btintel: Add DSBR support for BlazarIW, BlazarU and GaP") to 6.12.y

by Salvatore Bonaccorso

Hi Guido Berhoerster asked in Debian (https://bugs.debian.org/1118660) to consider adding support for bluetooth device of BlazarIW, BlazarU and Gale Peak2 cores, which landed in 6.13-rc1, via d88a8bb8bbbe ("Bluetooth: btintel: Add DSBR support for BlazarIW, BlazarU and GaP"). While it is not exactly a bugfix, as things were not working beforehand as well, this type of hardware might be very common during the lifecycle of users for 6.12.y stable series. Can you consider picking the commit for 6.12.y? Regards, Salvatore

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] io_uring/sqpoll: be smarter on when to update the stime usage" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x a94e0657269c5b8e1a90b17aa2c048b3d276e16d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102618-plastic-eldercare-f957@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a94e0657269c5b8e1a90b17aa2c048b3d276e16d Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Tue, 21 Oct 2025 11:44:39 -0600 Subject: [PATCH] io_uring/sqpoll: be smarter on when to update the stime usage The current approach is a bit naive, and hence calls the time querying way too often. Only start the "doing work" timer when there's actual work to do, and then use that information to terminate (and account) the work time once done. This greatly reduces the frequency of these calls, when they cannot have changed anyway. Running a basic random reader that is setup to use SQPOLL, a profile before this change shows these as the top cycle consumers: + 32.60% iou-sqp-1074 [kernel.kallsyms] [k] thread_group_cputime_adjusted + 19.97% iou-sqp-1074 [kernel.kallsyms] [k] thread_group_cputime + 12.20% io_uring io_uring [.] submitter_uring_fn + 4.13% iou-sqp-1074 [kernel.kallsyms] [k] getrusage + 2.45% iou-sqp-1074 [kernel.kallsyms] [k] io_submit_sqes + 2.18% iou-sqp-1074 [kernel.kallsyms] [k] __pi_memset_generic + 2.09% iou-sqp-1074 [kernel.kallsyms] [k] cputime_adjust and after this change, top of profile looks as follows: + 36.23% io_uring io_uring [.] submitter_uring_fn + 23.26% iou-sqp-819 [kernel.kallsyms] [k] io_sq_thread + 10.14% iou-sqp-819 [kernel.kallsyms] [k] io_sq_tw + 6.52% iou-sqp-819 [kernel.kallsyms] [k] tctx_task_work_run + 4.82% iou-sqp-819 [kernel.kallsyms] [k] nvme_submit_cmds.part.0 + 2.91% iou-sqp-819 [kernel.kallsyms] [k] io_submit_sqes [...] 0.02% iou-sqp-819 [kernel.kallsyms] [k] cputime_adjust where it's spending the cycles on things that actually matter. Reported-by: Fengnan Chang <changfengnan(a)bytedance.com> Cc: stable(a)vger.kernel.org Fixes: 3fcb9d17206e ("io_uring/sqpoll: statistics of the true utilization of sq threads") Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c index 2b816fdb9866..e22f072c7d5f 100644 --- a/io_uring/sqpoll.c +++ b/io_uring/sqpoll.c @@ -170,6 +170,11 @@ static inline bool io_sqd_events_pending(struct io_sq_data *sqd) return READ_ONCE(sqd->state); } +struct io_sq_time { + bool started; + u64 usec; +}; + u64 io_sq_cpu_usec(struct task_struct *tsk) { u64 utime, stime; @@ -179,12 +184,24 @@ u64 io_sq_cpu_usec(struct task_struct *tsk) return stime; } -static void io_sq_update_worktime(struct io_sq_data *sqd, u64 usec) +static void io_sq_update_worktime(struct io_sq_data *sqd, struct io_sq_time *ist) { - sqd->work_time += io_sq_cpu_usec(current) - usec; + if (!ist->started) + return; + ist->started = false; + sqd->work_time += io_sq_cpu_usec(current) - ist->usec; } -static int __io_sq_thread(struct io_ring_ctx *ctx, bool cap_entries) +static void io_sq_start_worktime(struct io_sq_time *ist) +{ + if (ist->started) + return; + ist->started = true; + ist->usec = io_sq_cpu_usec(current); +} + +static int __io_sq_thread(struct io_ring_ctx *ctx, struct io_sq_data *sqd, + bool cap_entries, struct io_sq_time *ist) { unsigned int to_submit; int ret = 0; @@ -197,6 +214,8 @@ static int __io_sq_thread(struct io_ring_ctx *ctx, bool cap_entries) if (to_submit || !wq_list_empty(&ctx->iopoll_list)) { const struct cred *creds = NULL; + io_sq_start_worktime(ist); + if (ctx->sq_creds != current_cred()) creds = override_creds(ctx->sq_creds); @@ -278,7 +297,6 @@ static int io_sq_thread(void *data) unsigned long timeout = 0; char buf[TASK_COMM_LEN] = {}; DEFINE_WAIT(wait); - u64 start; /* offload context creation failed, just exit */ if (!current->io_uring) { @@ -313,6 +331,7 @@ static int io_sq_thread(void *data) mutex_lock(&sqd->lock); while (1) { bool cap_entries, sqt_spin = false; + struct io_sq_time ist = { }; if (io_sqd_events_pending(sqd) || signal_pending(current)) { if (io_sqd_handle_event(sqd)) @@ -321,9 +340,8 @@ static int io_sq_thread(void *data) } cap_entries = !list_is_singular(&sqd->ctx_list); - start = io_sq_cpu_usec(current); list_for_each_entry(ctx, &sqd->ctx_list, sqd_list) { - int ret = __io_sq_thread(ctx, cap_entries); + int ret = __io_sq_thread(ctx, sqd, cap_entries, &ist); if (!sqt_spin && (ret > 0 || !wq_list_empty(&ctx->iopoll_list))) sqt_spin = true; @@ -331,15 +349,18 @@ static int io_sq_thread(void *data) if (io_sq_tw(&retry_list, IORING_TW_CAP_ENTRIES_VALUE)) sqt_spin = true; - list_for_each_entry(ctx, &sqd->ctx_list, sqd_list) - if (io_napi(ctx)) + list_for_each_entry(ctx, &sqd->ctx_list, sqd_list) { + if (io_napi(ctx)) { + io_sq_start_worktime(&ist); io_napi_sqpoll_busy_poll(ctx); + } + } + + io_sq_update_worktime(sqd, &ist); if (sqt_spin || !time_after(jiffies, timeout)) { - if (sqt_spin) { - io_sq_update_worktime(sqd, start); + if (sqt_spin) timeout = jiffies + sqd->sq_thread_idle; - } if (unlikely(need_resched())) { mutex_unlock(&sqd->lock); cond_resched();

3 weeks, 1 day

3
2
0 0

FAILED: patch "[PATCH] drm/amd/display: use GFP_NOWAIT for allocation in interrupt" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 72a1eb3cf573ab957ae412f0efb0cf6ff0876234 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102633-shimmy-ferocity-c891@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 72a1eb3cf573ab957ae412f0efb0cf6ff0876234 Mon Sep 17 00:00:00 2001 From: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Date: Thu, 25 Sep 2025 10:23:59 -0400 Subject: [PATCH] drm/amd/display: use GFP_NOWAIT for allocation in interrupt handler schedule_dc_vmin_vmax() is called by dm_crtc_high_irq(). Hence, we cannot have the former sleep. Use GFP_NOWAIT for allocation in this function. Fixes: c210b757b400 ("drm/amd/display: fix dmub access race condition") Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Sun peng (Leo) Li <sunpeng.li(a)amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit c04812cbe2f247a1c1e53a9b6c5e659963fe4065) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 6597475e245d..bfa3199591b6 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -551,13 +551,13 @@ static void schedule_dc_vmin_vmax(struct amdgpu_device *adev, struct dc_stream_state *stream, struct dc_crtc_timing_adjust *adjust) { - struct vupdate_offload_work *offload_work = kzalloc(sizeof(*offload_work), GFP_KERNEL); + struct vupdate_offload_work *offload_work = kzalloc(sizeof(*offload_work), GFP_NOWAIT); if (!offload_work) { drm_dbg_driver(adev_to_drm(adev), "Failed to allocate vupdate_offload_work\n"); return; } - struct dc_crtc_timing_adjust *adjust_copy = kzalloc(sizeof(*adjust_copy), GFP_KERNEL); + struct dc_crtc_timing_adjust *adjust_copy = kzalloc(sizeof(*adjust_copy), GFP_NOWAIT); if (!adjust_copy) { drm_dbg_driver(adev_to_drm(adev), "Failed to allocate adjust_copy\n"); kfree(offload_work);

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] drm/amd/display: Fix NULL pointer dereference" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x 89939cf252d80237ed380c1d20575ecfe56ff894 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102625-bright-circulate-8844@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 89939cf252d80237ed380c1d20575ecfe56ff894 Mon Sep 17 00:00:00 2001 From: Meenakshikumar Somasundaram <meenakshikumar.somasundaram(a)amd.com> Date: Mon, 29 Sep 2025 14:28:34 -0400 Subject: [PATCH] drm/amd/display: Fix NULL pointer dereference [Why] On a mst branch with multi display setup, dc context is obselete after updating the first stream. Referencing the same dc context for the next stream update to fetch dc pointer leads to NULL pointer dereference. [How] Get the dc pointer from the link rather than context. Cc: Mario Limonciello <mario.limonciello(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Charlene Liu <charlene.liu(a)amd.com> Signed-off-by: Meenakshikumar Somasundaram <meenakshikumar.somasundaram(a)amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit dc69b48988b171d6ccb3a083607e4dff015e2c0d) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_cts.c b/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_cts.c index 9e33bf937a69..2676ae9f6fe8 100644 --- a/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_cts.c +++ b/drivers/gpu/drm/amd/display/dc/link/accessories/link_dp_cts.c @@ -78,6 +78,7 @@ static void dp_retrain_link_dp_test(struct dc_link *link, struct audio_output audio_output[MAX_PIPES]; struct dc_stream_state *streams_on_link[MAX_PIPES]; int num_streams_on_link = 0; + struct dc *dc = (struct dc *)link->dc; needs_divider_update = (link->dc->link_srv->dp_get_encoding_format(link_setting) != link->dc->link_srv->dp_get_encoding_format((const struct dc_link_settings *) &link->cur_link_settings)); @@ -150,7 +151,7 @@ static void dp_retrain_link_dp_test(struct dc_link *link, if (streams_on_link[i] && streams_on_link[i]->link && streams_on_link[i]->link == link) { stream_update.stream = streams_on_link[i]; stream_update.dpms_off = &dpms_off; - dc_update_planes_and_stream(state->clk_mgr->ctx->dc, NULL, 0, streams_on_link[i], &stream_update); + dc_update_planes_and_stream(dc, NULL, 0, streams_on_link[i], &stream_update); } } }

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] drm/xe: Check return value of GGTT workqueue allocation" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x ce29214ada6d08dbde1eeb5a69c3b09ddf3da146 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102655-unsettled-dingy-acaf@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ce29214ada6d08dbde1eeb5a69c3b09ddf3da146 Mon Sep 17 00:00:00 2001 From: Matthew Brost <matthew.brost(a)intel.com> Date: Tue, 21 Oct 2025 17:55:36 -0700 Subject: [PATCH] drm/xe: Check return value of GGTT workqueue allocation Workqueue allocation can fail, so check the return value of the GGTT workqueue allocation and fail driver initialization if the allocation fails. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable(a)vger.kernel.org Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> Link: https://lore.kernel.org/r/20251022005538.828980-2-matthew.brost@intel.com (cherry picked from commit 1f1314e8e71385bae319e43082b798c11f6648bc) Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> diff --git a/drivers/gpu/drm/xe/xe_ggtt.c b/drivers/gpu/drm/xe/xe_ggtt.c index 7fdd0a97a628..5edc0cad47e2 100644 --- a/drivers/gpu/drm/xe/xe_ggtt.c +++ b/drivers/gpu/drm/xe/xe_ggtt.c @@ -292,6 +292,9 @@ int xe_ggtt_init_early(struct xe_ggtt *ggtt) ggtt->pt_ops = &xelp_pt_ops; ggtt->wq = alloc_workqueue("xe-ggtt-wq", 0, WQ_MEM_RECLAIM); + if (!ggtt->wq) + return -ENOMEM; + __xe_ggtt_init_early(ggtt, xe_wopcm_size(xe)); err = drmm_add_action_or_reset(&xe->drm, ggtt_fini_early, ggtt);

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] io_uring/sqpoll: switch away from getrusage() for CPU" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x 8ac9b0d33e5c0a995338ee5f25fe1b6ff7d97f65 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102606-showplace-direness-c7b3@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 8ac9b0d33e5c0a995338ee5f25fe1b6ff7d97f65 Mon Sep 17 00:00:00 2001 From: Jens Axboe <axboe(a)kernel.dk> Date: Tue, 21 Oct 2025 07:16:08 -0600 Subject: [PATCH] io_uring/sqpoll: switch away from getrusage() for CPU accounting getrusage() does a lot more than what the SQPOLL accounting needs, the latter only cares about (and uses) the stime. Rather than do a full RUSAGE_SELF summation, just query the used stime instead. Cc: stable(a)vger.kernel.org Fixes: 3fcb9d17206e ("io_uring/sqpoll: statistics of the true utilization of sq threads") Reviewed-by: Gabriel Krisman Bertazi <krisman(a)suse.de> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> diff --git a/io_uring/fdinfo.c b/io_uring/fdinfo.c index ff3364531c77..294c75a8a3bd 100644 --- a/io_uring/fdinfo.c +++ b/io_uring/fdinfo.c @@ -59,7 +59,6 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m) { struct io_overflow_cqe *ocqe; struct io_rings *r = ctx->rings; - struct rusage sq_usage; unsigned int sq_mask = ctx->sq_entries - 1, cq_mask = ctx->cq_entries - 1; unsigned int sq_head = READ_ONCE(r->sq.head); unsigned int sq_tail = READ_ONCE(r->sq.tail); @@ -152,14 +151,15 @@ static void __io_uring_show_fdinfo(struct io_ring_ctx *ctx, struct seq_file *m) * thread termination. */ if (tsk) { + u64 usec; + get_task_struct(tsk); rcu_read_unlock(); - getrusage(tsk, RUSAGE_SELF, &sq_usage); + usec = io_sq_cpu_usec(tsk); put_task_struct(tsk); sq_pid = sq->task_pid; sq_cpu = sq->sq_cpu; - sq_total_time = (sq_usage.ru_stime.tv_sec * 1000000 - + sq_usage.ru_stime.tv_usec); + sq_total_time = usec; sq_work_time = sq->work_time; } else { rcu_read_unlock(); diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c index a3f11349ce06..2b816fdb9866 100644 --- a/io_uring/sqpoll.c +++ b/io_uring/sqpoll.c @@ -11,6 +11,7 @@ #include <linux/audit.h> #include <linux/security.h> #include <linux/cpuset.h> +#include <linux/sched/cputime.h> #include <linux/io_uring.h> #include <uapi/linux/io_uring.h> @@ -169,6 +170,20 @@ static inline bool io_sqd_events_pending(struct io_sq_data *sqd) return READ_ONCE(sqd->state); } +u64 io_sq_cpu_usec(struct task_struct *tsk) +{ + u64 utime, stime; + + task_cputime_adjusted(tsk, &utime, &stime); + do_div(stime, 1000); + return stime; +} + +static void io_sq_update_worktime(struct io_sq_data *sqd, u64 usec) +{ + sqd->work_time += io_sq_cpu_usec(current) - usec; +} + static int __io_sq_thread(struct io_ring_ctx *ctx, bool cap_entries) { unsigned int to_submit; @@ -255,26 +270,15 @@ static bool io_sq_tw_pending(struct llist_node *retry_list) return retry_list || !llist_empty(&tctx->task_list); } -static void io_sq_update_worktime(struct io_sq_data *sqd, struct rusage *start) -{ - struct rusage end; - - getrusage(current, RUSAGE_SELF, &end); - end.ru_stime.tv_sec -= start->ru_stime.tv_sec; - end.ru_stime.tv_usec -= start->ru_stime.tv_usec; - - sqd->work_time += end.ru_stime.tv_usec + end.ru_stime.tv_sec * 1000000; -} - static int io_sq_thread(void *data) { struct llist_node *retry_list = NULL; struct io_sq_data *sqd = data; struct io_ring_ctx *ctx; - struct rusage start; unsigned long timeout = 0; char buf[TASK_COMM_LEN] = {}; DEFINE_WAIT(wait); + u64 start; /* offload context creation failed, just exit */ if (!current->io_uring) { @@ -317,7 +321,7 @@ static int io_sq_thread(void *data) } cap_entries = !list_is_singular(&sqd->ctx_list); - getrusage(current, RUSAGE_SELF, &start); + start = io_sq_cpu_usec(current); list_for_each_entry(ctx, &sqd->ctx_list, sqd_list) { int ret = __io_sq_thread(ctx, cap_entries); @@ -333,7 +337,7 @@ static int io_sq_thread(void *data) if (sqt_spin || !time_after(jiffies, timeout)) { if (sqt_spin) { - io_sq_update_worktime(sqd, &start); + io_sq_update_worktime(sqd, start); timeout = jiffies + sqd->sq_thread_idle; } if (unlikely(need_resched())) { diff --git a/io_uring/sqpoll.h b/io_uring/sqpoll.h index b83dcdec9765..fd2f6f29b516 100644 --- a/io_uring/sqpoll.h +++ b/io_uring/sqpoll.h @@ -29,6 +29,7 @@ void io_sq_thread_unpark(struct io_sq_data *sqd); void io_put_sq_data(struct io_sq_data *sqd); void io_sqpoll_wait_sq(struct io_ring_ctx *ctx); int io_sqpoll_wq_cpu_affinity(struct io_ring_ctx *ctx, cpumask_var_t mask); +u64 io_sq_cpu_usec(struct task_struct *tsk); static inline struct task_struct *sqpoll_task_locked(struct io_sq_data *sqd) {

3 weeks, 1 day

2
1
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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.4.y git checkout FETCH_HEAD git cherry-pick -x e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102615-unsoiled-renovator-7821@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" 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 e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102614-goatskin-stopped-5434@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

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 e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102614-knickers-other-9f02@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" 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 e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102614-trustful-rancidity-1b04@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

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 e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102613-disgrace-junkman-a4f1@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-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.12.y git checkout FETCH_HEAD git cherry-pick -x e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102613-alarm-decipher-135c@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

FAILED: patch "[PATCH] smb: client: allocate enough space for MR WRs and" failed to apply to 6.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.17-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.17.y git checkout FETCH_HEAD git cherry-pick -x e607ef686ab95fbcb0dfd16f49aea7918be626e1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102613-galvanize-commerce-52df@gregkh' --subject-prefix 'PATCH 6.17.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From e607ef686ab95fbcb0dfd16f49aea7918be626e1 Mon Sep 17 00:00:00 2001 From: Stefan Metzmacher <metze(a)samba.org> Date: Thu, 16 Oct 2025 12:54:21 +0200 Subject: [PATCH] smb: client: allocate enough space for MR WRs and ib_drain_qp() The IB_WR_REG_MR and IB_WR_LOCAL_INV operations for smbdirect_mr_io structures should never fail because the submission or completion queues are too small. So we allocate more send_wr depending on the (local) max number of MRs. While there also add additional space for ib_drain_qp(). This should make sure ib_post_send() will never fail because the submission queue is full. Fixes: f198186aa9bb ("CIFS: SMBD: Establish SMB Direct connection") Fixes: cc55f65dd352 ("smb: client: make use of common smbdirect_socket_parameters") Cc: stable(a)vger.kernel.org Cc: Steve French <smfrench(a)gmail.com> Cc: Tom Talpey <tom(a)talpey.com> Cc: Long Li <longli(a)microsoft.com> Cc: Namjae Jeon <linkinjeon(a)kernel.org> Cc: linux-cifs(a)vger.kernel.org Cc: samba-technical(a)lists.samba.org Signed-off-by: Stefan Metzmacher <metze(a)samba.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> diff --git a/fs/smb/client/smbdirect.c b/fs/smb/client/smbdirect.c index 49e2df3ad1f0..b1218ea4aa8b 100644 --- a/fs/smb/client/smbdirect.c +++ b/fs/smb/client/smbdirect.c @@ -1767,6 +1767,7 @@ static struct smbd_connection *_smbd_get_connection( struct smbdirect_socket *sc; struct smbdirect_socket_parameters *sp; struct rdma_conn_param conn_param; + struct ib_qp_cap qp_cap; struct ib_qp_init_attr qp_attr; struct sockaddr_in *addr_in = (struct sockaddr_in *) dstaddr; struct ib_port_immutable port_immutable; @@ -1838,6 +1839,25 @@ static struct smbd_connection *_smbd_get_connection( goto config_failed; } + sp->responder_resources = + min_t(u8, sp->responder_resources, + sc->ib.dev->attrs.max_qp_rd_atom); + log_rdma_mr(INFO, "responder_resources=%d\n", + sp->responder_resources); + + /* + * We use allocate sp->responder_resources * 2 MRs + * and each MR needs WRs for REG and INV, so + * we use '* 4'. + * + * +1 for ib_drain_qp() + */ + memset(&qp_cap, 0, sizeof(qp_cap)); + qp_cap.max_send_wr = sp->send_credit_target + sp->responder_resources * 4 + 1; + qp_cap.max_recv_wr = sp->recv_credit_max + 1; + qp_cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; + qp_cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; + sc->ib.pd = ib_alloc_pd(sc->ib.dev, 0); if (IS_ERR(sc->ib.pd)) { rc = PTR_ERR(sc->ib.pd); @@ -1848,7 +1868,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.send_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->send_credit_target, IB_POLL_SOFTIRQ); + qp_cap.max_send_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.send_cq)) { sc->ib.send_cq = NULL; goto alloc_cq_failed; @@ -1856,7 +1876,7 @@ static struct smbd_connection *_smbd_get_connection( sc->ib.recv_cq = ib_alloc_cq_any(sc->ib.dev, sc, - sp->recv_credit_max, IB_POLL_SOFTIRQ); + qp_cap.max_recv_wr, IB_POLL_SOFTIRQ); if (IS_ERR(sc->ib.recv_cq)) { sc->ib.recv_cq = NULL; goto alloc_cq_failed; @@ -1865,11 +1885,7 @@ static struct smbd_connection *_smbd_get_connection( memset(&qp_attr, 0, sizeof(qp_attr)); qp_attr.event_handler = smbd_qp_async_error_upcall; qp_attr.qp_context = sc; - qp_attr.cap.max_send_wr = sp->send_credit_target; - qp_attr.cap.max_recv_wr = sp->recv_credit_max; - qp_attr.cap.max_send_sge = SMBDIRECT_SEND_IO_MAX_SGE; - qp_attr.cap.max_recv_sge = SMBDIRECT_RECV_IO_MAX_SGE; - qp_attr.cap.max_inline_data = 0; + qp_attr.cap = qp_cap; qp_attr.sq_sig_type = IB_SIGNAL_REQ_WR; qp_attr.qp_type = IB_QPT_RC; qp_attr.send_cq = sc->ib.send_cq; @@ -1883,12 +1899,6 @@ static struct smbd_connection *_smbd_get_connection( } sc->ib.qp = sc->rdma.cm_id->qp; - sp->responder_resources = - min_t(u8, sp->responder_resources, - sc->ib.dev->attrs.max_qp_rd_atom); - log_rdma_mr(INFO, "responder_resources=%d\n", - sp->responder_resources); - memset(&conn_param, 0, sizeof(conn_param)); conn_param.initiator_depth = sp->initiator_depth; conn_param.responder_resources = sp->responder_resources;

3 weeks, 1 day

1
0
0 0

5.10 kernel series fails to build on newer toolchain: FAILED unresolved symbol filp_close

by Philip Müller

For some odd reason 5.10 kernel series doesn't compile with a newer toolchain since 2025-02-09: 2025-02-09T17:32:07.7991299Z GEN .version 2025-02-09T17:32:07.8270062Z CHK include/generated/compile.h 2025-02-09T17:32:07.8540777Z LD vmlinux.o 2025-02-09T17:32:11.7210899Z MODPOST vmlinux.symvers 2025-02-09T17:32:12.0869599Z MODINFO modules.builtin.modinfo 2025-02-09T17:32:12.1403022Z GEN modules.builtin 2025-02-09T17:32:12.1475659Z LD .tmp_vmlinux.btf 2025-02-09T17:32:19.6117204Z BTF .btf.vmlinux.bin.o 2025-02-09T17:32:31.2916650Z LD .tmp_vmlinux.kallsyms1 2025-02-09T17:32:34.8731104Z KSYMS .tmp_vmlinux.kallsyms1.S 2025-02-09T17:32:35.4910608Z AS .tmp_vmlinux.kallsyms1.o 2025-02-09T17:32:35.9662538Z LD .tmp_vmlinux.kallsyms2 2025-02-09T17:32:39.2595984Z KSYMS .tmp_vmlinux.kallsyms2.S 2025-02-09T17:32:39.8802028Z AS .tmp_vmlinux.kallsyms2.o 2025-02-09T17:32:40.3659440Z LD vmlinux 2025-02-09T17:32:48.0031558Z BTFIDS vmlinux 2025-02-09T17:32:48.0143553Z FAILED unresolved symbol filp_close 2025-02-09T17:32:48.5019928Z make: *** [Makefile:1207: vmlinux] Error 255 2025-02-09T17:32:48.5061241Z ==> ERROR: A failure occurred in build(). 5.10.234 built fine couple of days ago with the older one. There were slight changes made. 5.4 and 5.15 still compile. Wonder what might be missing here ... -- Best, Philip

3 weeks, 1 day

5
14
0 0

🕘 Mark Your Calendar: DUOONE OLED SPAN/FOLD Launches on Kickstarter on Nov 15!

by InnLead Innovative

🕘 Mark Your Calendar: DUOONE OLED SPAN/FOLD Launches on Kickstarter on Nov 15! Multiplayer Gaming, Dual Fun & Work | Duel, Tabletop & Video Games | 1ms Respones Time | Vivid Lifelike OLED ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ Hello, Hope you’ve been doing great! I just wanted to share something I’m really excited about — we’ve been working on a game-changing OLED dual-monitor called DUOONE OLED SPAN/FOLD, and it’s finally launching on Kickstarter ( http://tracking.nextech.shop/tracking/click?d=4AivePE4XMH7w6uFxD5qcyyWtLdIu… )at: 🕘 9:00 AM, Saturday, November 15 (New York time) Time zones: * America/New York: 9:00 AM (EST) * Europe/London: 2:00 PM (GMT) * Europe/Rome: 3:00 PM (CET) * Asia/Singapore: 10:00 PM (SGT) * Asia/Tokyo: 11:00 PM (JST) What makes it special? It’s super light, compact, and offers ultimate flexibility with vivid OLED colors, deep contrast, and plug-and-play compatibility for everything — gaming, work, and creative projects. 🎲 Board & Tabletop Games 🎮 Mobile & Console Gaming 🤝 Multiplayer & Party Games 📚 Book Mode & Work Modes 🆚 Head-to-Head & Versus Games If you’re curious, here’s the prelaunch page (no pressure at all — just wanted you to take a look): 👉Notify Me: Get Mine on Kickstarter ( http://tracking.nextech.shop/tracking/click?d=4AivePE4XMH7w6uFxD5qcyyWtLdIu… ) Those who follow early will get Free Shipping and $405 off.. ( http://tracking.nextech.shop/tracking/click?d=4AivePE4XMH7w6uFxD5qcyyWtLdIu… ) ( http://tracking.nextech.shop/tracking/click?d=4AivePE4XMH7w6uFxD5qcyyWtLdIu… ) Don't miss out and reserve yours now. ( http://tracking.nextech.shop/tracking/click?d=4AivePE4XMH7w6uFxD5qcyyWtLdIu… ) Can’t wait to see you on Kickstarter — your support means everything! Best, DUOONE Team

3 weeks, 1 day

1
0
0 0

[PATCH v2 RESEND] net/dccp: validate Reset/Close/CloseReq in DCCP_REQUESTING

by Yizhou Zhao

DCCP sockets in DCCP_REQUESTING state do not check the sequence number or acknowledgment number for incoming Reset, CloseReq, and Close packets. As a result, an attacker can send a spoofed Reset packet while the client is in the requesting state. The client will accept the packet without verification and immediately close the connection, causing a denial of service (DoS) attack. This patch moves the processing of Reset, Close, and CloseReq packets into dccp_rcv_request_sent_state_process() and validates the ack number before accepting them. This fix should apply to stable versions *only* in Linux 5.x and 6.x. Note that DCCP was removed in Linux 6.16, so this patch is only relevant for older versions. We tested it on Ubuntu 24.04 LTS (Linux 6.8) and it worked as expected. Signed-off-by: Yizhou Zhao <zhaoyz24(a)mails.tsinghua.edu.cn> Cc: stable(a)vger.kernel.org Signed-off-by: Yizhou Zhao <zhaoyz24(a)mails.tsinghua.edu.cn> --- net/dccp/input.c | 54 ++++++++++++++++++++++++++++-------------------- 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/net/dccp/input.c b/net/dccp/input.c index 2cbb757a8..0b1ffb044 100644 --- a/net/dccp/input.c +++ b/net/dccp/input.c @@ -397,21 +397,22 @@ static int dccp_rcv_request_sent_state_process(struct sock *sk, * / * Response processing continues in Step 10; Reset * processing continues in Step 9 * / */ + struct dccp_sock *dp = dccp_sk(sk); + + if (!between48(DCCP_SKB_CB(skb)->dccpd_ack_seq, + dp->dccps_awl, dp->dccps_awh)) { + dccp_pr_debug("invalid ackno: S.AWL=%llu, " + "P.ackno=%llu, S.AWH=%llu\n", + (unsigned long long)dp->dccps_awl, + (unsigned long long)DCCP_SKB_CB(skb)->dccpd_ack_seq, + (unsigned long long)dp->dccps_awh); + goto out_invalid_packet; + } + if (dh->dccph_type == DCCP_PKT_RESPONSE) { const struct inet_connection_sock *icsk = inet_csk(sk); - struct dccp_sock *dp = dccp_sk(sk); - long tstamp = dccp_timestamp(); - - if (!between48(DCCP_SKB_CB(skb)->dccpd_ack_seq, - dp->dccps_awl, dp->dccps_awh)) { - dccp_pr_debug("invalid ackno: S.AWL=%llu, " - "P.ackno=%llu, S.AWH=%llu\n", - (unsigned long long)dp->dccps_awl, - (unsigned long long)DCCP_SKB_CB(skb)->dccpd_ack_seq, - (unsigned long long)dp->dccps_awh); - goto out_invalid_packet; - } + long tstamp = dccp_timestamp(); /* * If option processing (Step 8) failed, return 1 here so that * dccp_v4_do_rcv() sends a Reset. The Reset code depends on @@ -496,6 +497,13 @@ static int dccp_rcv_request_sent_state_process(struct sock *sk, } dccp_send_ack(sk); return -1; + } else if (dh->dccph_type == DCCP_PKT_RESET) { + dccp_rcv_reset(sk, skb); + return 0; + } else if (dh->dccph_type == DCCP_PKT_CLOSEREQ) { + return dccp_rcv_closereq(sk, skb); + } else if (dh->dccph_type == DCCP_PKT_CLOSE) { + return dccp_rcv_close(sk, skb); } out_invalid_packet: @@ -658,17 +666,19 @@ int dccp_rcv_state_process(struct sock *sk, struct sk_buff *skb, * Set TIMEWAIT timer * Drop packet and return */ - if (dh->dccph_type == DCCP_PKT_RESET) { - dccp_rcv_reset(sk, skb); - return 0; - } else if (dh->dccph_type == DCCP_PKT_CLOSEREQ) { /* Step 13 */ - if (dccp_rcv_closereq(sk, skb)) - return 0; - goto discard; - } else if (dh->dccph_type == DCCP_PKT_CLOSE) { /* Step 14 */ - if (dccp_rcv_close(sk, skb)) + if (sk->sk_state != DCCP_REQUESTING) { + if (dh->dccph_type == DCCP_PKT_RESET) { + dccp_rcv_reset(sk, skb); return 0; - goto discard; + } else if (dh->dccph_type == DCCP_PKT_CLOSEREQ) { /* Step 13 */ + if (dccp_rcv_closereq(sk, skb)) + return 0; + goto discard; + } else if (dh->dccph_type == DCCP_PKT_CLOSE) { /* Step 14 */ + if (dccp_rcv_close(sk, skb)) + return 0; + goto discard; + } } switch (sk->sk_state) { -- 2.34.1

3 weeks, 1 day

2
3
0 0

[PATCH] arm64: dts: rockchip: Add devicetree for the X3568 v4

by Coia Prant

Specification: - SoC: RockChip RK3568 ARM64 (4 cores) - eMMC: 16-128 GB - RAM: 2-8 GB - Power: DC 12V 2A - Ethernet: 2x YT8521SC RGMII (10/100/1000 Mbps) - Wireless radio: 802.11b/g/n/ac/ax dual-band - LED: Power: AlwaysOn User: GPIO - Button: VOL+: SARADC/0 <35k µV> VOL-: SARADC/0 <450k µV> Power/Reset: PMIC RK809 - CAN CAN/1: 4-pin (PH 2.0) - PWM PWM/4: Backlight DSI/0 DSI/1 PWM/7: IR Receiver [may not install] - UART: UART/2: Debug TTL - 1500000 8N1 (1.25mm) UART/3: TTL (PH 2.0) UART/4: TTL (PH 2.0) UART/8: AP6275S Bluetooth UART/9: TTL (PH 2.0) - I2C: I2C/0: PMIC RK809 I2C/1: Touchscreen DSI/0 DSI/1 I2C/4: Camera I2C/5: RTC@51 PCF8563 - I2S: I2S/0: miniHDMI Sound I2S/1: RK809 Audio Codec I2S/3: AP6275S Bluetooth Sound - SDMMC: SDMMC/0: microSD (TF) slot SDMMC/2: AP6275S SDIO WiFi card - Camera: 1x CSI - Video: miniHDMI / DSI0 (MIPI/LVDS) / DSI1 (MIPI/EDP) - Audio: miniHDMI / MIC on-board / Speaker / SPDIF / 3.5mm Headphones / AP6275S Bluetooth - USB: USB 2.0 HOST x2 USB 2.0 HOST x3 (4-pin) USB 2.0 OTG x1 (shared with USB 3.0 OTG/HOST) [slot may not install] USB 3.0 HOST x1 USB 3.0 OTG/HOST x1 - SATA: 1x SATA 3.0 with Power/4-pin [slot may not install] - PCIe: 1x PCIe 3.0 x2 (x4 connecter) [clock/slot may not install] Link: - https://appletsapi.52solution.com/media/X3568V4%E5%BC%80%E5%8F%91%E6%9D%BF%… - https://blog.gov.cooking/archives/research-ninetripod-x3568-v4-and-flash.ht… Signed-off-by: Coia Prant <coiaprant(a)gmail.com> Tested-by: Coia Prant <coiaprant(a)gmail.com> --- arch/arm64/boot/dts/rockchip/Makefile | 11 + .../rockchip/rk3568-x3568-camera-demo.dtso | 82 ++ .../boot/dts/rockchip/rk3568-x3568-v4.dts | 884 ++++++++++++++++++ .../dts/rockchip/rk3568-x3568-video-demo.dtso | 141 +++ 4 files changed, 1118 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-x3568-camera-demo.dtso create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-x3568-v4.dts create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-x3568-video-demo.dtso diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile index ad684e383..ea36334bb 100644 --- a/arch/arm64/boot/dts/rockchip/Makefile +++ b/arch/arm64/boot/dts/rockchip/Makefile @@ -150,6 +150,9 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-rock-3b.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-display-vz.dtbo dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-wolfvision-pf5-io-expander.dtbo +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-x3568-v4.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-x3568-camera-demo.dtso +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-x3568-video-demo.dtso dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtbo dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-evb1-v10.dtb @@ -252,6 +255,14 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-armsom-sige5-v1.2-wifibt.dtb rk3576-armsom-sige5-v1.2-wifibt-dtbs := rk3576-armsom-sige5.dtb \ rk3576-armsom-sige5-v1.2-wifibt.dtbo +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-x3568-v4-camera-demo.dtb +rk3568-x3568-v4-camera-demo-dtbs := rk3568-x3568-v4.dtb \ + rk3568-x3568-camera-demo.dtso + +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-x3568-v4-video-demo.dtb +rk3568-x3568-v4-video-demo-dtbs := rk3568-x3568-v4.dtb \ + rk3568-x3568-video-demo.dtso + dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-edgeble-neu6a-wifi.dtb rk3588-edgeble-neu6a-wifi-dtbs := rk3588-edgeble-neu6a-io.dtb \ rk3588-edgeble-neu6a-wifi.dtbo diff --git a/arch/arm64/boot/dts/rockchip/rk3568-x3568-camera-demo.dtso b/arch/arm64/boot/dts/rockchip/rk3568-x3568-camera-demo.dtso new file mode 100644 index 000000000..b144d0010 --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3568-x3568-camera-demo.dtso @@ -0,0 +1,82 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT) + +// This is a sample reference, due to lack of hardware can not be tested, at your own risk + +/dts-v1/; +/plugin/; + +#include <dt-bindings/clock/rk3568-cru.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/pinctrl/rockchip.h> + +&{/} { + vcc_cam: regulator-vcc-cam { + compatible = "regulator-fixed"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + enable-active-high; + gpio = <&gpio0 RK_PC1 GPIO_ACTIVE_HIGH>; + regulator-name = "vcc_cam"; + vin-supply = <&vcc3v3_sys>; + pinctrl-names = "default"; + pinctrl-0 = <&vcc_cam_en>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; +}; + +&pinctrl { + cam { + vcc_cam_en: vcc_cam_en { + rockchip,pins = <0 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; +}; + +&csi_dphy { + status = "okay"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + mipi_in_ucam: endpoint@2 { + reg = <2>; + remote-endpoint = <&ucam_out>; + data-lanes = <1 2 3 4>; + }; + }; + }; +}; + +&i2c4 { + status = "okay"; + + camera@37 { + compatible = "ovti,ov5695"; + reg = <0x37>; + clocks = <&cru CLK_CIF_OUT>; + clock-names = "xvclk"; + avdd-supply = <&vcc_cam>; + dvdd-supply = <&vcc_cam>; + dovdd-supply = <&vcc_cam>; + pinctrl-names = "default"; + pinctrl-0 = <&cif_clk>; + reset-gpios = <&gpio3 RK_PB6 GPIO_ACTIVE_LOW>; + pwdn-gpios = <&gpio4 RK_PB4 GPIO_ACTIVE_LOW>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1 2 3 4>; + }; + }; + }; +}; diff --git a/arch/arm64/boot/dts/rockchip/rk3568-x3568-v4.dts b/arch/arm64/boot/dts/rockchip/rk3568-x3568-v4.dts new file mode 100644 index 000000000..901735c6f --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3568-x3568-v4.dts @@ -0,0 +1,884 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +/dts-v1/; +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/input/input.h> +#include <dt-bindings/leds/common.h> +#include <dt-bindings/pinctrl/rockchip.h> +#include <dt-bindings/soc/rockchip,vop2.h> +#include "rk3568.dtsi" + +/ { + model = "NineTripod X3568 v4"; + compatible = "ninetripod,x3568-v4", "rockchip,rk3568"; + + aliases { + ethernet0 = &gmac0; + ethernet1 = &gmac1; + mmc0 = &sdhci; + mmc1 = &sdmmc0; + mmc2 = &sdmmc2; + }; + + chosen { + stdout-path = "serial2:1500000n8"; + }; + + adc-keys { + compatible = "adc-keys"; + io-channels = <&saradc 0>; + io-channel-names = "buttons"; + keyup-threshold-microvolt = <1800000>; + poll-interval = <100>; + + button-vol-up { + label = "volume up"; + linux,code = <KEY_VOLUMEUP>; + press-threshold-microvolt = <50000>; + }; + + button-vol-down { + label = "volume down"; + linux,code = <KEY_VOLUMEDOWN>; + press-threshold-microvolt = <500000>; + }; + }; + + hdmi-con { + compatible = "hdmi-connector"; + type = "a"; + + port { + hdmi_con_in: endpoint { + remote-endpoint = <&hdmi_out_con>; + }; + }; + }; + + leds { + compatible = "gpio-leds"; + + led_work: led-0 { + gpios = <&gpio0 RK_PC0 GPIO_ACTIVE_HIGH>; + function = LED_FUNCTION_HEARTBEAT; + color = <LED_COLOR_ID_BLUE>; + linux,default-trigger = "heartbeat"; + pinctrl-names = "default"; + pinctrl-0 = <&led_work_en>; + }; + }; + + rk809-sound { + compatible = "simple-audio-card"; + simple-audio-card,format = "i2s"; + simple-audio-card,name = "Analog RK809"; + simple-audio-card,mclk-fs = <256>; + + simple-audio-card,cpu { + sound-dai = <&i2s1_8ch>; + }; + simple-audio-card,codec { + sound-dai = <&rk809>; + }; + }; + + pdm_codec: pdm-codec { + compatible = "dmic-codec"; + num-channels = <2>; + #sound-dai-cells = <0>; + }; + + pdm_sound: pdm-sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "microphone"; + + simple-audio-card,cpu { + sound-dai = <&pdm>; + }; + + simple-audio-card,codec { + sound-dai = <&pdm_codec>; + }; + }; + + spdif_dit: spdif-dit { + compatible = "linux,spdif-dit"; + #sound-dai-cells = <0>; + }; + + spdif_sound: spdif-sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "SPDIF"; + + simple-audio-card,cpu { + sound-dai = <&spdif>; + }; + simple-audio-card,codec { + sound-dai = <&spdif_dit>; + }; + }; + + sdio_pwrseq: sdio-pwrseq { + compatible = "mmc-pwrseq-simple"; + clocks = <&rk809 1>; + clock-names = "ext_clock"; + pinctrl-names = "default"; + pinctrl-0 = <&wifi_enable>; + post-power-on-delay-ms = <100>; + power-off-delay-us = <300>; + reset-gpios = <&gpio3 RK_PD5 GPIO_ACTIVE_LOW>; + }; + + dc_12v: regulator-dc-12v { + compatible = "regulator-fixed"; + regulator-name = "dc_12v"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <12000000>; + regulator-max-microvolt = <12000000>; + }; + + pcie30_avdd0v9: regulator-pcie30-avdd0v9 { + compatible = "regulator-fixed"; + regulator-name = "pcie30_avdd0v9"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + vin-supply = <&vcc3v3_sys>; + }; + + pcie30_avdd1v8: regulator-pcie30-avdd1v8 { + compatible = "regulator-fixed"; + regulator-name = "pcie30_avdd1v8"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + vin-supply = <&vcc3v3_sys>; + }; + + vcc3v3_sys: regulator-vcc3v3-sys { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + vin-supply = <&dc_12v>; + }; + + vcc3v3_pcie: regulator-vcc3v3-pcie { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_pcie"; + enable-active-high; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + pinctrl-names = "default"; + pinctrl-0 = <&vcc3v3_pcie_en_pin>; + gpio = <&gpio0 RK_PD4 GPIO_ACTIVE_HIGH>; + startup-delay-us = <5000>; + vin-supply = <&vcc5v0_sys>; + }; + + vcc5v0_sys: regulator-vcc5v0-sys { + compatible = "regulator-fixed"; + regulator-name = "vcc5v0_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&dc_12v>; + }; + + vcc5v0_usb: regulator-vcc5v0-usb { + compatible = "regulator-fixed"; + regulator-name = "vcc5v0_usb"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&dc_12v>; + }; + + vcc5v0_usb_host: regulator-vcc5v0-usb-host { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&vcc5v0_usb_host_en>; + regulator-name = "vcc5v0_usb_host"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&vcc5v0_usb>; + }; + + vcc5v0_usb_otg: regulator-vcc5v0-usb-otg { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&vcc5v0_usb_otg_en>; + regulator-name = "vcc5v0_usb_otg"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + vin-supply = <&vcc5v0_usb>; + }; +}; + +&can1 { + assigned-clocks = <&cru CLK_CAN1>; + assigned-clock-rates = <150000000>; + pinctrl-names = "default"; + pinctrl-0 = <&can1m1_pins>; + status = "okay"; +}; + +/* used for usb_host0_xhci */ +&combphy0 { + status = "okay"; +}; + +/* used for usb_host1_xhci */ +&combphy1 { + status = "okay"; +}; + +/* connected to sata2 */ +&combphy2 { + status = "okay"; +}; + +&cpu0 { + cpu-supply = <&vdd_cpu>; +}; + +&cpu1 { + cpu-supply = <&vdd_cpu>; +}; + +&cpu2 { + cpu-supply = <&vdd_cpu>; +}; + +&cpu3 { + cpu-supply = <&vdd_cpu>; +}; + +&gmac0 { + assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>; + assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>; + assigned-clock-rates = <0>, <125000000>; + clock_in_out = "output"; + pinctrl-names = "default"; + pinctrl-0 = <&gmac0_miim + &gmac0_tx_bus2 + &gmac0_rx_bus2 + &gmac0_rgmii_clk + &gmac0_rgmii_bus + &gmac0_clkinout>; + phy-handle = <&rgmii_phy0>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + +&gmac1 { + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>; + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>; + assigned-clock-rates = <0>, <125000000>; + clock_in_out = "output"; + pinctrl-names = "default"; + pinctrl-0 = <&gmac1m1_miim + &gmac1m1_tx_bus2 + &gmac1m1_rx_bus2 + &gmac1m1_rgmii_clk + &gmac1m1_rgmii_bus + &gmac1m1_clkinout>; + phy-handle = <&rgmii_phy1>; + phy-mode = "rgmii-id"; + status = "okay"; +}; + +&gpu { + mali-supply = <&vdd_gpu>; + status = "okay"; +}; + +&hdmi { + avdd-0v9-supply = <&vdda0v9_image>; + avdd-1v8-supply = <&vcca1v8_image>; + status = "okay"; +}; + +&hdmi_in { + hdmi_in_vp0: endpoint { + remote-endpoint = <&vp0_out_hdmi>; + }; +}; + +&hdmi_out { + hdmi_out_con: endpoint { + remote-endpoint = <&hdmi_con_in>; + }; +}; + +&hdmi_sound { + status = "okay"; +}; + +&i2c0 { + status = "okay"; + + vdd_cpu: regulator@1c { + compatible = "tcs,tcs4525"; + reg = <0x1c>; + fcs,suspend-voltage-selector = <1>; + regulator-name = "vdd_cpu"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1150000>; + regulator-ramp-delay = <2300>; + vin-supply = <&vcc5v0_sys>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + rk809: pmic@20 { + compatible = "rockchip,rk809"; + reg = <0x20>; + interrupt-parent = <&gpio0>; + interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>; + assigned-clocks = <&cru I2S1_MCLKOUT_TX>; + assigned-clock-parents = <&cru CLK_I2S1_8CH_TX>; + #clock-cells = <1>; + clock-names = "mclk"; + clocks = <&cru I2S1_MCLKOUT_TX>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int>, <&i2s1m0_mclk>; + system-power-controller; + #sound-dai-cells = <0>; + vcc1-supply = <&vcc3v3_sys>; + vcc2-supply = <&vcc3v3_sys>; + vcc3-supply = <&vcc3v3_sys>; + vcc4-supply = <&vcc3v3_sys>; + vcc5-supply = <&vcc3v3_sys>; + vcc6-supply = <&vcc3v3_sys>; + vcc7-supply = <&vcc3v3_sys>; + vcc8-supply = <&vcc3v3_sys>; + vcc9-supply = <&vcc3v3_sys>; + wakeup-source; + + regulators { + vdd_logic: DCDC_REG1 { + regulator-name = "vdd_logic"; + regulator-always-on; + regulator-boot-on; + regulator-initial-mode = <0x2>; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_gpu: DCDC_REG2 { + regulator-name = "vdd_gpu"; + regulator-always-on; + regulator-initial-mode = <0x2>; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + regulator-initial-mode = <0x2>; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vdd_npu: DCDC_REG4 { + regulator-name = "vdd_npu"; + regulator-initial-mode = <0x2>; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_1v8: DCDC_REG5 { + regulator-name = "vcc_1v8"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdda0v9_image: LDO_REG1 { + regulator-name = "vdda0v9_image"; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdda_0v9: LDO_REG2 { + regulator-name = "vdda_0v9"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdda0v9_pmu: LDO_REG3 { + regulator-name = "vdda0v9_pmu"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <900000>; + }; + }; + + vccio_acodec: LDO_REG4 { + regulator-name = "vccio_acodec"; + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vccio_sd: LDO_REG5 { + regulator-name = "vccio_sd"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc3v3_pmu: LDO_REG6 { + regulator-name = "vcc3v3_pmu"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcca_1v8: LDO_REG7 { + regulator-name = "vcca_1v8"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcca1v8_pmu: LDO_REG8 { + regulator-name = "vcca1v8_pmu"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vcca1v8_image: LDO_REG9 { + regulator-name = "vcca1v8_image"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_3v3: SWITCH_REG1 { + regulator-name = "vcc_3v3"; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc3v3_sd: SWITCH_REG2 { + regulator-name = "vcc3v3_sd"; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + }; + + codec { + rockchip,mic-in-differential; + }; + }; +}; + +&i2c5 { + status = "okay"; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + #clock-cells = <0>; + }; +}; + +&i2s0_8ch { + status = "okay"; +}; + +&i2s1_8ch { + pinctrl-0 = <&i2s1m0_sclktx &i2s1m0_lrcktx &i2s1m0_sdi0 &i2s1m0_sdo0>; + rockchip,trcm-sync-tx-only; + status = "okay"; +}; + +/* used for AP6275S Bluetooth Sound */ +&i2s3_2ch { + status = "okay"; +}; + +&mdio0 { + rgmii_phy0: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0x0>; + reset-assert-us = <20000>; + reset-deassert-us = <100000>; + reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_AMBER>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + }; + }; +}; + +&mdio1 { + rgmii_phy1: ethernet-phy@0 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <0x0>; + reset-assert-us = <20000>; + reset-deassert-us = <100000>; + reset-gpios = <&gpio2 RK_PD1 GPIO_ACTIVE_LOW>; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_AMBER>; + function = LED_FUNCTION_LAN; + default-state = "keep"; + }; + }; + }; +}; + +&pcie30phy { + status = "okay"; +}; + +&pcie3x2 { + pinctrl-names = "default"; + pinctrl-0 = <&pcie_reset_pin>; + reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>; + vpcie3v3-supply = <&vcc3v3_pcie>; + status = "okay"; +}; + +&pdm { + status = "okay"; +}; + +&pinctrl { + leds { + led_work_en: led_work_en { + rockchip,pins = <0 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + pmic { + pmic_int: pmic_int { + rockchip,pins = + <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>; + }; + }; + + sdio-pwrseq { + wifi_enable: wifi-enable { + rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + usb { + vcc5v0_usb_host_en: vcc5v0_usb_host_en { + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>; + }; + vcc5v0_usb_otg_en: vcc5v0_usb_otg_en { + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; + + pcie { + pcie_reset_pin: pcie-reset-pin { + rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>; + }; + vcc3v3_pcie_en_pin: vcc3v3-pcie-en-pin { + rockchip,pins = <0 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; +}; + +&pmu_io_domains { + pmuio1-supply = <&vcc3v3_pmu>; + pmuio2-supply = <&vcc3v3_pmu>; + vccio1-supply = <&vccio_acodec>; + vccio2-supply = <&vcc_1v8>; + vccio3-supply = <&vccio_sd>; + vccio4-supply = <&vcc_1v8>; + vccio5-supply = <&vcc_3v3>; + vccio6-supply = <&vcc_1v8>; + vccio7-supply = <&vcc_3v3>; + status = "okay"; +}; + +&pwm4 { + status = "okay"; +}; + +/* Required remotectl for IR receiver */ +&pwm7 { + status = "disabled"; +}; + +&saradc { + vref-supply = <&vcca_1v8>; + status = "okay"; +}; + +&sata2 { + status = "okay"; +}; + +/* used for eMMC */ +&sdhci { + bus-width = <8>; + max-frequency = <200000000>; + mmc-hs200-1_8v; + non-removable; + pinctrl-names = "default"; + pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>; + status = "okay"; +}; + +/* used for microSD (TF) Slot */ +&sdmmc0 { + bus-width = <4>; + cap-sd-highspeed; + cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>; + disable-wp; + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>; + sd-uhs-sdr104; + vmmc-supply = <&vcc3v3_sd>; + vqmmc-supply = <&vccio_sd>; + status = "okay"; +}; + +/* used for AP6275S WiFi */ +&sdmmc2 { + bus-width = <4>; + disable-wp; + cap-sd-highspeed; + cap-sdio-irq; + keep-power-in-suspend; + mmc-pwrseq = <&sdio_pwrseq>; + non-removable; + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc2m0_bus4 &sdmmc2m0_cmd &sdmmc2m0_clk>; + sd-uhs-sdr12; + sd-uhs-sdr25; + sd-uhs-sdr50; + sd-uhs-sdr104; + vmmc-supply = <&vcc3v3_sys>; + vqmmc-supply = <&vcc_1v8>; + status = "okay"; +}; + +&spdif { + status = "okay"; +}; + +&tsadc { + rockchip,hw-tshut-mode = <1>; + rockchip,hw-tshut-polarity = <0>; + status = "okay"; +}; + +/* used for Debug */ +&uart2 { + status = "okay"; +}; + +&uart3 { + pinctrl-0 = <&uart3m1_xfer>; + status = "okay"; +}; + +&uart4 { + pinctrl-0 = <&uart4m1_xfer>; + status = "okay"; +}; + +/* used for WiFi/BT AP6275S */ +&uart8 { + pinctrl-0 = <&uart8m0_xfer &uart8m0_ctsn>; + status = "okay"; +}; + +&uart9 { + pinctrl-0 = <&uart9m1_xfer>; + status = "okay"; +}; + +&usb_host0_ehci { + status = "okay"; +}; + +&usb_host0_ohci { + status = "okay"; +}; + +&usb_host0_xhci { + extcon = <&usb2phy0>; + status = "okay"; +}; + +&usb_host1_ehci { + status = "okay"; +}; + +&usb_host1_ohci { + status = "okay"; +}; + +&usb_host1_xhci { + status = "okay"; +}; + +&usb2phy0 { + status = "okay"; +}; + +&usb2phy0_host { + phy-supply = <&vcc5v0_usb_host>; + status = "okay"; +}; + +&usb2phy0_otg { + phy-supply = <&vcc5v0_usb_otg>; + status = "okay"; +}; + +&usb2phy1 { + status = "okay"; +}; + +&usb2phy1_host { + phy-supply = <&vcc5v0_usb_host>; + status = "okay"; +}; + +&usb2phy1_otg { + phy-supply = <&vcc5v0_usb_host>; + status = "okay"; +}; + +&vop { + assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>; + assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>; + status = "okay"; +}; + +&vop_mmu { + status = "okay"; +}; + +&vp0 { + vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 { + reg = <ROCKCHIP_VOP2_EP_HDMI0>; + remote-endpoint = <&hdmi_in_vp0>; + }; +}; diff --git a/arch/arm64/boot/dts/rockchip/rk3568-x3568-video-demo.dtso b/arch/arm64/boot/dts/rockchip/rk3568-x3568-video-demo.dtso new file mode 100644 index 000000000..f819eff8f --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3568-x3568-video-demo.dtso @@ -0,0 +1,141 @@ +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT) + +// This is a sample reference, due to lack of hardware can not be tested, at your own risk + +/dts-v1/; +/plugin/; + +#include <dt-bindings/clock/rk3568-cru.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/pinctrl/rockchip.h> + +&{/} { + backlight: backlight { + compatible = "pwm-backlight"; + brightness-levels = <20 220>; + default-brightness-level = <100>; + num-interpolated-steps = <200>; + power-supply = <&vcc3v3_sys>; + pwms = <&pwm4 0 25000 0>; + }; + + vcc3v3_lcd0_n: regulator-vcc3v3-lcd0-n { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_lcd0_n"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + enable-active-high; + gpio = <&gpio0 RK_PC7 GPIO_ACTIVE_HIGH>; + vin-supply = <&vcc3v3_sys>; + pinctrl-names = "default"; + pinctrl-0 = <&vcc3v3_lcd0_n_en>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc3v3_lcd1_n: regulator-vcc3v3-lcd1-n { + compatible = "regulator-fixed"; + regulator-name = "vcc3v3_lcd1_n"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + enable-active-high; + gpio = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>; + vin-supply = <&vcc3v3_sys>; + pinctrl-names = "default"; + pinctrl-0 = <&vcc3v3_lcd1_n_en>; + + regulator-state-mem { + regulator-off-in-suspend; + }; + }; +}; + +&pinctrl { + display { + vcc3v3_lcd0_n_en: vcc3v3_lcd0_n_en { + rockchip,pins = <0 RK_PC7 0 &pcfg_pull_none>; + }; + vcc3v3_lcd1_n_en: vcc3v3_lcd1_n_en { + rockchip,pins = <0 RK_PC5 0 &pcfg_pull_none>; + }; + }; + + touchscreen { + touch_int: touch_int { + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up>; + }; + touch_rst: touch_rst { + rockchip,pins = <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; +}; + +&dsi0 { + clock-master; + #address-cells = <1>; + #size-cells = <0>; + status = "okay"; + + panel@0 { + compatible = "wanchanglong,w552793baa", "raydium,rm67200"; + reg = <0>; + backlight = <&backlight>; + iovcc-supply = <&vcc3v3_lcd0_n>; + reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>; + vdd-supply = <&vcc3v3_lcd0_n>; + vsn-supply = <&vcc5v0_sys>; + vsp-supply = <&vcc5v0_sys>; + + port { + panel_in_dsi: endpoint { + remote-endpoint = <&dsi0_out_panel>; + }; + }; + }; +}; + +&dsi0_in { + dsi0_in_vp1: endpoint { + remote-endpoint = <&vp1_out_dsi0>; + }; +}; + +&dsi0_out { + dsi0_out_panel: endpoint { + remote-endpoint = <&panel_in_dsi>; + }; +}; + +&dsi_dphy0 { + status = "okay"; +}; + +&pwm4 { + status = "okay"; +}; + +&i2c1 { + status = "okay"; + + touchscreen0: goodix@14 { + compatible = "goodix,gt1151"; + reg = <0x14>; + interrupt-parent = <&gpio0>; + interrupts = <RK_PB5 IRQ_TYPE_EDGE_FALLING>; + AVDD28-supply = <&vcc3v3_lcd0_n>; + irq-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&touch_int &touch_rst>; + reset-gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_LOW>; + VDDIO-supply = <&vcc3v3_lcd0_n>; + }; +}; + +&vp1 { + vp1_out_dsi0: endpoint@ROCKCHIP_VOP2_EP_MIPI0 { + reg = <ROCKCHIP_VOP2_EP_MIPI0>; + remote-endpoint = <&dsi0_in_vp1>; + }; +}; -- 2.47.3

3 weeks, 1 day

3
3
0 0

[PATCH v2 1/3] dt-bindings: vendor-prefixes: Add NineTripod

by Coia Prant

Add NineTripod to the vendor prefixes. Signed-off-by: Coia Prant <coiaprant(a)gmail.com> Cc: stable(a)vger.kernel.org --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index f1d188200..37687737e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1124,6 +1124,8 @@ patternProperties: description: National Instruments "^nicera,.*": description: Nippon Ceramic Co., Ltd. + "^ninetripod,.*": + description: Shenzhen 9Tripod Innovation and Development CO., LTD. "^nintendo,.*": description: Nintendo "^nlt,.*": -- 2.47.3

3 weeks, 1 day

2
5
0 0

+ fs-proc-fix-uaf-in-proc_readdir_de.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: fs/proc: fix uaf in proc_readdir_de() has been added to the -mm mm-hotfixes-unstable branch. Its filename is fs-proc-fix-uaf-in-proc_readdir_de.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Wei Yang <albinwyang(a)tencent.com> Subject: fs/proc: fix uaf in proc_readdir_de() Date: Sat, 25 Oct 2025 10:42:33 +0800 Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access. We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows: 1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3; 2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab; 3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access. CPU 0 | CPU 1 ---------------------------------------------------------------------------------------------- traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF | rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2) Link: https://lkml.kernel.org/r/20251025024233.158363-1-albin_yang@163.com Signed-off-by: Wei Yang <albinwyang(a)tencent.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: Christian Brauner <brauner(a)kernel.org> Cc: wangzijie <wangzijie1(a)honor.com> Cc: Alexey Dobriyan <adobriyan(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/generic.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/fs/proc/generic.c~fs-proc-fix-uaf-in-proc_readdir_de +++ a/fs/proc/generic.c @@ -698,6 +698,12 @@ void pde_put(struct proc_dir_entry *pde) } } +static void pde_erase(struct proc_dir_entry *pde, struct proc_dir_entry *parent) +{ + rb_erase(&pde->subdir_node, &parent->subdir); + RB_CLEAR_NODE(&pde->subdir_node); +} + /* * Remove a /proc entry and free it if it's not currently in use. */ @@ -720,7 +726,7 @@ void remove_proc_entry(const char *name, WARN(1, "removing permanent /proc entry '%s'", de->name); de = NULL; } else { - rb_erase(&de->subdir_node, &parent->subdir); + pde_erase(de, parent); if (S_ISDIR(de->mode)) parent->nlink--; } @@ -764,7 +770,7 @@ int remove_proc_subtree(const char *name root->parent->name, root->name); return -EINVAL; } - rb_erase(&root->subdir_node, &parent->subdir); + pde_erase(root, parent); de = root; while (1) { @@ -776,7 +782,7 @@ int remove_proc_subtree(const char *name next->parent->name, next->name); return -EINVAL; } - rb_erase(&next->subdir_node, &de->subdir); + pde_erase(next, de); de = next; continue; } _ Patches currently in -mm which might be from albinwyang(a)tencent.com are fs-proc-fix-uaf-in-proc_readdir_de.patch

3 weeks, 2 days

1
0
0 0

[PATCH v2 fs/btrfs v2] btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation

by Shardul Bankar

When btrfs_add_qgroup_relation() is called with invalid qgroup levels (src >= dst), the function returns -EINVAL directly without freeing the preallocated qgroup_list structure passed by the caller. This causes a memory leak because the caller unconditionally sets the pointer to NULL after the call, preventing any cleanup. The issue occurs because the level validation check happens before the mutex is acquired and before any error handling path that would free the prealloc pointer. On this early return, the cleanup code at the 'out' label (which includes kfree(prealloc)) is never reached. In btrfs_ioctl_qgroup_assign(), the code pattern is: prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL); ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc); prealloc = NULL; // Always set to NULL regardless of return value ... kfree(prealloc); // This becomes kfree(NULL), does nothing When the level check fails, 'prealloc' is never freed by either the callee or the caller, resulting in a 64-byte memory leak per failed operation. This can be triggered repeatedly by an unprivileged user with access to a writable btrfs mount, potentially exhausting kernel memory. Fix this by freeing prealloc before the early return, ensuring prealloc is always freed on all error paths. Fixes: 8465ecec9611 ("btrfs: Check qgroup level in kernel qgroup assign.") Cc: stable(a)vger.kernel.org # v4.0+ Signed-off-by: Shardul Bankar <shardulsb08(a)gmail.com> --- v2: - Free prealloc directly before returning -EINVAL (no mutex held), per review from Qu Wenruo. - Drop goto-based cleanup. fs/btrfs/qgroup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index 1175b8192cd7..31ad8580322a 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1539,8 +1539,10 @@ int btrfs_add_qgroup_relation(struct btrfs_trans_handle *trans, u64 src, u64 dst ASSERT(prealloc); /* Check the level of src and dst first */ - if (btrfs_qgroup_level(src) >= btrfs_qgroup_level(dst)) + if (btrfs_qgroup_level(src) >= btrfs_qgroup_level(dst)) { + kfree(prealloc); return -EINVAL; + } mutex_lock(&fs_info->qgroup_ioctl_lock); if (!fs_info->quota_root) { -- 2.34.1

3 weeks, 2 days

2
1
0 0

+ mm-huge_memory-preserve-pg_has_hwpoisoned-if-a-folio-is-split-to-0-order.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-huge_memory-preserve-pg_has_hwpoisoned-if-a-folio-is-split-to-0-order.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Zi Yan <ziy(a)nvidia.com> Subject: mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order Date: Wed, 22 Oct 2025 23:05:21 -0400 folio split clears PG_has_hwpoisoned, but the flag should be preserved in after-split folios containing pages with PG_hwpoisoned flag if the folio is split to >0 order folios. Scan all pages in a to-be-split folio to determine which after-split folios need the flag. An alternatives is to change PG_has_hwpoisoned to PG_maybe_hwpoisoned to avoid the scan and set it on all after-split folios, but resulting false positive has undesirable negative impact. To remove false positive, caller of folio_test_has_hwpoisoned() and folio_contain_hwpoisoned_page() needs to do the scan. That might be causing a hassle for current and future callers and more costly than doing the scan in the split code. More details are discussed in [1]. This issue can be exposed via: 1. splitting a has_hwpoisoned folio to >0 order from debugfs interface; 2. truncating part of a has_hwpoisoned folio in truncate_inode_partial_folio(). And later accesses to a hwpoisoned page could be possible due to the missing has_hwpoisoned folio flag. This will lead to MCE errors. Link: https://lore.kernel.org/all/CAHbLzkoOZm0PXxE9qwtF4gKR=cpRXrSrJ9V9Pm2DJexs98… [1] Link: https://lkml.kernel.org/r/20251023030521.473097-1-ziy@nvidia.com Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Zi Yan <ziy(a)nvidia.com> Acked-by: David Hildenbrand <david(a)redhat.com> Cc: Pankaj Raghav <kernel(a)pankajraghav.com> Reviewed-by: Yang Shi <yang(a)os.amperecomputing.com> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Barry Song <baohua(a)kernel.org> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Jane Chu <jane.chu(a)oracle.com> Cc: Lance Yang <lance.yang(a)linux.dev> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Luis Chamberalin <mcgrof(a)kernel.org> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Naoya Horiguchi <nao.horiguchi(a)gmail.com> Cc: Nico Pache <npache(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Wei Yang <richard.weiyang(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) --- a/mm/huge_memory.c~mm-huge_memory-preserve-pg_has_hwpoisoned-if-a-folio-is-split-to-0-order +++ a/mm/huge_memory.c @@ -3263,6 +3263,14 @@ bool can_split_folio(struct folio *folio caller_pins; } +static bool page_range_has_hwpoisoned(struct page *page, long nr_pages) +{ + for (; nr_pages; page++, nr_pages--) + if (PageHWPoison(page)) + return true; + return false; +} + /* * It splits @folio into @new_order folios and copies the @folio metadata to * all the resulting folios. @@ -3270,17 +3278,24 @@ bool can_split_folio(struct folio *folio static void __split_folio_to_order(struct folio *folio, int old_order, int new_order) { + /* Scan poisoned pages when split a poisoned folio to large folios */ + const bool handle_hwpoison = folio_test_has_hwpoisoned(folio) && new_order; long new_nr_pages = 1 << new_order; long nr_pages = 1 << old_order; long i; + folio_clear_has_hwpoisoned(folio); + + /* Check first new_nr_pages since the loop below skips them */ + if (handle_hwpoison && + page_range_has_hwpoisoned(folio_page(folio, 0), new_nr_pages)) + folio_set_has_hwpoisoned(folio); /* * Skip the first new_nr_pages, since the new folio from them have all * the flags from the original folio. */ for (i = new_nr_pages; i < nr_pages; i += new_nr_pages) { struct page *new_head = &folio->page + i; - /* * Careful: new_folio is not a "real" folio before we cleared PageTail. * Don't pass it around before clear_compound_head(). @@ -3322,6 +3337,10 @@ static void __split_folio_to_order(struc (1L << PG_dirty) | LRU_GEN_MASK | LRU_REFS_MASK)); + if (handle_hwpoison && + page_range_has_hwpoisoned(new_head, new_nr_pages)) + folio_set_has_hwpoisoned(new_folio); + new_folio->mapping = folio->mapping; new_folio->index = folio->index + i; @@ -3422,8 +3441,6 @@ static int __split_unmapped_folio(struct if (folio_test_anon(folio)) mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1); - folio_clear_has_hwpoisoned(folio); - /* * split to new_order one order at a time. For uniform split, * folio is split to new_order directly. _ Patches currently in -mm which might be from ziy(a)nvidia.com are mm-huge_memory-do-not-change-split_huge_page-target-order-silently.patch mm-huge_memory-preserve-pg_has_hwpoisoned-if-a-folio-is-split-to-0-order.patch

3 weeks, 2 days

3
2
0 0

[PATCH V2] LoongArch: Align ACPI structures if ARCH_STRICT_ALIGN enabled

by Huacai Chen

ARCH_STRICT_ALIGN is used for hardware without UAL, now it only control the -mstrict-align flag. However, ACPI structures are packed by default so will cause unaligned accesses. To avoid this, define ACPI_MISALIGNMENT_NOT_SUPPORTED in asm/acenv.h to align ACPI structures if ARCH_STRICT_ALIGN enabled. Cc: stable(a)vger.kernel.org Reported-by: Binbin Zhou <zhoubinbin(a)loongson.cn> Suggested-by: Xi Ruoyao <xry111(a)xry111.site> Suggested-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> Signed-off-by: Huacai Chen <chenhuacai(a)loongson.cn> --- V2: Modify asm/acenv.h instead of Makefile. arch/loongarch/include/asm/acenv.h | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/loongarch/include/asm/acenv.h b/arch/loongarch/include/asm/acenv.h index 52f298f7293b..483c955f2ae5 100644 --- a/arch/loongarch/include/asm/acenv.h +++ b/arch/loongarch/include/asm/acenv.h @@ -10,9 +10,8 @@ #ifndef _ASM_LOONGARCH_ACENV_H #define _ASM_LOONGARCH_ACENV_H -/* - * This header is required by ACPI core, but we have nothing to fill in - * right now. Will be updated later when needed. - */ +#ifdef CONFIG_ARCH_STRICT_ALIGN +#define ACPI_MISALIGNMENT_NOT_SUPPORTED +#endif /* CONFIG_ARCH_STRICT_ALIGN */ #endif /* _ASM_LOONGARCH_ACENV_H */ -- 2.47.3

3 weeks, 2 days

6
8
0 0

[PATCH] leds: leds-lp50xx: enable chip before any communication

by Christian Hitz

From: Christian Hitz <christian.hitz(a)bbv.ch> If a GPIO is used to control the chip's enable pin, it needs to be pulled high before any SPI communication is attempted. Split lp50xx_enable_disable() into two distinct functions to enforce correct ordering. Observe correct timing after manipulating the enable GPIO and SPI communication. Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Signed-off-by: Christian Hitz <christian.hitz(a)bbv.ch> Cc: stable(a)vger.kernel.org --- drivers/leds/leds-lp50xx.c | 51 +++++++++++++++++++++++++++----------- 1 file changed, 36 insertions(+), 15 deletions(-) diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c index d19b6a459151..f23e9ae434e4 100644 --- a/drivers/leds/leds-lp50xx.c +++ b/drivers/leds/leds-lp50xx.c @@ -52,6 +52,8 @@ #define LP50XX_SW_RESET 0xff #define LP50XX_CHIP_EN BIT(6) +#define LP50XX_START_TIME_US 500 +#define LP50XX_RESET_TIME_US 3 /* There are 3 LED outputs per bank */ #define LP50XX_LEDS_PER_MODULE 3 @@ -374,19 +376,42 @@ static int lp50xx_reset(struct lp50xx *priv) return regmap_write(priv->regmap, priv->chip_info->reset_reg, LP50XX_SW_RESET); } -static int lp50xx_enable_disable(struct lp50xx *priv, int enable_disable) +static int lp50xx_enable(struct lp50xx *priv) { int ret; - ret = gpiod_direction_output(priv->enable_gpio, enable_disable); + if (priv->enable_gpio) { + ret = gpiod_direction_output(priv->enable_gpio, 1); + if (ret) + return ret; + + udelay(LP50XX_START_TIME_US); + } else { + ret = lp50xx_reset(priv); + if (ret) + return ret; + } + + return regmap_write(priv->regmap, LP50XX_DEV_CFG0, LP50XX_CHIP_EN); +} + +static int lp50xx_disable(struct lp50xx *priv) +{ + int ret; + + ret = regmap_write(priv->regmap, LP50XX_DEV_CFG0, 0); if (ret) return ret; - if (enable_disable) - return regmap_write(priv->regmap, LP50XX_DEV_CFG0, LP50XX_CHIP_EN); - else - return regmap_write(priv->regmap, LP50XX_DEV_CFG0, 0); + if (priv->enable_gpio) { + ret = gpiod_direction_output(priv->enable_gpio, 0); + if (ret) + return ret; + + udelay(LP50XX_RESET_TIME_US); + } + return 0; } static int lp50xx_probe_leds(struct fwnode_handle *child, struct lp50xx *priv, @@ -453,6 +478,10 @@ static int lp50xx_probe_dt(struct lp50xx *priv) return dev_err_probe(priv->dev, PTR_ERR(priv->enable_gpio), "Failed to get enable GPIO\n"); + ret = lp50xx_enable(priv); + if (ret) + return ret; + priv->regulator = devm_regulator_get(priv->dev, "vled"); if (IS_ERR(priv->regulator)) priv->regulator = NULL; @@ -550,14 +579,6 @@ static int lp50xx_probe(struct i2c_client *client) return ret; } - ret = lp50xx_reset(led); - if (ret) - return ret; - - ret = lp50xx_enable_disable(led, 1); - if (ret) - return ret; - return lp50xx_probe_dt(led); } @@ -566,7 +587,7 @@ static void lp50xx_remove(struct i2c_client *client) struct lp50xx *led = i2c_get_clientdata(client); int ret; - ret = lp50xx_enable_disable(led, 0); + ret = lp50xx_disable(led); if (ret) dev_err(led->dev, "Failed to disable chip\n"); -- 2.51.0

3 weeks, 2 days

2
2
0 0

[PATCH v3 06/14] iommu/mediatek: fix use-after-free on probe deferral

by Johan Hovold

The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers. Fix this by keeping the references as expected while the iommu driver is bound. Fixes: 26593928564c ("iommu/mediatek: Add error path for loop of mm_dts_parse") Cc: stable(a)vger.kernel.org Cc: Yong Wu <yong.wu(a)mediatek.com> Acked-by: Robin Murphy <robin.murphy(a)arm.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/iommu/mtk_iommu.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index 8d8e85186188..64ce041238fd 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -1213,16 +1213,19 @@ static int mtk_iommu_mm_dts_parse(struct device *dev, struct component_match **m } component_match_add(dev, match, component_compare_dev, &plarbdev->dev); - platform_device_put(plarbdev); } - if (!frst_avail_smicomm_node) - return -EINVAL; + if (!frst_avail_smicomm_node) { + ret = -EINVAL; + goto err_larbdev_put; + } pcommdev = of_find_device_by_node(frst_avail_smicomm_node); of_node_put(frst_avail_smicomm_node); - if (!pcommdev) - return -ENODEV; + if (!pcommdev) { + ret = -ENODEV; + goto err_larbdev_put; + } data->smicomm_dev = &pcommdev->dev; link = device_link_add(data->smicomm_dev, dev, @@ -1230,7 +1233,8 @@ static int mtk_iommu_mm_dts_parse(struct device *dev, struct component_match **m platform_device_put(pcommdev); if (!link) { dev_err(dev, "Unable to link %s.\n", dev_name(data->smicomm_dev)); - return -EINVAL; + ret = -EINVAL; + goto err_larbdev_put; } return 0; @@ -1402,8 +1406,12 @@ static int mtk_iommu_probe(struct platform_device *pdev) iommu_device_sysfs_remove(&data->iommu); out_list_del: list_del(&data->list); - if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_MM)) + if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_MM)) { device_link_remove(data->smicomm_dev, dev); + + for (i = 0; i < MTK_LARB_NR_MAX; i++) + put_device(data->larb_imu[i].dev); + } out_runtime_disable: pm_runtime_disable(dev); return ret; @@ -1423,6 +1431,9 @@ static void mtk_iommu_remove(struct platform_device *pdev) if (MTK_IOMMU_IS_TYPE(data->plat_data, MTK_IOMMU_TYPE_MM)) { device_link_remove(data->smicomm_dev, &pdev->dev); component_master_del(&pdev->dev, &mtk_iommu_com_ops); + + for (i = 0; i < MTK_LARB_NR_MAX; i++) + put_device(data->larb_imu[i].dev); } pm_runtime_disable(&pdev->dev); for (i = 0; i < data->plat_data->banks_num; i++) { -- 2.49.1

3 weeks, 2 days

3
2
0 0

[PATCH v2 0/5] mm, swap: misc cleanup and bugfix

by Kairui Song

A few cleanups and a bugfix that are either suitable after the swap table phase I or found during code review. Patch 1 is a bugfix and needs to be included in the stable branch, the rest have no behavior change. --- Changes in v2: - Update commit message for patch 1, it's a sub-optimal fix and a better fix can be done later. [ Chris Li ] - Fix a lock balance issue in patch 1. [ YoungJun Park ] - Add a trivial cleanup patch to remove an unused argument, no behavior change. - Update kernel doc. - Fix minor issue with commit message [ Nhat Pham ] - Link to v1: https://lore.kernel.org/r/20251007-swap-clean-after-swap-table-p1-v1-0-7486… --- Kairui Song (5): mm, swap: do not perform synchronous discard during allocation mm, swap: rename helper for setup bad slots mm, swap: cleanup swap entry allocation parameter mm/migrate, swap: drop usage of folio_index mm, swap: remove redundant argument for isolating a cluster include/linux/swap.h | 4 +-- mm/migrate.c | 4 +-- mm/shmem.c | 2 +- mm/swap.h | 21 ---------------- mm/swapfile.c | 71 +++++++++++++++++++++++++++++++++++----------------- mm/vmscan.c | 4 +-- 6 files changed, 55 insertions(+), 51 deletions(-) --- base-commit: 5b5c3e53c939318f6a0698c895c7ec40758bff6a change-id: 20251007-swap-clean-after-swap-table-p1-b9a7635ee3fa Best regards, -- Kairui Song <kasong(a)tencent.com>

3 weeks, 3 days

3
3
0 0

[PATCH v2 6.1.y] drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()'

by Vasiliy Kovalev

From: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> commit cdb637d339572398821204a1142d8d615668f1e9 upstream. The issue arises when the array 'adev->vcn.vcn_config' is accessed before checking if the index 'adev->vcn.num_vcn_inst' is within the bounds of the array. The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array before it is used as an index. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_base_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use. Fixes: a0ccc717c4ab ("drm/amdgpu/discovery: validate VCN and SDMA instances") Cc: Christian König <christian.koenig(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> [ kovalev: bp to fix CVE-2024-27042 ] Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- v2: Added braces around the single statement in the `else` block to comply with kernel coding style. --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c index d8441e273cb5..9274ac361203 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c @@ -1128,15 +1128,16 @@ static int amdgpu_discovery_reg_base_init(struct amdgpu_device *adev) * 0b10 : encode is disabled * 0b01 : decode is disabled */ - adev->vcn.vcn_config[adev->vcn.num_vcn_inst] = - ip->revision & 0xc0; - ip->revision &= ~0xc0; - if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) + if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) { + adev->vcn.vcn_config[adev->vcn.num_vcn_inst] = + ip->revision & 0xc0; adev->vcn.num_vcn_inst++; - else + } else { dev_err(adev->dev, "Too many VCN instances: %d vs %d\n", adev->vcn.num_vcn_inst + 1, AMDGPU_MAX_VCN_INSTANCES); + } + ip->revision &= ~0xc0; } if (le16_to_cpu(ip->hw_id) == SDMA0_HWID || le16_to_cpu(ip->hw_id) == SDMA1_HWID || -- 2.50.1

3 weeks, 3 days

1
0
0 0

[PATCH v2 0/4] arm64: dts: marvell: cn913x-solidrun: fix sata ports status

by Josua Mayer

The SolidRun CN9130 SoC based boards have a variety of functional problems, in particular - SATA ports - CN9132 CEX-7 eMMC - CN9132 Clearfog PCI-E x2 / x4 ports are not functional. The SATA issue was recently introduced via changes to the armada-cp11x.dtsi, wheras the eMMC and SPI problems were present in the board dts from the very beginning. This patch-set aims to resolve the problems after testing on Debian 13 release (Linux v6.12). Signed-off-by: Josua Mayer <josua(a)solid-run.com> --- Changes in v2: - fixed mistakes in the original board device-trees that caused functional issues with eMMC and pci. - Link to v1: https://lore.kernel.org/r/20250911-cn913x-sr-fix-sata-v1-1-9e72238d0988@sol… --- Josua Mayer (4): arm64: dts: marvell: cn913x-solidrun: fix sata ports status arm64: dts: marvell: cn9132-clearfog: disable eMMC high-speed modes arm64: dts: marvell: cn9132-clearfog: fix multi-lane pci x2 and x4 ports arm64: dts: marvell: cn9130-sr-som: add missing properties to emmc arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 7 ++++--- arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 2 ++ arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts | 6 ++++-- arch/arm64/boot/dts/marvell/cn9132-clearfog.dts | 22 ++++++++++++++++------ arch/arm64/boot/dts/marvell/cn9132-sr-cex7.dtsi | 8 ++++++++ 5 files changed, 34 insertions(+), 11 deletions(-) --- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250911-cn913x-sr-fix-sata-5c737ebdb97f Best regards, -- Josua Mayer <josua(a)solid-run.com>

3 weeks, 3 days

3
13
0 0

[PATCH bpf-next 1/3] ftrace: Fix BPF fexit with livepatch

by Song Liu

When livepatch is attached to the same function as bpf trampoline with a fexit program, bpf trampoline code calls register_ftrace_direct() twice. The first time will fail with -EAGAIN, and the second time it will succeed. This requires register_ftrace_direct() to unregister the address on the first attempt. Otherwise, the bpf trampoline cannot attach. Here is an easy way to reproduce this issue: insmod samples/livepatch/livepatch-sample.ko bpftrace -e 'fexit:cmdline_proc_show {}' ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show... Fix this by cleaning up the hash when register_ftrace_function_nolock hits errors. Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Cc: stable(a)vger.kernel.org # v6.6+ Reported-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crow… Cc: Steven Rostedt (Google) <rostedt(a)goodmis.org> Cc: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Signed-off-by: Song Liu <song(a)kernel.org> --- kernel/trace/ftrace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 42bd2ba68a82..7f432775a6b5 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6048,6 +6048,8 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->direct_call = addr; err = register_ftrace_function_nolock(ops); + if (err) + remove_direct_functions_hash(hash, addr); out_unlock: mutex_unlock(&direct_mutex); -- 2.47.3

3 weeks, 3 days

3
3
0 0

[PATCH v2 bpf 1/3] ftrace: Fix BPF fexit with livepatch

by Song Liu

When livepatch is attached to the same function as bpf trampoline with a fexit program, bpf trampoline code calls register_ftrace_direct() twice. The first time will fail with -EAGAIN, and the second time it will succeed. This requires register_ftrace_direct() to unregister the address on the first attempt. Otherwise, the bpf trampoline cannot attach. Here is an easy way to reproduce this issue: insmod samples/livepatch/livepatch-sample.ko bpftrace -e 'fexit:cmdline_proc_show {}' ERROR: Unable to attach probe: fexit:vmlinux:cmdline_proc_show... Fix this by cleaning up the hash when register_ftrace_function_nolock hits errors. Fixes: d05cb470663a ("ftrace: Fix modification of direct_function hash while in use") Cc: stable(a)vger.kernel.org # v6.6+ Reported-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Closes: https://lore.kernel.org/live-patching/c5058315a39d4615b333e485893345be@crow… Cc: Steven Rostedt (Google) <rostedt(a)goodmis.org> Cc: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Acked-and-tested-by: Andrey Grodzovsky <andrey.grodzovsky(a)crowdstrike.com> Signed-off-by: Song Liu <song(a)kernel.org> --- kernel/trace/ftrace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 42bd2ba68a82..7f432775a6b5 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6048,6 +6048,8 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr) ops->direct_call = addr; err = register_ftrace_function_nolock(ops); + if (err) + remove_direct_functions_hash(hash, addr); out_unlock: mutex_unlock(&direct_mutex); -- 2.47.3

3 weeks, 3 days

1
0
0 0

FAILED: patch "[PATCH] x86/resctrl: Fix miscount of bandwidth event when" 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 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102053-condone-sprout-77c6@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 15292f1b4c55a3a7c940dbcb6cb8793871ed3d92 Mon Sep 17 00:00:00 2001 From: Babu Moger <babu.moger(a)amd.com> Date: Fri, 10 Oct 2025 12:08:35 -0500 Subject: [PATCH] x86/resctrl: Fix miscount of bandwidth event when reactivating previously unavailable RMID Users can create as many monitoring groups as the number of RMIDs supported by the hardware. However, on AMD systems, only a limited number of RMIDs are guaranteed to be actively tracked by the hardware. RMIDs that exceed this limit are placed in an "Unavailable" state. When a bandwidth counter is read for such an RMID, the hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62). When such an RMID starts being tracked again the hardware counter is reset to zero. MSR_IA32_QM_CTR.Unavailable remains set on first read after tracking re-starts and is clear on all subsequent reads as long as the RMID is tracked. resctrl miscounts the bandwidth events after an RMID transitions from the "Unavailable" state back to being tracked. This happens because when the hardware starts counting again after resetting the counter to zero, resctrl in turn compares the new count against the counter value stored from the previous time the RMID was tracked. This results in resctrl computing an event value that is either undercounting (when new counter is more than stored counter) or a mistaken overflow (when new counter is less than stored counter). Reset the stored value (arch_mbm_state::prev_msr) of MSR_IA32_QM_CTR to zero whenever the RMID is in the "Unavailable" state to ensure accurate counting after the RMID resets to zero when it starts to be tracked again. Example scenario that results in mistaken overflow ================================================== 1. The resctrl filesystem is mounted, and a task is assigned to a monitoring group. $mount -t resctrl resctrl /sys/fs/resctrl $mkdir /sys/fs/resctrl/mon_groups/test1/ $echo 1234 > /sys/fs/resctrl/mon_groups/test1/tasks $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 21323 <- Total bytes on domain 0 "Unavailable" <- Total bytes on domain 1 Task is running on domain 0. Counter on domain 1 is "Unavailable". 2. The task runs on domain 0 for a while and then moves to domain 1. The counter starts incrementing on domain 1. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 7345357 <- Total bytes on domain 0 4545 <- Total bytes on domain 1 3. At some point, the RMID in domain 0 transitions to the "Unavailable" state because the task is no longer executing in that domain. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes "Unavailable" <- Total bytes on domain 0 434341 <- Total bytes on domain 1 4. Since the task continues to migrate between domains, it may eventually return to domain 0. $cat /sys/fs/resctrl/mon_groups/test1/mon_data/mon_L3_*/mbm_total_bytes 17592178699059 <- Overflow on domain 0 3232332 <- Total bytes on domain 1 In this case, the RMID on domain 0 transitions from "Unavailable" state to active state. The hardware sets MSR_IA32_QM_CTR.Unavailable (bit 62) when the counter is read and begins tracking the RMID counting from 0. Subsequent reads succeed but return a value smaller than the previously saved MSR value (7345357). Consequently, the resctrl's overflow logic is triggered, it compares the previous value (7345357) with the new, smaller value and incorrectly interprets this as a counter overflow, adding a large delta. In reality, this is a false positive: the counter did not overflow but was simply reset when the RMID transitioned from "Unavailable" back to active state. Here is the text from APM [1] available from [2]. "In PQOS Version 2.0 or higher, the MBM hardware will set the U bit on the first QM_CTR read when it begins tracking an RMID that it was not previously tracking. The U bit will be zero for all subsequent reads from that RMID while it is still tracked by the hardware. Therefore, a QM_CTR read with the U bit set when that RMID is in use by a processor can be considered 0 when calculating the difference with a subsequent read." [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming Publication # 24593 Revision 3.41 section 19.3.3 Monitoring L3 Memory Bandwidth (MBM). [ bp: Split commit message into smaller paragraph chunks for better consumption. ] Fixes: 4d05bf71f157d ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger <babu.moger(a)amd.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Reviewed-by: Reinette Chatre <reinette.chatre(a)intel.com> Tested-by: Reinette Chatre <reinette.chatre(a)intel.com> Cc: stable(a)vger.kernel.org # needs adjustments for <= v6.17 Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537 # [2] diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/resctrl/monitor.c index c8945610d455..2cd25a0d4637 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -242,7 +242,9 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d, u32 unused, u32 rmid, enum resctrl_event_id eventid, u64 *val, void *ignored) { + struct rdt_hw_mon_domain *hw_dom = resctrl_to_arch_mon_dom(d); int cpu = cpumask_any(&d->hdr.cpu_mask); + struct arch_mbm_state *am; u64 msr_val; u32 prmid; int ret; @@ -251,12 +253,16 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_mon_domain *d, prmid = logical_rmid_to_physical_rmid(cpu, rmid); ret = __rmid_read_phys(prmid, eventid, &msr_val); - if (ret) - return ret; - *val = get_corrected_val(r, d, rmid, eventid, msr_val); + if (!ret) { + *val = get_corrected_val(r, d, rmid, eventid, msr_val); + } else if (ret == -EINVAL) { + am = get_arch_mbm_state(hw_dom, rmid, eventid); + if (am) + am->prev_msr = 0; + } - return 0; + return ret; } static int __cntr_id_read(u32 cntr_id, u64 *val)

3 weeks, 3 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror