Skip site navigation (1)Skip section navigation (2) 
Date:      Sat, 10 Jan 2026 14:40:49 +0400
From:      Pavel Perikov <perikov@gmail.com>
To:        freebsd-bugs@FreeBSD.org
Subject:   =?UTF-8?Q?15=2E0-RELEASE_panic_in_inotify=5Flog=28=29=3A_vp-=3Ev=5F?= =?UTF-8?Q?pollinfo_=3D=3D_NULL_=E2=80=94_advice_on_PR_/_invariant?=
Message-ID:  <25523ec1-3780-4638-ad5c-440ec39eedc0@gmail.com>
index | next in thread | raw e-mail 

[-- Attachment #1 --]
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


[-- Attachment #2 --]
<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello,</p>
    <p>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.</p>
    <p><strong>System</strong><br>
      FreeBSD 15.0-RELEASE releng/15.0-n280995-7aedc8de6446 GENERIC<br>
      (amd64, desktop system, KDE Plasma). Desktop is running in jail,
      non-root.</p>
    <p><strong>Symptom</strong><br>
      Kernel panic / page fault in:</p>
    <pre><code>inotify_log()
  mtx_lock(&amp;vp-&gt;v_pollinfo-&gt;vpi_lock);
</code></pre>
    <p>At the time of the crash, <code>vp-&gt;v_pollinfo == NULL</code>
      (confirmed in kgdb).</p>
    <p><strong>Reproducer (so far)</strong><br>
      On my system this can be triggered reliably by normal desktop
      interaction:</p>
    <ul>
      <li>
        <p>KDE Plasma running</p>
      </li>
      <li>
        <p>clicking the digital clock/calendar widget (opening the
          panel) and clicking around repeatedly</p>
      </li>
      <li>
        <p>more likely when inotify-heavy applications are active (e.g.
          Cursor / Electron-based apps)</p>
      </li>
    </ul>
    <p><strong>Observation</strong><br>
      <code>inotify_log()</code> assumes <code>vp-&gt;v_pollinfo</code>
      is non-NULL and dereferences it unconditionally.<br>
      A minimal local guard:</p>
    <pre><code class="language-c">if (vp-&gt;v_pollinfo == NULL)
        return;
</code></pre>
    <p>prevents the panic and restores system stability, but I do <em>not</em>
      consider this a proper fix — it appears to mask a violated
      invariant or lifetime issue.</p>
    <p><strong>Question</strong><br>
      Before filing a PR, I would appreciate guidance on:</p>
    <ul>
      <li>
        <p>whether <code>inotify_log()</code> is supposed to be
          callable when <code>vp-&gt;v_pollinfo</code> is NULL,</p>
      </li>
      <li>
        <p>or whether this indicates a missing pollinfo creation /
          teardown ordering elsewhere,</p>
      </li>
      <li>
        <p>and how maintainers would prefer this to be reported (PR vs
          discussion first)</p>
      </li>
    </ul>
    <p>I see the ongoing work on the subsystem in git logs and a cherry
      picked one of the patches (didn't help).</p>
    <p>I can provide backtraces, event values, and additional context if
      useful.</p>
    <p>Thank you for your time, and please let me know if I should
      proceed directly with a Bugzilla PR.</p>
    <p>Best regards,<br>
          Pavel</p>
    <p><br>
    </p>
  </body>
</html>
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25523ec1-3780-4638-ad5c-440ec39eedc0>