15.0-RELEASE_panic_in_inotify_log():_vp->v_ pollinfo_==_NULL_—_advice_on_PR_/_invariant

Hello,

I am seeing a reproducible kernel panic on FreeBSD 15.0-RELEASE 
(GENERIC) in the inotify subsystem and would appreciate advice on how 
best to proceed with a PR and whether my understanding of the invariant 
is correct.

*System*
FreeBSD 15.0-RELEASE releng/15.0-n280995-7aedc8de6446 GENERIC
(amd64, desktop system, KDE Plasma). Desktop is running in jail, non-root.

*Symptom*
Kernel panic / page fault in:

|inotify_log() mtx_lock(&vp->v_pollinfo->vpi_lock); |

At the time of the crash, |vp->v_pollinfo == NULL| (confirmed in kgdb).

*Reproducer (so far)*
On my system this can be triggered reliably by normal desktop interaction:

  *

    KDE Plasma running

  *

    clicking the digital clock/calendar widget (opening the panel) and
    clicking around repeatedly

  *

    more likely when inotify-heavy applications are active (e.g. Cursor
    / Electron-based apps)

*Observation*
|inotify_log()| assumes |vp->v_pollinfo| is non-NULL and dereferences it 
unconditionally.
A minimal local guard:

|if (vp->v_pollinfo == NULL) return; |

prevents the panic and restores system stability, but I do /not/ 
consider this a proper fix — it appears to mask a violated invariant or 
lifetime issue.

*Question*
Before filing a PR, I would appreciate guidance on:

  *

    whether |inotify_log()| is supposed to be callable when
    |vp->v_pollinfo| is NULL,

  *

    or whether this indicates a missing pollinfo creation / teardown
    ordering elsewhere,

  *

    and how maintainers would prefer this to be reported (PR vs
    discussion first)

I see the ongoing work on the subsystem in git logs and a cherry picked 
one of the patches (didn't help).

I can provide backtraces, event values, and additional context if useful.

Thank you for your time, and please let me know if I should proceed 
directly with a Bugzilla PR.

Best regards,
     Pavel