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

Re: [PATCH] mm/damon/core: support multiple damon_call_control requests

by SeongJae Park

Hello Enze, First of all, thank you for sharing this patch! On Tue, 2 Dec 2025 10:14:07 +0800 Enze Li <lienze(a)kylinos.cn> wrote: > The current implementation only supports repeated calls to a single > damon_call_control request per context. I understand "repeated calls to a single damon_call_control" means "single damon_call_control object having ->repeat set as true". Let me call it "repeat mode damon_call_control object". This is not an intentionally designed limitation but a bug. damon_call() allows callers adding multiple repeat mode damon_call_control objects per context. Technically, it adds any requested damon_call_control object to the per-context linked list, regardless of the number of repeat mode objects on the list. But, the consumer of the damon_call_control objects list, kdamond_call(), moves the repeat mode objects from the per-context list to a temporal list (repeat_controls), and then move only the first repeat mode entry from the temporal list to the per-context list. If there were multiple repeat mode objects in the per-context list, what happens to the remaining repeat mode damon_call_control objects on the temporal list? Nothing. As a result, the memory for the objects are leaked. Definitely this is a bug. Luckily there is no such multiple repeat mode damon_call() requests, so no upstream kernel user is exposed to the memory leak bug in real. But the bug is a bug. We should fix this. > This limitation introduces > inefficiencies for scenarios that require registering multiple deferred > operations. I'm not very convinced with the above reasoning because 1. it is not a matter of inefficiency but a clear memory leak bug. 2. there is no damon_call() callers that want to have multiple deferred operations with high efficiency, at the moment. In my opinion, the above sentence is better to be just dropped. > > This patch modifies the implementation of kdamond_call() to support > repeated calls to multiple damon_call_control requests. This change is rquired for fixing the bug, though. > To demonstrate > the effect of this change, I made minor modifications to > samples/damon/prcl.c by adding a new request alongside the original > damon_call_control request and performed comparative tests. > > Before applying the patch, I observed, > > [ 381.661821] damon_sample_prcl: start > [ 381.668199] damon_sample_prcl: repeat_call_v2 > [ 381.668208] damon_sample_prcl: repeat_call > [ 381.668211] damon_sample_prcl: wss: 0 > [ 381.675194] damon_sample_prcl: repeat_call > [ 381.675202] damon_sample_prcl: wss: 0 > > after applying the patch, I saw, > > [ 61.750723] damon_sample_prcl: start > [ 61.757104] damon_sample_prcl: repeat_call_v2 > [ 61.757106] damon_sample_prcl: repeat_call > [ 61.757107] damon_sample_prcl: wss: 0 > [ 61.763067] damon_sample_prcl: repeat_call_v2 > [ 61.763069] damon_sample_prcl: repeat_call > [ 61.763070] damon_sample_prcl: wss: 0 > > Signed-off-by: Enze Li <lienze(a)kylinos.cn> Assuming we agree on the fact this is a fix of the bug, I think we should add below tags. Fixes: 43df7676e550 ("mm/damon/core: introduce repeat mode damon_call()") Cc: <stable(a)vger.kernel.org> # 6.17.x > --- > mm/damon/core.c | 20 +++++++++++++------- > 1 file changed, 13 insertions(+), 7 deletions(-) > > diff --git a/mm/damon/core.c b/mm/damon/core.c > index 109b050c795a..66b5bae44f22 100644 > --- a/mm/damon/core.c > +++ b/mm/damon/core.c > @@ -2526,13 +2526,19 @@ static void kdamond_call(struct damon_ctx *ctx, bool cancel) > list_add(&control->list, &repeat_controls); > } > } > - control = list_first_entry_or_null(&repeat_controls, > - struct damon_call_control, list); > - if (!control || cancel) > - return; > - mutex_lock(&ctx->call_controls_lock); > - list_add_tail(&control->list, &ctx->call_controls); > - mutex_unlock(&ctx->call_controls_lock); > + while (true) { > + control = list_first_entry_or_null(&repeat_controls, > + struct damon_call_control, list); > + if (!control) > + break; > + /* Unlink from the repeate_controls list. */ > + list_del(&control->list); > + if (cancel) > + continue; > + mutex_lock(&ctx->call_controls_lock); > + list_add(&control->list, &ctx->call_controls); > + mutex_unlock(&ctx->call_controls_lock); > + } This looks good enough to fix the bug. Could you please resend this patch after rewording the commit message as appripriate for the bug fix, adding points I listed above? Again, thank you for letting us find this bug. Thanks, SJ [...]

