From: kernel test robot <lkp@intel.com>
To: Milos Nikic <nikic.milos@gmail.com>, jack@suse.cz
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
tytso@mit.edu, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, Milos Nikic <nikic.milos@gmail.com>
Subject: Re: [PATCH v3 2/2] jbd2: gracefully abort on transaction state corruptions
Date: Tue, 3 Mar 2026 07:16:52 +0100 [thread overview]
Message-ID: <202603030706.NpyA7pqe-lkp@intel.com> (raw)
In-Reply-To: <20260303005502.337108-3-nikic.milos@gmail.com>
Hi Milos,
kernel test robot noticed the following build warnings:
[auto build test WARNING on brauner-vfs/vfs.all]
[also build test WARNING on tytso-ext4/dev next-20260302]
[cannot apply to linus/master v6.16-rc1]
[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/Milos-Nikic/jbd2-gracefully-abort-instead-of-panicking-on-unlocked-buffer/20260303-085946
base: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.all
patch link: https://lore.kernel.org/r/20260303005502.337108-3-nikic.milos%40gmail.com
patch subject: [PATCH v3 2/2] jbd2: gracefully abort on transaction state corruptions
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260303/202603030706.NpyA7pqe-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260303/202603030706.NpyA7pqe-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/202603030706.NpyA7pqe-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> fs/jbd2/transaction.c:1547:11: warning: variable 'journal' is uninitialized when used here [-Wuninitialized]
1547 | journal->j_devname, jh->b_transaction,
| ^~~~~~~
include/linux/printk.h:554:33: note: expanded from macro 'pr_err'
554 | printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~~~~~
include/linux/printk.h:511:60: note: expanded from macro 'printk'
511 | #define printk(fmt, ...) printk_index_wrap(_printk, fmt, ##__VA_ARGS__)
| ^~~~~~~~~~~
include/linux/printk.h:483:19: note: expanded from macro 'printk_index_wrap'
483 | _p_func(_fmt, ##__VA_ARGS__); \
| ^~~~~~~~~~~
fs/jbd2/transaction.c:1520:20: note: initialize the variable 'journal' to silence this warning
1520 | journal_t *journal;
| ^
| = NULL
1 warning generated.
vim +/journal +1547 fs/jbd2/transaction.c
1493
1494 /**
1495 * jbd2_journal_dirty_metadata() - mark a buffer as containing dirty metadata
1496 * @handle: transaction to add buffer to.
1497 * @bh: buffer to mark
1498 *
1499 * mark dirty metadata which needs to be journaled as part of the current
1500 * transaction.
1501 *
1502 * The buffer must have previously had jbd2_journal_get_write_access()
1503 * called so that it has a valid journal_head attached to the buffer
1504 * head.
1505 *
1506 * The buffer is placed on the transaction's metadata list and is marked
1507 * as belonging to the transaction.
1508 *
1509 * Returns error number or 0 on success.
1510 *
1511 * Special care needs to be taken if the buffer already belongs to the
1512 * current committing transaction (in which case we should have frozen
1513 * data present for that commit). In that case, we don't relink the
1514 * buffer: that only gets done when the old transaction finally
1515 * completes its commit.
1516 */
1517 int jbd2_journal_dirty_metadata(handle_t *handle, struct buffer_head *bh)
1518 {
1519 transaction_t *transaction = handle->h_transaction;
1520 journal_t *journal;
1521 struct journal_head *jh;
1522 int ret = 0;
1523
1524 if (!buffer_jbd(bh))
1525 return -EUCLEAN;
1526
1527 /*
1528 * We don't grab jh reference here since the buffer must be part
1529 * of the running transaction.
1530 */
1531 jh = bh2jh(bh);
1532 jbd2_debug(5, "journal_head %p\n", jh);
1533 JBUFFER_TRACE(jh, "entry");
1534
1535 /*
1536 * This and the following assertions are unreliable since we may see jh
1537 * in inconsistent state unless we grab bh_state lock. But this is
1538 * crucial to catch bugs so let's do a reliable check until the
1539 * lockless handling is fully proven.
1540 */
1541 if (data_race(jh->b_transaction != transaction &&
1542 jh->b_next_transaction != transaction)) {
1543 spin_lock(&jh->b_state_lock);
1544 if (WARN_ON_ONCE(jh->b_transaction != transaction &&
1545 jh->b_next_transaction != transaction)) {
1546 pr_err("JBD2: %s: assertion failure: b_transaction=%p transaction=%p b_next_transaction=%p\n",
> 1547 journal->j_devname, jh->b_transaction,
1548 transaction, jh->b_next_transaction);
1549 ret = -EINVAL;
1550 goto out_unlock_bh;
1551 }
1552 spin_unlock(&jh->b_state_lock);
1553 }
1554 if (data_race(jh->b_modified == 1)) {
1555 /* If it's in our transaction it must be in BJ_Metadata list. */
1556 if (data_race(jh->b_transaction == transaction &&
1557 jh->b_jlist != BJ_Metadata)) {
1558 spin_lock(&jh->b_state_lock);
1559 if (jh->b_transaction == transaction &&
1560 jh->b_jlist != BJ_Metadata)
1561 pr_err("JBD2: assertion failure: h_type=%u h_line_no=%u block_no=%llu jlist=%u\n",
1562 handle->h_type, handle->h_line_no,
1563 (unsigned long long) bh->b_blocknr,
1564 jh->b_jlist);
1565 if (WARN_ON_ONCE(jh->b_transaction == transaction &&
1566 jh->b_jlist != BJ_Metadata)) {
1567 ret = -EINVAL;
1568 goto out_unlock_bh;
1569 }
1570 spin_unlock(&jh->b_state_lock);
1571 }
1572 goto out;
1573 }
1574
1575 spin_lock(&jh->b_state_lock);
1576
1577 if (is_handle_aborted(handle)) {
1578 /*
1579 * Check journal aborting with @jh->b_state_lock locked,
1580 * since 'jh->b_transaction' could be replaced with
1581 * 'jh->b_next_transaction' during old transaction
1582 * committing if journal aborted, which may fail
1583 * assertion on 'jh->b_frozen_data == NULL'.
1584 */
1585 ret = -EROFS;
1586 goto out_unlock_bh;
1587 }
1588
1589 journal = transaction->t_journal;
1590
1591 if (jh->b_modified == 0) {
1592 /*
1593 * This buffer's got modified and becoming part
1594 * of the transaction. This needs to be done
1595 * once a transaction -bzzz
1596 */
1597 if (WARN_ON_ONCE(jbd2_handle_buffer_credits(handle) <= 0)) {
1598 ret = -ENOSPC;
1599 goto out_unlock_bh;
1600 }
1601 jh->b_modified = 1;
1602 handle->h_total_credits--;
1603 }
1604
1605 /*
1606 * fastpath, to avoid expensive locking. If this buffer is already
1607 * on the running transaction's metadata list there is nothing to do.
1608 * Nobody can take it off again because there is a handle open.
1609 * I _think_ we're OK here with SMP barriers - a mistaken decision will
1610 * result in this test being false, so we go in and take the locks.
1611 */
1612 if (jh->b_transaction == transaction && jh->b_jlist == BJ_Metadata) {
1613 JBUFFER_TRACE(jh, "fastpath");
1614 if (unlikely(jh->b_transaction !=
1615 journal->j_running_transaction)) {
1616 printk(KERN_ERR "JBD2: %s: "
1617 "jh->b_transaction (%llu, %p, %u) != "
1618 "journal->j_running_transaction (%p, %u)\n",
1619 journal->j_devname,
1620 (unsigned long long) bh->b_blocknr,
1621 jh->b_transaction,
1622 jh->b_transaction ? jh->b_transaction->t_tid : 0,
1623 journal->j_running_transaction,
1624 journal->j_running_transaction ?
1625 journal->j_running_transaction->t_tid : 0);
1626 ret = -EINVAL;
1627 }
1628 goto out_unlock_bh;
1629 }
1630
1631 set_buffer_jbddirty(bh);
1632
1633 /*
1634 * Metadata already on the current transaction list doesn't
1635 * need to be filed. Metadata on another transaction's list must
1636 * be committing, and will be refiled once the commit completes:
1637 * leave it alone for now.
1638 */
1639 if (jh->b_transaction != transaction) {
1640 JBUFFER_TRACE(jh, "already on other transaction");
1641 if (unlikely(((jh->b_transaction !=
1642 journal->j_committing_transaction)) ||
1643 (jh->b_next_transaction != transaction))) {
1644 printk(KERN_ERR "jbd2_journal_dirty_metadata: %s: "
1645 "bad jh for block %llu: "
1646 "transaction (%p, %u), "
1647 "jh->b_transaction (%p, %u), "
1648 "jh->b_next_transaction (%p, %u), jlist %u\n",
1649 journal->j_devname,
1650 (unsigned long long) bh->b_blocknr,
1651 transaction, transaction->t_tid,
1652 jh->b_transaction,
1653 jh->b_transaction ?
1654 jh->b_transaction->t_tid : 0,
1655 jh->b_next_transaction,
1656 jh->b_next_transaction ?
1657 jh->b_next_transaction->t_tid : 0,
1658 jh->b_jlist);
1659 WARN_ON(1);
1660 ret = -EINVAL;
1661 }
1662 /* And this case is illegal: we can't reuse another
1663 * transaction's data buffer, ever. */
1664 goto out_unlock_bh;
1665 }
1666
1667 /* That test should have eliminated the following case: */
1668 if (WARN_ON_ONCE(jh->b_frozen_data)) {
1669 ret = -EINVAL;
1670 goto out_unlock_bh;
1671 }
1672
1673 JBUFFER_TRACE(jh, "file as BJ_Metadata");
1674 spin_lock(&journal->j_list_lock);
1675 __jbd2_journal_file_buffer(jh, transaction, BJ_Metadata);
1676 spin_unlock(&journal->j_list_lock);
1677 out_unlock_bh:
1678 spin_unlock(&jh->b_state_lock);
1679 out:
1680 JBUFFER_TRACE(jh, "exit");
1681 return ret;
1682 }
1683
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2026-03-03 6:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 0:55 [PATCH v3 0/2] jbd2: audit and convert legacy J_ASSERT usage Milos Nikic
2026-03-03 0:55 ` [PATCH v3 1/2] jbd2: gracefully abort instead of panicking on unlocked buffer Milos Nikic
2026-03-03 1:05 ` Andreas Dilger
2026-03-03 0:55 ` [PATCH v3 2/2] jbd2: gracefully abort on transaction state corruptions Milos Nikic
2026-03-03 6:16 ` kernel test robot [this message]
2026-03-03 2:11 ` [PATCH v3 0/2] jbd2: audit and convert legacy J_ASSERT usage yebin (H)
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=202603030706.NpyA7pqe-lkp@intel.com \
--to=lkp@intel.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nikic.milos@gmail.com \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.