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

[PATCH] mm/damon/core: fix memory leak of repeat mode damon_call_control objects

by Enze Li

A memory leak exists in the handling of repeat mode damon_call_control objects by kdamond_call(). While damon_call() correctly allows multiple repeat mode objects (with ->repeat set to true) to be added to the per-context list, kdamond_call() incorrectly processes them. The function moves all repeat mode objects from the context's list to a temporary list (repeat_controls). However, it only moves the first object back to the context's list for future calls, leaving the remaining objects on the temporary list where they are abandoned and leaked. This patch fixes the leak by ensuring all repeat mode objects are properly re-added to the context's list. Fixes: 43df7676e550 ("mm/damon/core: introduce repeat mode damon_call()") Signed-off-by: Enze Li <lienze(a)kylinos.cn> 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); + } } /* Returns negative error code if it's not activated but should return */ base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449 -- 2.52.0

1 week, 3 days

1
0
0 0

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, 3 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror