oe-kbuild-all.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: oe-kbuild-all@lists.linux.dev
Subject: Re: [RFC v4 linux-next 19/19] fs & block: remove bdev->bd_inode
Date: Sun, 25 Feb 2024 08:06:48 +0800	[thread overview]
Message-ID: <202402250747.57bivGGZ-lkp@intel.com> (raw)
In-Reply-To: <20240222124555.2049140-20-yukuai1@huaweicloud.com>

Hi Yu,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build warnings:

[auto build test WARNING on next-20240221]

url:    https://github.com/intel-lab-lkp/linux/commits/Yu-Kuai/block-move-two-helpers-into-bdev-c/20240222-205510
base:   next-20240221
patch link:    https://lore.kernel.org/r/20240222124555.2049140-20-yukuai1%40huaweicloud.com
patch subject: [RFC v4 linux-next 19/19] fs & block: remove bdev->bd_inode
config: i386-buildonly-randconfig-002-20240225 (https://download.01.org/0day-ci/archive/20240225/202402250747.57bivGGZ-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240225/202402250747.57bivGGZ-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/202402250747.57bivGGZ-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> fs/buffer.c:1702: warning: Function parameter or struct member 'bd_inode' not described in '__clean_bdev_aliases'
>> fs/buffer.c:1702: warning: Excess function parameter 'inode' description in '__clean_bdev_aliases'


vim +1702 fs/buffer.c

^1da177e4c3f41 Linus Torvalds          2005-04-16  1680  
29f3ad7d838036 Jan Kara                2016-11-04  1681  /**
666c7b98061c32 Yu Kuai                 2024-02-22  1682   * __clean_bdev_aliases: clean a range of buffers in block device
666c7b98061c32 Yu Kuai                 2024-02-22  1683   * @inode: Block device inode to clean buffers in
29f3ad7d838036 Jan Kara                2016-11-04  1684   * @block: Start of a range of blocks to clean
29f3ad7d838036 Jan Kara                2016-11-04  1685   * @len: Number of blocks to clean
29f3ad7d838036 Jan Kara                2016-11-04  1686   *
29f3ad7d838036 Jan Kara                2016-11-04  1687   * We are taking a range of blocks for data and we don't want writeback of any
29f3ad7d838036 Jan Kara                2016-11-04  1688   * buffer-cache aliases starting from return from this function and until the
29f3ad7d838036 Jan Kara                2016-11-04  1689   * moment when something will explicitly mark the buffer dirty (hopefully that
29f3ad7d838036 Jan Kara                2016-11-04  1690   * will not happen until we will free that block ;-) We don't even need to mark
29f3ad7d838036 Jan Kara                2016-11-04  1691   * it not-uptodate - nobody can expect anything from a newly allocated buffer
29f3ad7d838036 Jan Kara                2016-11-04  1692   * anyway. We used to use unmap_buffer() for such invalidation, but that was
29f3ad7d838036 Jan Kara                2016-11-04  1693   * wrong. We definitely don't want to mark the alias unmapped, for example - it
29f3ad7d838036 Jan Kara                2016-11-04  1694   * would confuse anyone who might pick it with bread() afterwards...
29f3ad7d838036 Jan Kara                2016-11-04  1695   *
29f3ad7d838036 Jan Kara                2016-11-04  1696   * Also..  Note that bforget() doesn't lock the buffer.  So there can be
29f3ad7d838036 Jan Kara                2016-11-04  1697   * writeout I/O going on against recently-freed buffers.  We don't wait on that
29f3ad7d838036 Jan Kara                2016-11-04  1698   * I/O in bforget() - it's more efficient to wait on the I/O only if we really
29f3ad7d838036 Jan Kara                2016-11-04  1699   * need to.  That happens here.
29f3ad7d838036 Jan Kara                2016-11-04  1700   */
666c7b98061c32 Yu Kuai                 2024-02-22  1701  void __clean_bdev_aliases(struct inode *bd_inode, sector_t block, sector_t len)
^1da177e4c3f41 Linus Torvalds          2005-04-16 @1702  {
29f3ad7d838036 Jan Kara                2016-11-04  1703  	struct address_space *bd_mapping = bd_inode->i_mapping;
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1704) 	struct folio_batch fbatch;
4b04646caed544 Matthew Wilcox (Oracle  2023-11-09  1705) 	pgoff_t index = ((loff_t)block << bd_inode->i_blkbits) / PAGE_SIZE;
29f3ad7d838036 Jan Kara                2016-11-04  1706  	pgoff_t end;
c10f778ddfc161 Jan Kara                2017-09-06  1707  	int i, count;
29f3ad7d838036 Jan Kara                2016-11-04  1708  	struct buffer_head *bh;
29f3ad7d838036 Jan Kara                2016-11-04  1709  	struct buffer_head *head;
^1da177e4c3f41 Linus Torvalds          2005-04-16  1710  
4b04646caed544 Matthew Wilcox (Oracle  2023-11-09  1711) 	end = ((loff_t)(block + len - 1) << bd_inode->i_blkbits) / PAGE_SIZE;
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1712) 	folio_batch_init(&fbatch);
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1713) 	while (filemap_get_folios(bd_mapping, &index, end, &fbatch)) {
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1714) 		count = folio_batch_count(&fbatch);
c10f778ddfc161 Jan Kara                2017-09-06  1715  		for (i = 0; i < count; i++) {
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1716) 			struct folio *folio = fbatch.folios[i];
^1da177e4c3f41 Linus Torvalds          2005-04-16  1717  
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1718) 			if (!folio_buffers(folio))
29f3ad7d838036 Jan Kara                2016-11-04  1719  				continue;
29f3ad7d838036 Jan Kara                2016-11-04  1720  			/*
600f111ef51dc2 Matthew Wilcox (Oracle  2023-11-17  1721) 			 * We use folio lock instead of bd_mapping->i_private_lock
29f3ad7d838036 Jan Kara                2016-11-04  1722  			 * to pin buffers here since we can afford to sleep and
29f3ad7d838036 Jan Kara                2016-11-04  1723  			 * it scales better than a global spinlock lock.
29f3ad7d838036 Jan Kara                2016-11-04  1724  			 */
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1725) 			folio_lock(folio);
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1726) 			/* Recheck when the folio is locked which pins bhs */
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1727) 			head = folio_buffers(folio);
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1728) 			if (!head)
29f3ad7d838036 Jan Kara                2016-11-04  1729  				goto unlock_page;
29f3ad7d838036 Jan Kara                2016-11-04  1730  			bh = head;
29f3ad7d838036 Jan Kara                2016-11-04  1731  			do {
6c006a9d94bfb5 Chandan Rajendra        2016-12-25  1732  				if (!buffer_mapped(bh) || (bh->b_blocknr < block))
29f3ad7d838036 Jan Kara                2016-11-04  1733  					goto next;
29f3ad7d838036 Jan Kara                2016-11-04  1734  				if (bh->b_blocknr >= block + len)
29f3ad7d838036 Jan Kara                2016-11-04  1735  					break;
29f3ad7d838036 Jan Kara                2016-11-04  1736  				clear_buffer_dirty(bh);
29f3ad7d838036 Jan Kara                2016-11-04  1737  				wait_on_buffer(bh);
29f3ad7d838036 Jan Kara                2016-11-04  1738  				clear_buffer_req(bh);
29f3ad7d838036 Jan Kara                2016-11-04  1739  next:
29f3ad7d838036 Jan Kara                2016-11-04  1740  				bh = bh->b_this_page;
29f3ad7d838036 Jan Kara                2016-11-04  1741  			} while (bh != head);
29f3ad7d838036 Jan Kara                2016-11-04  1742  unlock_page:
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1743) 			folio_unlock(folio);
29f3ad7d838036 Jan Kara                2016-11-04  1744  		}
9e0b6f31bae664 Matthew Wilcox (Oracle  2022-06-04  1745) 		folio_batch_release(&fbatch);
29f3ad7d838036 Jan Kara                2016-11-04  1746  		cond_resched();
c10f778ddfc161 Jan Kara                2017-09-06  1747  		/* End of range already reached? */
c10f778ddfc161 Jan Kara                2017-09-06  1748  		if (index > end || !index)
c10f778ddfc161 Jan Kara                2017-09-06  1749  			break;
^1da177e4c3f41 Linus Torvalds          2005-04-16  1750  	}
^1da177e4c3f41 Linus Torvalds          2005-04-16  1751  }
666c7b98061c32 Yu Kuai                 2024-02-22  1752  EXPORT_SYMBOL(__clean_bdev_aliases);
^1da177e4c3f41 Linus Torvalds          2005-04-16  1753  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

           reply	other threads:[~2024-02-25  0:07 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <20240222124555.2049140-20-yukuai1@huaweicloud.com>]

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=202402250747.57bivGGZ-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=yukuai1@huaweicloud.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;
as well as URLs for NNTP newsgroup(s).