Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 Jul 2025 10:53:42 -0400
From:      Mark Johnston <markj@freebsd.org>
To:        Olivier Certner <olce@freebsd.org>
Cc:        Charlie Li <vishwin@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org
Subject:   Re: git: f1f230439fa4 - main - vfs: Initial revision of inotify
Message-ID:  <aHPIds_oMKXVBG8h@nuc>
In-Reply-To: <2937929.UcPf6a0QyJ@francois>
References:  <202507041455.564EtqwS073424@gitrepo.freebsd.org> <cc4b2cfb-3405-450a-855a-d1c157920404@freebsd.org> <2937929.UcPf6a0QyJ@francois>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 13, 2025 at 10:46:57PM +0900, Olivier Certner wrote:
> Hi Charlie,
> 
> The panic you're seeing is caused by 'MPASS(*eofflag != 0);' in vn_dir_next_dirent().  This test is here to check that VOP_READDIR() works properly.  In particular, if VOP_READDIR() returned 0 (no error), and the length it filled is 0 (nothing was added), then we must be at EOF, and VOP_READDIR() must have set '*eofflag' to something non-zero.  UFS has been verified to abide by this rule (unless the directory being read is malformed).  Which filesystem are you using?
> 
> Shot in the dark & educated guess: You're using ZFS, and you've just stumbled on the following case (lines from 'zfs_vnops_os.c'):
> 
>         /*                                                                                                                                                
>          * Quit if directory has been removed (posix)                                                                                                     
>          */
>         if ((*eofp = zp->z_unlinked) != 0) {
>                 zfs_exit(zfsvfs, FTAG);
>                 return (0);
>         }
> 
> which is a corner case that apparently has been missed.  Just add some 'if (eofflag != NULL) *eofflag = 1;' inside the "then" block there and retry.  It looks like all other cases in this function are handled correctly (but I have not thoroughly verified).

The store to *eofp sets eofflag, so that is not the problem.

Based on the presence of "efi" as a component name in the stack trace
that Charlie provided, I suspect the problem is rather in msdosfs, but I
don't immediately see what's wrong there.

> I'll be mostly AFK for the next 10 days, so probably won't be able to follow-up, but hope that will help.
> 
> Thanks and regards.
> 
> -- 
> Olivier Certner





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?aHPIds_oMKXVBG8h>