1 week, 3 days

2
1
0 0

FAILED: patch "[PATCH] mm/huge_memory: fix NULL pointer deference when splitting" 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 cff47b9e39a6abf03dde5f4f156f841b0c54bba0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025120102-geranium-elevator-ca86@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From cff47b9e39a6abf03dde5f4f156f841b0c54bba0 Mon Sep 17 00:00:00 2001 From: Wei Yang <richard.weiyang(a)gmail.com> Date: Wed, 19 Nov 2025 23:53:02 +0000 Subject: [PATCH] mm/huge_memory: fix NULL pointer deference when splitting folio Commit c010d47f107f ("mm: thp: split huge page to any lower order pages") introduced an early check on the folio's order via mapping->flags before proceeding with the split work. This check introduced a bug: for shmem folios in the swap cache and truncated folios, the mapping pointer can be NULL. Accessing mapping->flags in this state leads directly to a NULL pointer dereference. This commit fixes the issue by moving the check for mapping != NULL before any attempt to access mapping->flags. Link: https://lkml.kernel.org/r/20251119235302.24773-1-richard.weiyang@gmail.com Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Signed-off-by: Wei Yang <richard.weiyang(a)gmail.com> Reviewed-by: Zi Yan <ziy(a)nvidia.com> Acked-by: David Hildenbrand (Red Hat) <david(a)kernel.org> Reviewed-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 2f2a521e5d68..6cba1cb14b23 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3619,6 +3619,16 @@ static int __folio_split(struct folio *folio, unsigned int new_order, if (folio != page_folio(split_at) || folio != page_folio(lock_at)) return -EINVAL; + /* + * Folios that just got truncated cannot get split. Signal to the + * caller that there was a race. + * + * TODO: this will also currently refuse shmem folios that are in the + * swapcache. + */ + if (!is_anon && !folio->mapping) + return -EBUSY; + if (new_order >= folio_order(folio)) return -EINVAL; @@ -3659,18 +3669,6 @@ static int __folio_split(struct folio *folio, unsigned int new_order, gfp_t gfp; mapping = folio->mapping; - - /* Truncated ? */ - /* - * TODO: add support for large shmem folio in swap cache. - * When shmem is in swap cache, mapping is NULL and - * folio_test_swapcache() is true. - */ - if (!mapping) { - ret = -EBUSY; - goto out; - } - min_order = mapping_min_folio_order(folio->mapping); if (new_order < min_order) { ret = -EINVAL;

1 week, 3 days

3
2
0 0

[PATCH v4 5/7] NTB: epf: vntb: Stop cmd_handler work in epf_ntb_epc_cleanup

