mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: kbuild-all@lists.01.org, linux-kernel@vger.kernel.org
Subject: [norov:bitmap-20210716 15/17] fs/btrfs/extent_io.c:3809:2: error: implicit declaration of function 'bitmap_next_set_region'; did you mean 'bitmap_release_region'?
Date: Mon, 19 Jul 2021 13:13:51 +0800	[thread overview]
Message-ID: <202107191341.dEhiyILv-lkp@intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 5778 bytes --]

tree:   https://github.com/norov/linux bitmap-20210716
head:   8ac80f856c70d69f310de6215244b6aaeb22d5b9
commit: a2d6e02d19450a49a55f08c151d1f704723bec1a [15/17] bitmap: unify find_bit operations
config: nios2-randconfig-r031-20210719 (attached as .config)
compiler: nios2-linux-gcc (GCC) 10.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/norov/linux/commit/a2d6e02d19450a49a55f08c151d1f704723bec1a
        git remote add norov https://github.com/norov/linux
        git fetch --no-tags norov bitmap-20210716
        git checkout a2d6e02d19450a49a55f08c151d1f704723bec1a
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross ARCH=nios2 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   fs/btrfs/extent_io.c: In function 'find_next_dirty_byte':
>> fs/btrfs/extent_io.c:3809:2: error: implicit declaration of function 'bitmap_next_set_region'; did you mean 'bitmap_release_region'? [-Werror=implicit-function-declaration]
    3809 |  bitmap_next_set_region(&dirty_bitmap, &range_start_bit, &range_end_bit,
         |  ^~~~~~~~~~~~~~~~~~~~~~
         |  bitmap_release_region
   cc1: some warnings being treated as errors


vim +3809 fs/btrfs/extent_io.c

40f765805f082e Chris Mason 2014-05-21  3766  
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3767  /*
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3768   * Find the first byte we need to write.
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3769   *
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3770   * For subpage, one page can contain several sectors, and
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3771   * __extent_writepage_io() will just grab all extent maps in the page
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3772   * range and try to submit all non-inline/non-compressed extents.
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3773   *
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3774   * This is a big problem for subpage, we shouldn't re-submit already written
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3775   * data at all.
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3776   * This function will lookup subpage dirty bit to find which range we really
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3777   * need to submit.
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3778   *
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3779   * Return the next dirty range in [@start, @end).
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3780   * If no dirty range is found, @start will be page_offset(page) + PAGE_SIZE.
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3781   */
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3782  static void find_next_dirty_byte(struct btrfs_fs_info *fs_info,
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3783  				 struct page *page, u64 *start, u64 *end)
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3784  {
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3785  	struct btrfs_subpage *subpage = (struct btrfs_subpage *)page->private;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3786  	u64 orig_start = *start;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3787  	/* Declare as unsigned long so we can use bitmap ops */
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3788  	unsigned long dirty_bitmap;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3789  	unsigned long flags;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3790  	int nbits = (orig_start - page_offset(page)) >> fs_info->sectorsize_bits;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3791  	int range_start_bit = nbits;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3792  	int range_end_bit;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3793  
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3794  	/*
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3795  	 * For regular sector size == page size case, since one page only
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3796  	 * contains one sector, we return the page offset directly.
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3797  	 */
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3798  	if (fs_info->sectorsize == PAGE_SIZE) {
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3799  		*start = page_offset(page);
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3800  		*end = page_offset(page) + PAGE_SIZE;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3801  		return;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3802  	}
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3803  
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3804  	/* We should have the page locked, but just in case */
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3805  	spin_lock_irqsave(&subpage->lock, flags);
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3806  	dirty_bitmap = subpage->dirty_bitmap;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3807  	spin_unlock_irqrestore(&subpage->lock, flags);
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3808  
c5ef5c6c733a08 Qu Wenruo   2021-05-31 @3809  	bitmap_next_set_region(&dirty_bitmap, &range_start_bit, &range_end_bit,
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3810  			       BTRFS_SUBPAGE_BITMAP_SIZE);
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3811  	*start = page_offset(page) + range_start_bit * fs_info->sectorsize;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3812  	*end = page_offset(page) + range_end_bit * fs_info->sectorsize;
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3813  }
c5ef5c6c733a08 Qu Wenruo   2021-05-31  3814  

:::::: The code at line 3809 was first introduced by commit
:::::: c5ef5c6c733a087fc3f8b298010d7e6911bff1e3 btrfs: make __extent_writepage_io() only submit dirty range for subpage

:::::: TO: Qu Wenruo <wqu@suse.com>
:::::: CC: David Sterba <dsterba@suse.com>

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28624 bytes --]

                 reply	other threads:[~2021-07-19  5:14 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=202107191341.dEhiyILv-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yury.norov@gmail.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

all inboxes | Powered by JetHome®