Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: kernel test robot <lkp@intel.com>
To: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH] btrfs: enhance ordered extent double freeing detection
Date: Thu, 12 Dec 2024 02:11:55 +0800	[thread overview]
Message-ID: <202412120136.6OwbbtZf-lkp@intel.com> (raw)
In-Reply-To: <53b793f2e7a7788f89cda97de565cfc1577cbf75.1733890357.git.wqu@suse.com>

Hi Qu,

kernel test robot noticed the following build errors:

[auto build test ERROR on kdave/for-next]
[also build test ERROR on linus/master v6.13-rc2 next-20241211]
[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/Qu-Wenruo/btrfs-enhance-ordered-extent-double-freeing-detection/20241211-121647
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
patch link:    https://lore.kernel.org/r/53b793f2e7a7788f89cda97de565cfc1577cbf75.1733890357.git.wqu%40suse.com
patch subject: [PATCH] btrfs: enhance ordered extent double freeing detection
config: i386-buildonly-randconfig-003-20241211 (https://download.01.org/0day-ci/archive/20241212/202412120136.6OwbbtZf-lkp@intel.com/config)
compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241212/202412120136.6OwbbtZf-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/202412120136.6OwbbtZf-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from fs/btrfs/ordered-data.c:7:
   In file included from include/linux/blkdev.h:9:
   In file included from include/linux/blk_types.h:10:
   In file included from include/linux/bvec.h:10:
   In file included from include/linux/highmem.h:8:
   In file included from include/linux/cacheflush.h:5:
   In file included from arch/x86/include/asm/cacheflush.h:5:
   In file included from include/linux/mm.h:2223:
   include/linux/vmstat.h:518:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion]
     518 |         return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_"
         |                               ~~~~~~~~~~~ ^ ~~~
>> fs/btrfs/ordered-data.c:200:10: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     200 |                 entry->finished_bitmap = bitmap_zalloc(
         |                 ~~~~~  ^
   fs/btrfs/ordered-data.c:202:15: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     202 |                 if (!entry->finished_bitmap) {
         |                      ~~~~~  ^
   fs/btrfs/ordered-data.c:380:38: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     380 |                 nr_set = bitmap_count_set(ordered->finished_bitmap, start_bit, nbits);
         |                                           ~~~~~~~  ^
   fs/btrfs/ordered-data.c:388:17: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     388 |                                    ordered->finished_bitmap);
         |                                    ~~~~~~~  ^
   fs/btrfs/messages.h:44:41: note: expanded from macro 'btrfs_crit'
      44 |         btrfs_printk(fs_info, KERN_CRIT fmt, ##args)
         |                                                ^~~~
   fs/btrfs/messages.h:27:32: note: expanded from macro 'btrfs_printk'
      27 |         _btrfs_printk(fs_info, fmt, ##args)
         |                                       ^~~~
   fs/btrfs/ordered-data.c:390:23: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     390 |                 bitmap_set(ordered->finished_bitmap, start_bit, nbits);
         |                            ~~~~~~~  ^
   fs/btrfs/ordered-data.c:418:37: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     418 |                 if (WARN_ON(!bitmap_full(ordered->finished_bitmap,
         |                                          ~~~~~~~  ^
   include/asm-generic/bug.h:123:25: note: expanded from macro 'WARN_ON'
     123 |         int __ret_warn_on = !!(condition);                              \
         |                                ^~~~~~~~~
   fs/btrfs/ordered-data.c:426:14: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     426 |                                 ordered->finished_bitmap);
         |                                 ~~~~~~~  ^
   fs/btrfs/messages.h:44:41: note: expanded from macro 'btrfs_crit'
      44 |         btrfs_printk(fs_info, KERN_CRIT fmt, ##args)
         |                                                ^~~~
   fs/btrfs/messages.h:27:32: note: expanded from macro 'btrfs_printk'
      27 |         _btrfs_printk(fs_info, fmt, ##args)
         |                                       ^~~~
   fs/btrfs/ordered-data.c:675:23: error: no member named 'finished_bitmap' in 'struct btrfs_ordered_extent'
     675 |                         bitmap_free(entry->finished_bitmap);
         |                                     ~~~~~  ^
   1 warning and 8 errors generated.


vim +200 fs/btrfs/ordered-data.c

   147	
   148	static struct btrfs_ordered_extent *alloc_ordered_extent(
   149				struct btrfs_inode *inode, u64 file_offset, u64 num_bytes,
   150				u64 ram_bytes, u64 disk_bytenr, u64 disk_num_bytes,
   151				u64 offset, unsigned long flags, int compress_type)
   152	{
   153		struct btrfs_ordered_extent *entry;
   154		int ret;
   155		u64 qgroup_rsv = 0;
   156	
   157		if (flags &
   158		    ((1 << BTRFS_ORDERED_NOCOW) | (1 << BTRFS_ORDERED_PREALLOC))) {
   159			/* For nocow write, we can release the qgroup rsv right now */
   160			ret = btrfs_qgroup_free_data(inode, NULL, file_offset, num_bytes, &qgroup_rsv);
   161			if (ret < 0)
   162				return ERR_PTR(ret);
   163		} else {
   164			/*
   165			 * The ordered extent has reserved qgroup space, release now
   166			 * and pass the reserved number for qgroup_record to free.
   167			 */
   168			ret = btrfs_qgroup_release_data(inode, file_offset, num_bytes, &qgroup_rsv);
   169			if (ret < 0)
   170				return ERR_PTR(ret);
   171		}
   172		entry = kmem_cache_zalloc(btrfs_ordered_extent_cache, GFP_NOFS);
   173		if (!entry)
   174			return ERR_PTR(-ENOMEM);
   175	
   176		entry->file_offset = file_offset;
   177		entry->num_bytes = num_bytes;
   178		entry->ram_bytes = ram_bytes;
   179		entry->disk_bytenr = disk_bytenr;
   180		entry->disk_num_bytes = disk_num_bytes;
   181		entry->offset = offset;
   182		entry->bytes_left = num_bytes;
   183		entry->inode = BTRFS_I(igrab(&inode->vfs_inode));
   184		entry->compress_type = compress_type;
   185		entry->truncated_len = (u64)-1;
   186		entry->qgroup_rsv = qgroup_rsv;
   187		entry->flags = flags;
   188		refcount_set(&entry->refs, 1);
   189		init_waitqueue_head(&entry->wait);
   190		INIT_LIST_HEAD(&entry->list);
   191		INIT_LIST_HEAD(&entry->log_list);
   192		INIT_LIST_HEAD(&entry->root_extent_list);
   193		INIT_LIST_HEAD(&entry->work_list);
   194		INIT_LIST_HEAD(&entry->bioc_list);
   195		init_completion(&entry->completion);
   196	
   197		if (IS_ENABLED(CONFIG_BTRFS_DEBUG)) {
   198			struct btrfs_fs_info *fs_info = inode->root->fs_info;
   199	
 > 200			entry->finished_bitmap = bitmap_zalloc(
   201				num_bytes >> fs_info->sectorsize_bits, GFP_NOFS);
   202			if (!entry->finished_bitmap) {
   203				kmem_cache_free(btrfs_ordered_extent_cache, entry);
   204				return ERR_PTR(-ENOMEM);
   205			}
   206		}
   207		/*
   208		 * We don't need the count_max_extents here, we can assume that all of
   209		 * that work has been done at higher layers, so this is truly the
   210		 * smallest the extent is going to get.
   211		 */
   212		spin_lock(&inode->lock);
   213		btrfs_mod_outstanding_extents(inode, 1);
   214		spin_unlock(&inode->lock);
   215	
   216		return entry;
   217	}
   218	

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

       reply	other threads:[~2024-12-11 18:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53b793f2e7a7788f89cda97de565cfc1577cbf75.1733890357.git.wqu@suse.com>
2024-12-11 18:11 ` kernel test robot [this message]
2024-12-11 19:47   ` [PATCH] btrfs: enhance ordered extent double freeing detection Qu Wenruo
2024-12-11 21:26     ` David Sterba

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=202412120136.6OwbbtZf-lkp@intel.com \
    --to=lkp@intel.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=wqu@suse.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