by Koichiro Den

Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20 Cc: <stable(a)vger.kernel.org> Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Koichiro Den <den(a)valinux.co.jp> --- drivers/pci/endpoint/functions/pci-epf-vntb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c index 49ce5d4b0ee5..750a246f79c9 100644 --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c @@ -823,6 +823,7 @@ static int epf_ntb_epc_init(struct epf_ntb *ntb) */ static void epf_ntb_epc_cleanup(struct epf_ntb *ntb) { + disable_delayed_work_sync(&ntb->cmd_handler); epf_ntb_mw_bar_clear(ntb, ntb->num_mws); epf_ntb_db_bar_clear(ntb); epf_ntb_config_sspad_bar_clear(ntb); -- 2.48.1

1 week, 3 days

1
0
0 0

[PATCH v4 4/7] PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown

by Koichiro Den

epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to do later. This leads to an oops when .allow_link fails or when .drop_link is performed. Remove the helper. Also drop pci_epc_put(). EPC device refcounting is tied to configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Cc: <stable(a)vger.kernel.org> Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Koichiro Den <den(a)valinux.co.jp> --- drivers/pci/endpoint/functions/pci-epf-ntb.c | 56 +------------------- 1 file changed, 2 insertions(+), 54 deletions(-) diff --git a/drivers/pci/endpoint/functions/pci-epf-ntb.c b/drivers/pci/endpoint/functions/pci-epf-ntb.c index e01a98e74d21..7702ebb81d99 100644 --- a/drivers/pci/endpoint/functions/pci-epf-ntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-ntb.c @@ -1494,47 +1494,6 @@ static int epf_ntb_db_mw_bar_init(struct epf_ntb *ntb, return ret; } -/** - * epf_ntb_epc_destroy_interface() - Cleanup NTB EPC interface - * @ntb: NTB device that facilitates communication between HOST1 and HOST2 - * @type: PRIMARY interface or SECONDARY interface - * - * Unbind NTB function device from EPC and relinquish reference to pci_epc - * for each of the interface. - */ -static void epf_ntb_epc_destroy_interface(struct epf_ntb *ntb, - enum pci_epc_interface_type type) -{ - struct epf_ntb_epc *ntb_epc; - struct pci_epc *epc; - struct pci_epf *epf; - - if (type < 0) - return; - - epf = ntb->epf; - ntb_epc = ntb->epc[type]; - if (!ntb_epc) - return; - epc = ntb_epc->epc; - pci_epc_remove_epf(epc, epf, type); - pci_epc_put(epc); -} - -/** - * epf_ntb_epc_destroy() - Cleanup NTB EPC interface - * @ntb: NTB device that facilitates communication between HOST1 and HOST2 - * - * Wrapper for epf_ntb_epc_destroy_interface() to cleanup all the NTB interfaces - */ -static void epf_ntb_epc_destroy(struct epf_ntb *ntb) -{ - enum pci_epc_interface_type type; - - for (type = PRIMARY_INTERFACE; type <= SECONDARY_INTERFACE; type++) - epf_ntb_epc_destroy_interface(ntb, type); -} - /** * epf_ntb_epc_create_interface() - Create and initialize NTB EPC interface * @ntb: NTB device that facilitates communication between HOST1 and HOST2 @@ -1614,15 +1573,8 @@ static int epf_ntb_epc_create(struct epf_ntb *ntb) ret = epf_ntb_epc_create_interface(ntb, epf->sec_epc, SECONDARY_INTERFACE); - if (ret) { + if (ret) dev_err(dev, "SECONDARY intf: Fail to create NTB EPC\n"); - goto err_epc_create; - } - - return 0; - -err_epc_create: - epf_ntb_epc_destroy_interface(ntb, PRIMARY_INTERFACE); return ret; } @@ -1887,7 +1839,7 @@ static int epf_ntb_bind(struct pci_epf *epf) ret = epf_ntb_init_epc_bar(ntb); if (ret) { dev_err(dev, "Failed to create NTB EPC\n"); - goto err_bar_init; + return ret; } ret = epf_ntb_config_spad_bar_alloc_interface(ntb); @@ -1909,9 +1861,6 @@ static int epf_ntb_bind(struct pci_epf *epf) err_bar_alloc: epf_ntb_config_spad_bar_free(ntb); -err_bar_init: - epf_ntb_epc_destroy(ntb); - return ret; } @@ -1927,7 +1876,6 @@ static void epf_ntb_unbind(struct pci_epf *epf) epf_ntb_epc_cleanup(ntb); epf_ntb_config_spad_bar_free(ntb); - epf_ntb_epc_destroy(ntb); } #define EPF_NTB_R(_name) \ -- 2.48.1

1 week, 3 days

1
0
0 0

[PATCH v4 3/7] PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown

by Koichiro Den

epf_ntb_epc_destroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allow_link fails or when .drop_link is performed. The following is an example oops of the former case: Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pci_epc_remove_epf+0x78/0xe0 (P) pci_primary_epc_epf_link+0x88/0xa8 configfs_symlink+0x1f4/0x5a0 vfs_symlink+0x134/0x1d8 do_symlinkat+0x88/0x138 __arm64_sys_symlinkat+0x74/0xe0 [...] Remove the helper, and drop pci_epc_put(). EPC device refcounting is tied to the configfs EPC group lifetime, and pci_epc_put() in the .drop_link path is sufficient. Cc: <stable(a)vger.kernel.org> Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Koichiro Den <den(a)valinux.co.jp> --- drivers/pci/endpoint/functions/pci-epf-vntb.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c index 83e9ab10f9c4..49ce5d4b0ee5 100644 --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c @@ -644,19 +644,6 @@ static void epf_ntb_mw_bar_clear(struct epf_ntb *ntb, int num_mws) } } -/** - * epf_ntb_epc_destroy() - Cleanup NTB EPC interface - * @ntb: NTB device that facilitates communication between HOST and VHOST - * - * Wrapper for epf_ntb_epc_destroy_interface() to cleanup all the NTB interfaces - */ -static void epf_ntb_epc_destroy(struct epf_ntb *ntb) -{ - pci_epc_remove_epf(ntb->epf->epc, ntb->epf, 0); - pci_epc_put(ntb->epf->epc); -} - - /** * epf_ntb_is_bar_used() - Check if a bar is used in the ntb configuration * @ntb: NTB device that facilitates communication between HOST and VHOST @@ -1406,7 +1393,7 @@ static int epf_ntb_bind(struct pci_epf *epf) ret = epf_ntb_init_epc_bar(ntb); if (ret) { dev_err(dev, "Failed to create NTB EPC\n"); - goto err_bar_init; + return ret; } ret = epf_ntb_config_spad_bar_alloc(ntb); @@ -1446,9 +1433,6 @@ static int epf_ntb_bind(struct pci_epf *epf) err_bar_alloc: epf_ntb_config_spad_bar_free(ntb); -err_bar_init: - epf_ntb_epc_destroy(ntb); - return ret; } @@ -1464,7 +1448,6 @@ static void epf_ntb_unbind(struct pci_epf *epf) epf_ntb_epc_cleanup(ntb); epf_ntb_config_spad_bar_free(ntb); - epf_ntb_epc_destroy(ntb); pci_unregister_driver(&vntb_pci_driver); } -- 2.48.1

1 week, 3 days

1
0
0 0

[PATCH v4 2/7] PCI: endpoint: Fix parameter order for .drop_link

by Koichiro Den

The unlink callbacks passed the parameters in the wrong order that led to looking up the wrong group objects. Swap the arguments so that the first parameter is the epf item and the second is the epc item. Cc: <stable(a)vger.kernel.org> Fixes: e85a2d783762 ("PCI: endpoint: Add support in configfs to associate two EPCs with EPF") Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Koichiro Den <den(a)valinux.co.jp> --- drivers/pci/endpoint/pci-ep-cfs.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/pci/endpoint/pci-ep-cfs.c b/drivers/pci/endpoint/pci-ep-cfs.c index ef50c82e647f..c7cf6c76d116 100644 --- a/drivers/pci/endpoint/pci-ep-cfs.c +++ b/drivers/pci/endpoint/pci-ep-cfs.c @@ -69,8 +69,8 @@ static int pci_secondary_epc_epf_link(struct config_item *epf_item, return 0; } -static void pci_secondary_epc_epf_unlink(struct config_item *epc_item, - struct config_item *epf_item) +static void pci_secondary_epc_epf_unlink(struct config_item *epf_item, + struct config_item *epc_item) { struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent); struct pci_epc_group *epc_group = to_pci_epc_group(epc_item); @@ -133,8 +133,8 @@ static int pci_primary_epc_epf_link(struct config_item *epf_item, return 0; } -static void pci_primary_epc_epf_unlink(struct config_item *epc_item, - struct config_item *epf_item) +static void pci_primary_epc_epf_unlink(struct config_item *epf_item, + struct config_item *epc_item) { struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent); struct pci_epc_group *epc_group = to_pci_epc_group(epc_item); -- 2.48.1

1 week, 3 days

1
0
0 0

[PATCH v4 1/7] NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR

by Koichiro Den

When BAR_PEER_SPAD and BAR_CONFIG share one PCI BAR, the module teardown path ends up calling pci_iounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following: Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pci_iounmap+0x2c/0x40 ntb_epf_pci_remove+0x44/0x80 [ntb_hw_epf] pci_device_remove+0x48/0xf8 device_remove+0x50/0x88 device_release_driver_internal+0x1c8/0x228 driver_detach+0x50/0xb0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x68 pci_unregister_driver+0x34/0xa0 ntb_epf_pci_driver_exit+0x14/0xfe0 [ntb_hw_epf] [...] Fix it by unmapping only when PEER_SPAD and CONFIG use difference bars. Cc: <stable(a)vger.kernel.org> Fixes: e75d5ae8ab88 ("NTB: epf: Allow more flexibility in the memory BAR map method") Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Signed-off-by: Koichiro Den <den(a)valinux.co.jp> --- drivers/ntb/hw/epf/ntb_hw_epf.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/ntb/hw/epf/ntb_hw_epf.c b/drivers/ntb/hw/epf/ntb_hw_epf.c index d3ecf25a5162..9935da48a52e 100644 --- a/drivers/ntb/hw/epf/ntb_hw_epf.c +++ b/drivers/ntb/hw/epf/ntb_hw_epf.c @@ -646,7 +646,8 @@ static void ntb_epf_deinit_pci(struct ntb_epf_dev *ndev) struct pci_dev *pdev = ndev->ntb.pdev; pci_iounmap(pdev, ndev->ctrl_reg); - pci_iounmap(pdev, ndev->peer_spad_reg); + if (ndev->barno_map[BAR_PEER_SPAD] != ndev->barno_map[BAR_CONFIG]) + pci_iounmap(pdev, ndev->peer_spad_reg); pci_iounmap(pdev, ndev->db_reg); pci_release_regions(pdev); -- 2.48.1

1 week, 3 days

1
0
0 0

[PATCH v3 0/7] PCI: endpoint/NTB: Harden vNTB resource management

by Koichiro Den

The vNTB endpoint function (pci-epf-vntb) can be configured and reconfigured through configfs (link/unlink functions, start/stop the controller, update parameters). In practice, several pitfalls present: double-unmapping when two windows share a BAR, wrong parameter order in .drop_link leading to wrong object lookups, duplicate EPC teardown that leads to oopses, a work item running after resources were torn down, and inability to re-link/restart fundamentally because ntb_dev was embedded and the vPCI bus teardown was incomplete. This series addresses those issues and hardens resource management across NTB EPF and PCI EP core: - Avoid double iounmap when PEER_SPAD and CONFIG share the same BAR. - Fix configfs .drop_link parameter order so the correct groups are used during unlink. - Remove duplicate EPC resource teardown in both pci-epf-vntb and pci-epf-ntb, avoiding crashes on .allow_link failures and during .drop_link. - Stop the delayed cmd_handler work before clearing BARs/doorbells. - Manage ntb_dev as a devm-managed allocation and implement .remove() in the vNTB PCI driver. Switch to pci_scan_root_bus(). With these changes, the controller can now be stopped, a function unlinked, configfs settings updated, and the controller re-linked and restarted without rebooting the endpoint, as long as the underlying pci_epc_ops .stop() is non-destructive and .start() restores normal operation. Patches 1-5 carry Fixes tags and are candidates for stable. Patch 6 is a preparatory one for Patch 7. Patch 7 is a behavioral improvement that completes lifetime management for relink/restart scenarios. Apologies for the delay between v2 and v3, and thank you for the review. v2->v3 changes: - Added Reviewed-by tag for [PATCH v2 4/6] - Split [PATCH v2 6/6] into two, based on the feedback from Frank. (No code changes overall.) v1->v2 changes: - Incorporated feedback from Frank. - Added Reviewed-by tags (except for patches #4 and #6). - Fixed a typo in patch #5 title. (No code changes overall.) v2: https://lore.kernel.org/all/20251029080321.807943-1-den@valinux.co.jp/ v1: https://lore.kernel.org/all/20251023071757.901181-1-den@valinux.co.jp/ Koichiro Den (7): NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR PCI: endpoint: Fix parameter order for .drop_link PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown PCI: endpoint: pci-epf-ntb: Remove duplicate resource teardown NTB: epf: vntb: Stop cmd_handler work in epf_ntb_epc_cleanup PCI: endpoint: pci-epf-vntb: Switch vpci_scan_bus() to use pci_scan_root_bus() PCI: endpoint: pci-epf-vntb: Manage ntb_dev lifetime and fix vpci bus teardown drivers/ntb/hw/epf/ntb_hw_epf.c | 3 +- drivers/pci/endpoint/functions/pci-epf-ntb.c | 56 +----------- drivers/pci/endpoint/functions/pci-epf-vntb.c | 86 ++++++++++++------- drivers/pci/endpoint/pci-ep-cfs.c | 8 +- 4 files changed, 62 insertions(+), 91 deletions(-) -- 2.48.1

1 week, 3 days

3
11
0 0

How To Correct Name on JetBlue Flight Ticket?

by taige52＠netaxistech.com

Correcting a name on a JetBlue flight ticket doesn’t have to be a daunting task. This guide is designed to help travelers easily understand the steps and fees involved in making name corrections. Whether it’s a minor typo or a major change due to a life event, ensuring your name matches your government ID is crucial for a hassle-free journey. Read this blog on to learn how to handle name corrections efficiently and ensure your travel plans proceed without any issues. What is the policy of changing name on JetBlue? Before you proceed to change your name, you must be well versed with its name changing policy which will help you, JetBlue Name Change Policy includes the following criteria: Validation by JetBlue: The ticket must be validated by JetBlue (B6/279), and all flights on the ticket must be either operated or validated by JetBlue. Single Reissue: Only one reissue per ticket is allowed for a name correction. Any additional name corrections are treated as name changes and will incur change fees and fare increases. Flight and Fare Restrictions: Changes to flights, travel dates, fare classes, or fare basis codes are not permitted. If the original fare is unavailable, refer to specific instructions. Mid-Travel Corrections: Minor name corrections are allowed mid-travel to match the government-issued ID or passport, ensuring the passenger's identity is consistent throughout the journey. Date of Birth and Gender: The date of birth and gender cannot be changed in conjunction with a name correction. Altering both the date of birth and the name is considered a name change and falls under the Name Change Policy. Booking Errors: Minor corrections to the date of birth are permitted due to booking errors, provided the name remains unchanged. Single Correction Rule: Only one correction per customer is allowed. Any further changes will adhere to the Name Change Policy. How much will it cost to make JetBlue name changes? Changing a name on a JetBlue ticket comes with specific costs that vary depending on several factors. For Blue Basic seat holders, the fee is typically $100 for domestic flights, but this charge can rise to $200 for international flights beyond the USA, Mexico, or Central America. For passengers traveling with Blue, Blue Extra, Blue Refundable, Blue Plus, Blue Plus Refundable, Mint, and Mint Refundable tickets, name corrections can be made by covering the fare difference. If you choose to correct the name offline, be prepared to pay a bit more, with fees starting at $50, depending on the fare type. Special situations, such as name changes due to marriage, adoption, or divorce, may also incur varying costs based on the specifics of the case as per the JetBlue Airways name change policy. It's important to note that only one name change per passenger is allowed. If you need to modify the name more than once, you will have to pay the designated fee for each subsequent change. What is the process of modifying name on JetBlue tickets? Make sure JetBlue (B6/279) is the carrier for your flight. Have your government ID or passport ready. For name changes due to marriage, divorce, or adoption, have those legal documents too. Reach out to JetBlue customer service online, by phone, or at the airport. Tell them about the name correction you need. Explain if it’s a small fix (like a typo) or a big change. Ensure your date of birth and gender stay the same. Pay the required fee. Blue Basic seats might cost $100 for domestic or up to $200 for international flights. Other fare types might just need a fare difference payment. Once the correction is done and fees are paid, check your updated ticket to make sure everything is correct. Only one name change per ticket is allowed. Any further changes will cost extra. By following these steps, you can easily correct your name on JetBlue tickets and keep your travel plans on track. You can call JetBlue at +1 (866) 897-5122 for doing it over a call or need help. What is the acceptable name change on JetBlue? JetBlue’s Name Correction Policy offers flexibility for passengers needing to adjust their names on tickets to align with their government-issued ID or passport. This policy covers a range of changes, ensuring that travelers can rectify mistakes or update their names due to significant life events without undue hassle. Acceptable modifications include correcting misspellings in first, middle, or last names, switching from a nickname to a legal name, and resolving inverted names. Additionally, passengers can add a middle name or an extra last name if required. The policy also caters to more substantial changes, such as those resulting from marriage, divorce, or adoption. These updates are crucial for reflecting the new legal name accurately. Importantly, JetBlue requires that the date of birth and gender remain unchanged to maintain the consistency of the passenger's identity. In cases where an error isn't corrected before the first leg of travel, JetBlue permits mid-travel name corrections under the same guidelines. This provision ensures that even in the midst of a journey, passengers can amend their name details to avoid any issues during their travels. JetBlue offers a simply easy process for name corrections, tailored to accommodate both minor errors and significant changes resulting from life events like marriage, divorce, or adoption. You can call +1 (866) 897-5122 to know more.

1 week, 4 days

1
0
0 0

How To Talk To a Live Person at Lufthansa Airlines?

by taige52＠netaxistech.com

Trying to get in touch with a live person at Lufthansa Airlines can feel like a quest for hidden treasure. Whether it's resolving a booking issue, making a last-minute change, or simply seeking information, speaking directly to a human can make all the difference. This guide provides you with the essential steps to connect with a real representative at Lufthansa, ensuring your questions are answered swiftly and effectively. Discover how easy it can be to get the help you need with just a few clicks or a quick call through this blog . How to contact the Lufthansa Airlines customer service? Reaching out to Lufthansa Airlines for assistance is a breeze. Here’s how you can do it: Open your web browser and head over to Lufthansa’s official website. It’s your starting point for all things related to their services. Scroll to the bottom of the homepage. There, you’ll spot a link labeled "Help & Contact." Click on it to access the customer service options. You’ll find various ways to get in touch. Whether you prefer calling, emailing, or chatting online, they’ve got you covered. Pick the option that suits you best. If you prefer talking to someone directly, call Lufthansa customer service hotline at +1-800-645-3880 or +1 (866) 897-5122. Keep your booking details handy for a smoother conversation. If your issue isn’t urgent, consider sending an email. Look for the customer service email address in the contact section and draft a detailed message explaining your concern. Lufthansa is also active on social media platforms like Twitter and Facebook. You can send them a message or tweet at them for assistance. If you prefer face-to-face interaction, find the nearest Lufthansa office. Addresses and office hours are listed on their website. If you have the Lufthansa app installed, you can access customer service directly through it. The app provides a convenient way to manage your booking and get support on the go. With these steps, getting the help you need from Lufthansa customer service is simple and easy. What advantages can I get by contacting the Lufthansa Airlines customer service? Contacting Lufthansa Airlines customer service can significantly enhance your travel experience in numerous ways. First and foremost, their knowledgeable representatives can assist you with any booking modifications you might need. Whether it's changing flight dates, upgrading your seat, or adding extra baggage, they ensure your trip is tailored to your preferences without any hassle. Another major advantage is their ability to provide up-to-date information about your flight status. If there's a delay or change in your flight schedule, customer service can keep you informed, helping you avoid unnecessary stress and allowing you to plan accordingly. They can also assist you with any special requests, such as meal preferences, wheelchair assistance, or seating arrangements, ensuring your comfort throughout the journey. Lufthansa customer service also excels in resolving issues efficiently. If you encounter problems like lost luggage or ticketing errors, their team is equipped to handle such situations promptly, providing peace of mind. Additionally, their multilingual support ensures that language barriers are not an obstacle, making communication easy and effective for travelers from around the world. By reaching out to Lufthansa Airlines customer service, you gain a reliable partner in your travel journey, dedicated to making every aspect of your trip smoother and more enjoyable. Can I have a live chat with Lufthansa? Yes, you can have a live chat with Lufthansa, and it’s a straightforward process. When you need immediate assistance or have questions that require quick responses, the live chat feature on Lufthansa’s website is your go-to option. To get started, head over to the Lufthansa website and look for the "Help & Contact" page. Once there, you will see an icon resembling a message box. Clicking on this icon will connect you with a live representative who is ready to assist you. This feature is particularly useful for resolving issues on the spot, whether it’s inquiries about your booking, flight changes, or any special requests you might have. The Lufthansa live chat option provides a direct line to a knowledgeable representative, ensuring your concerns are addressed promptly. It’s a convenient way to get the help you need without having to wait on hold or navigate through automated phone menus. Whether you’re at home or on the go, Lufthansa’s live chat service offers a reliable and efficient way to get support, making your travel experience smoother and more enjoyable. Reaching a live person at Lufthansa Airlines doesn't have to be a daunting task. By following the steps outlined in this guide, you can connect with a knowledgeable representative who can assist with any queries or issues you might have. Whether you choose to use the live chat feature on their website, dial +1 (866) 897-5122 for direct support, or explore other contact options, knowing how to get in touch effectively can significantly enhance your travel experience. Remember, Lufthansa customer service team is there to help make your journey smoother and more enjoyable, providing the assistance you need when you need it most.

1 week, 4 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror