lpfc_check_nlp_post_devloss(9)

💖 lpfc_check_nlp_post_devloss(9) 💖

okay so bestie, this is a page straight out of the Kernel API Manual and it's genuinely one of the most niche little cleanup functions ever — but we're gonna understand it, periodt. ✨

---

🌸 NAME 🌸

lpfc_check_nlp_post_devloss — the little function that checks whether it needs to restore the ndlp refcnt after devloss 🫶

---

🦋 SYNOPSIS 🦋

void lpfc_check_nlp_post_devloss (struct lpfc_vport *vport , struct
       lpfc_nodelist *ndlp );

no cap, that's the whole signature. void in, void out, two pointers of business 💅

---

🎀 ARGUMENTS 🎀

• vport — pointer to the vport object. literally just a pointer to the vport object, that's the vibe 🐝
• ndlp — pointer to the remote node object. the remote node bestie in question 💜

---

⭐ DESCRIPTION ⭐

so here's the tea ☕ — if the NLP_IN_RECOV_POST_DEV_LOSS flag was set because a node had an outstanding recovery going on during dev_loss_tmo processing, then this function restores the nlp_put kref decrement from lpfc_dev_loss_tmo_handler. 🩹✨

that's it. that's the whole job. it undoes the refcount dip so the node doesn't get yeeted into the void while it's still mid-recovery. king behavior honestly 👑

ngl this one is short but it matters — it's the "wait, put that kref back" moment of the devloss flow 😭

---

🌈 SEE ALSO 🌈

the kernel file:

• ./drivers/scsi/lpfc/lpfc_hbadisc.c

and the whole friend group (aka every related function, listed exactly, no skips, no cuts) 🫶:

• lpfc_check_inactive_vmid_one(9)
• lpfc_check_inactive_vmid(9)
• lpfc_dev_loss_tmo_handler(9)
• lpfc_sli4_post_dev_loss_tmo_handler(9)
• lpfc_alloc_fast_evt(9)
• lpfc_free_fast_evt(9)
• lpfc_send_fastpath_evt(9)
• lpfc_sli4_clear_fcf_rr_bmask(9)
• lpfc_fab_name_match(9)
• lpfc_sw_name_match(9)
• lpfc_mac_addr_match(9)
• __lpfc_update_fcf_record_pri(9)
• lpfc_copy_fcf_record(9)
• __lpfc_update_fcf_record(9)
• lpfc_register_fcf(9)
• lpfc_match_fcf_conn_list(9)
• lpfc_check_pending_fcoe_event(9)
• lpfc_sli4_new_fcf_random_select(9)
• lpfc_sli4_fcf_rec_mbox_parse(9)
• lpfc_sli4_log_fcf_record_info(9)
• lpfc_sli4_fcf_record_match(9)
• lpfc_sli4_fcf_rr_next_proc(9)
• lpfc_sli4_fcf_pri_list_del(9)
• lpfc_sli4_set_fcf_flogi_fail(9)
• lpfc_sli4_fcf_pri_list_add(9)
• lpfc_mbx_cmpl_fcf_scan_read_fcf_rec(9)
• lpfc_mbx_cmpl_fcf_rr_read_fcf_rec(9)
• lpfc_mbx_cmpl_read_fcf_rec(9)
• lpfc_init_vfi_cmpl(9)
• lpfc_issue_init_vfi(9)
• lpfc_init_vpi_cmpl(9)
• lpfc_issue_init_vpi(9)
• lpfc_start_fdiscs(9)
• lpfc_create_static_vport(9)
• lpfc_issue_gidpt(9)
• lpfc_initialize_node(9)
• lpfc_nlp_logo_unreg(9)
• lpfc_unreg_hba_rpis(9)
• lpfc_find_vport_by_vpid(9)
• lpfc_fcf_inuse(9)
• lpfc_unregister_vfi_cmpl(9)
• lpfc_unregister_fcfi_cmpl(9)
• lpfc_unregister_fcf_prep(9)
• lpfc_sli4_unregister_fcf(9)
• lpfc_unregister_fcf_rescan(9)
• lpfc_unregister_fcf(9)
• lpfc_unregister_unused_fcf(9)
• lpfc_read_fcf_conn_tbl(9)
• lpfc_read_fcoe_param(9)
• lpfc_get_rec_conf23(9)
• lpfc_parse_fcoe_conf(9)

---

and that's the page!! 🎀 this gem lives in ./drivers/scsi/lpfc, dated October 2026, and its whole title-and-manual-name situation is lpfc_check_nlp_post_devloss(9) — slay, go read the other 51 pages now, ily, bye 💜✨