Re: misc-next 6a43055c266e: assertion failed: ret != -EEXIST, in fs/btrfs/tree-log.c:3857

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Mon, May 02, 2022 at 10:25:58AM +0100, Filipe Manana wrote:
> On Fri, Apr 29, 2022 at 10:27:08PM -0400, Zygo Blaxell wrote:
> > Running my usual "run everything at once" test...
> > 
> > 	assertion failed: ret != -EEXIST, in fs/btrfs/tree-log.c:3857
> > 	[198255.980839][ T7460] ------------[ cut here ]------------
> > 	[198255.981666][ T7460] kernel BUG at fs/btrfs/ctree.h:3617!
> > 	[198255.983141][ T7460] invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
> > 	[198255.984080][ T7460] CPU: 0 PID: 7460 Comm: repro-ghost-dir Not tainted 5.18.0-5314c78ac373-misc-next+ #159 9f66820f9a8b6f20d808b7fbd7aaeab2c04eefe1
> 
> This is a bit confusing, the subject mentions 6a43055c266e, but here
> we see 5314c78ac373 and 9f66820f9a8b6f20d808b7fbd7aaeab2c04eefe1.

6a43055c266e from the subject line is the misc-next commit for btrfs.

5314c78ac373 from the kernel log is the git commit of the test kernel.
It's the misc-next tree with a commit on top to record the build
configuration.

9f66820f9a8b6f20d808b7fbd7aaeab2c04eefe1 is the GCC build ID for
debuginfod lookup, which would have been really convenient if it had
existed years ago when I had to roll my own infrastructure for mapping
kernel version strings back to specific build metadata.

> >    3847                         if (key.offset > *last_old_dentry_offset + 1) {
> >    3848                                 ret = insert_dir_log_key(trans, log, dst_path,
> >    3849                                                  ino, *last_old_dentry_offset + 1,
> >    3850                                                  key.offset - 1);
> >    3851                                 /*
> >    3852                                  * -EEXIST should never happen because when we
> >    3853                                  * log a directory in full mode (LOG_INODE_ALL)
> >    3854                                  * we drop all BTRFS_DIR_LOG_INDEX_KEY keys from
> >    3855                                  * the log tree.
> >    3856                                  */
> >   >3857<                                ASSERT(ret != -EEXIST);
> 
> It can actually happen, there's a harmless race between logging a directory
> and inserting items from other inodes into a subvolume's tree that can result
> in an attempt to log the same BTRFS_DIR_LOG_INDEX_KEY twice.
> 
> I'll fix that and send a patch soon.
> Thanks.

Cool.  Thanks!

> >    3858                                 if (ret < 0)
> >    3859                                         return ret;
> >    3860                         }
> >