From: kernel test robot <lkp@intel.com>
To: Filipe Manana <fdmanana@suse.com>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
David Sterba <dsterba@suse.com>, Boris Burkov <boris@bur.io>
Subject: fs/btrfs/ordered-data.c:215:5-11: ERROR: allocation function on line 173 returns NULL not ERR_PTR on failure
Date: Tue, 17 Feb 2026 07:16:35 +0800 [thread overview]
Message-ID: <202602170751.qIgCJbJI-lkp@intel.com> (raw)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: 9702969978695d9a699a1f34771580cdbb153b33
commit: 08c649a5637371cb6bf8f3e974323cf59a7f434b btrfs: check we grabbed inode reference when allocating an ordered extent
date: 9 months ago
config: mips-randconfig-r064-20260215 (https://download.01.org/0day-ci/archive/20260217/202602170751.qIgCJbJI-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9b8addffa70cee5b2acc5454712d9cf78ce45710)
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/202602170751.qIgCJbJI-lkp@intel.com/
cocci warnings: (new ones prefixed by >>)
>> fs/btrfs/ordered-data.c:215:5-11: ERROR: allocation function on line 173 returns NULL not ERR_PTR on failure
vim +215 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 const bool is_nocow = (flags &
157 ((1U << BTRFS_ORDERED_NOCOW) | (1U << BTRFS_ORDERED_PREALLOC)));
158
159 if (is_nocow) {
160 /* For nocow write, we can release the qgroup rsv right now */
161 ret = btrfs_qgroup_free_data(inode, NULL, file_offset, num_bytes, &qgroup_rsv);
162 if (ret < 0)
163 return ERR_PTR(ret);
164 } else {
165 /*
166 * The ordered extent has reserved qgroup space, release now
167 * and pass the reserved number for qgroup_record to free.
168 */
169 ret = btrfs_qgroup_release_data(inode, file_offset, num_bytes, &qgroup_rsv);
170 if (ret < 0)
171 return ERR_PTR(ret);
172 }
> 173 entry = kmem_cache_zalloc(btrfs_ordered_extent_cache, GFP_NOFS);
174 if (!entry) {
175 entry = ERR_PTR(-ENOMEM);
176 goto out;
177 }
178
179 entry->file_offset = file_offset;
180 entry->num_bytes = num_bytes;
181 entry->ram_bytes = ram_bytes;
182 entry->disk_bytenr = disk_bytenr;
183 entry->disk_num_bytes = disk_num_bytes;
184 entry->offset = offset;
185 entry->bytes_left = num_bytes;
186 if (WARN_ON_ONCE(!igrab(&inode->vfs_inode))) {
187 kmem_cache_free(btrfs_ordered_extent_cache, entry);
188 entry = ERR_PTR(-ESTALE);
189 goto out;
190 }
191 entry->inode = inode;
192 entry->compress_type = compress_type;
193 entry->truncated_len = (u64)-1;
194 entry->qgroup_rsv = qgroup_rsv;
195 entry->flags = flags;
196 refcount_set(&entry->refs, 1);
197 init_waitqueue_head(&entry->wait);
198 INIT_LIST_HEAD(&entry->list);
199 INIT_LIST_HEAD(&entry->log_list);
200 INIT_LIST_HEAD(&entry->root_extent_list);
201 INIT_LIST_HEAD(&entry->work_list);
202 INIT_LIST_HEAD(&entry->bioc_list);
203 init_completion(&entry->completion);
204
205 /*
206 * We don't need the count_max_extents here, we can assume that all of
207 * that work has been done at higher layers, so this is truly the
208 * smallest the extent is going to get.
209 */
210 spin_lock(&inode->lock);
211 btrfs_mod_outstanding_extents(inode, 1);
212 spin_unlock(&inode->lock);
213
214 out:
> 215 if (IS_ERR(entry) && !is_nocow)
216 btrfs_qgroup_free_refroot(inode->root->fs_info,
217 btrfs_root_id(inode->root),
218 qgroup_rsv, BTRFS_QGROUP_RSV_DATA);
219
220 return entry;
221 }
222
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next reply other threads:[~2026-02-16 23:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-16 23:16 kernel test robot [this message]
2026-02-17 12:21 ` fs/btrfs/ordered-data.c:215:5-11: ERROR: allocation function on line 173 returns NULL not ERR_PTR on failure Filipe Manana
-- strict thread matches above, loose matches on Subject: below --
2026-01-02 4:10 kernel test robot
2026-01-05 11:29 ` Filipe Manana
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=202602170751.qIgCJbJI-lkp@intel.com \
--to=lkp@intel.com \
--cc=boris@bur.io \
--cc=dsterba@suse.com \
--cc=fdmanana@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
/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