From: kernel test robot <lkp@intel.com>
To: Haoqin Huang <haoqinhuang7@gmail.com>,
chandan.babu@oracle.com, djwong@kernel.org,
linux-xfs@vger.kernel.org
Cc: oe-kbuild-all@lists.linux.dev,
Haoqin Huang <haoqinhuang@tencent.com>,
Rongwei Wang <zigiwang@tencent.com>
Subject: Re: [PATCH] xfs: fix deadlock between busy flushing and t_busy
Date: Sat, 15 Nov 2025 23:50:58 +0800 [thread overview]
Message-ID: <202511152332.yaXc6tmQ-lkp@intel.com> (raw)
In-Reply-To: <20251114152147.66688-1-haoqinhuang7@gmail.com>
Hi Haoqin,
kernel test robot noticed the following build errors:
[auto build test ERROR on xfs-linux/for-next]
[also build test ERROR on linus/master v6.18-rc5 next-20251114]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Haoqin-Huang/xfs-fix-deadlock-between-busy-flushing-and-t_busy/20251115-002142
base: https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git for-next
patch link: https://lore.kernel.org/r/20251114152147.66688-1-haoqinhuang7%40gmail.com
patch subject: [PATCH] xfs: fix deadlock between busy flushing and t_busy
config: m68k-mac_defconfig (https://download.01.org/0day-ci/archive/20251115/202511152332.yaXc6tmQ-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251115/202511152332.yaXc6tmQ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511152332.yaXc6tmQ-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from <command-line>:
fs/xfs/xfs_extent_busy.c: In function 'xfs_extent_busy_flush':
>> fs/xfs/xfs_extent_busy.c:639:59: error: 'pag' undeclared (first use in this function); did you mean 'page'?
639 | if (!alloc_flags && busy_gen == READ_ONCE(pag->pagb_gen))
| ^~~
include/linux/compiler_types.h:577:23: note: in definition of macro '__compiletime_assert'
577 | if (!(condition)) \
| ^~~~~~~~~
include/linux/compiler_types.h:597:9: note: in expansion of macro '_compiletime_assert'
597 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:36:9: note: in expansion of macro 'compiletime_assert'
36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
| ^~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:36:28: note: in expansion of macro '__native_word'
36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
| ^~~~~~~~~~~~~
include/asm-generic/rwonce.h:49:9: note: in expansion of macro 'compiletime_assert_rwonce_type'
49 | compiletime_assert_rwonce_type(x); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/xfs/xfs_extent_busy.c:639:49: note: in expansion of macro 'READ_ONCE'
639 | if (!alloc_flags && busy_gen == READ_ONCE(pag->pagb_gen))
| ^~~~~~~~~
fs/xfs/xfs_extent_busy.c:639:59: note: each undeclared identifier is reported only once for each function it appears in
639 | if (!alloc_flags && busy_gen == READ_ONCE(pag->pagb_gen))
| ^~~
include/linux/compiler_types.h:577:23: note: in definition of macro '__compiletime_assert'
577 | if (!(condition)) \
| ^~~~~~~~~
include/linux/compiler_types.h:597:9: note: in expansion of macro '_compiletime_assert'
597 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:36:9: note: in expansion of macro 'compiletime_assert'
36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
| ^~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:36:28: note: in expansion of macro '__native_word'
36 | compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long long), \
| ^~~~~~~~~~~~~
include/asm-generic/rwonce.h:49:9: note: in expansion of macro 'compiletime_assert_rwonce_type'
49 | compiletime_assert_rwonce_type(x); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fs/xfs/xfs_extent_busy.c:639:49: note: in expansion of macro 'READ_ONCE'
639 | if (!alloc_flags && busy_gen == READ_ONCE(pag->pagb_gen))
| ^~~~~~~~~
vim +639 fs/xfs/xfs_extent_busy.c
594
595 /*
596 * Flush out all busy extents for this group.
597 *
598 * If the current transaction is holding busy extents, the caller may not want
599 * to wait for committed busy extents to resolve. If we are being told just to
600 * try a flush or progress has been made since we last skipped a busy extent,
601 * return immediately to allow the caller to try again.
602 *
603 * If we are freeing extents, we might actually be holding the only free extents
604 * in the transaction busy list and the log force won't resolve that situation.
605 * In this case, we must return -EAGAIN to avoid a deadlock by informing the
606 * caller it needs to commit the busy extents it holds before retrying the
607 * extent free operation.
608 */
609 int
610 xfs_extent_busy_flush(
611 struct xfs_trans *tp,
612 struct xfs_group *xg,
613 unsigned busy_gen,
614 uint32_t alloc_flags)
615 {
616 struct xfs_extent_busy_tree *eb = xg->xg_busy_extents;
617 DEFINE_WAIT (wait);
618 int error;
619
620 error = xfs_log_force(tp->t_mountp, XFS_LOG_SYNC);
621 if (error)
622 return error;
623
624 /* Avoid deadlocks on uncommitted busy extents. */
625 if (!list_empty(&tp->t_busy)) {
626 if (alloc_flags & XFS_ALLOC_FLAG_TRYFLUSH)
627 return 0;
628
629 if (busy_gen != READ_ONCE(eb->eb_gen))
630 return 0;
631
632 if (alloc_flags & XFS_ALLOC_FLAG_FREEING)
633 return -EAGAIN;
634
635 /*
636 * To avoid deadlocks if alloc_flags without any FLAG set
637 * and t_busy is not empty.
638 */
> 639 if (!alloc_flags && busy_gen == READ_ONCE(pag->pagb_gen))
640 return -EAGAIN;
641 }
642
643 /* Wait for committed busy extents to resolve. */
644 do {
645 prepare_to_wait(&eb->eb_wait, &wait, TASK_KILLABLE);
646 if (busy_gen != READ_ONCE(eb->eb_gen))
647 break;
648 schedule();
649 } while (1);
650
651 finish_wait(&eb->eb_wait, &wait);
652 return 0;
653 }
654
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2025-11-15 15:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 15:21 [PATCH] xfs: fix deadlock between busy flushing and t_busy Haoqin Huang
2025-11-15 15:50 ` kernel test robot
2025-11-15 15:50 ` kernel test robot [this message]
2025-11-16 13:03 ` Dave Chinner
2025-11-22 9:41 ` haoqin huang
2025-11-24 4:13 ` Jinliang Zheng
2025-11-24 7:07 ` haoqin huang
[not found] ` <CAEjiKSmvzr1M-2=5SPA0hQo1-442t-_zLB3zBj1jqWoZ0tMCUQ@mail.gmail.com>
2025-11-24 21:18 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202511152332.yaXc6tmQ-lkp@intel.com \
--to=lkp@intel.com \
--cc=chandan.babu@oracle.com \
--cc=djwong@kernel.org \
--cc=haoqinhuang7@gmail.com \
--cc=haoqinhuang@tencent.com \
--cc=linux-xfs@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=zigiwang@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox