From: Mikulas Patocka <mpatocka@redhat.com>
To: kernel test robot <lkp@intel.com>
Cc: oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
John Garry <john.g.garry@oracle.com>
Subject: Re: drivers/md/dm.c:1324:9: sparse: sparse: cast from restricted blk_opf_t
Date: Wed, 18 Mar 2026 15:12:06 +0100 (CET) [thread overview]
Message-ID: <1d017f62-99b4-6293-d57d-4a3063b6f79e@redhat.com> (raw)
In-Reply-To: <202603181439.atBWgPQu-lkp@intel.com>
Hi
Could you please describe what's wrong here?
If I grep the kernel for 'bi_opf.*REQ_ATOMIC', there are 14 places where
bi_opf is tested or manipulated with the REQ_ATOMIC flag.
What should I use instead of 'bio->bi_opf & REQ_ATOMIC'?
Mikulas
On Wed, 18 Mar 2026, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: a989fde763f4f24209e4702f50a45be572340e68
> commit: de67c139b3846ece6b8bbb62abf1f010ae85c083 dm: test for REQ_ATOMIC in dm_accept_partial_bio()
> date: 3 months ago
> config: mips-randconfig-r113-20260318 (https://download.01.org/0day-ci/archive/20260318/202603181439.atBWgPQu-lkp@intel.com/config)
> compiler: mips-linux-gcc (GCC) 8.5.0
> sparse: v0.6.5-rc1
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260318/202603181439.atBWgPQu-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/202603181439.atBWgPQu-lkp@intel.com/
>
> sparse warnings: (new ones prefixed by >>)
> >> drivers/md/dm.c:1324:9: sparse: sparse: cast from restricted blk_opf_t
> drivers/md/dm.c:689:16: sparse: sparse: context imbalance in 'dm_get_live_table' - wrong count at exit
>
> vim +1324 drivers/md/dm.c
>
> 1283
> 1284 /*
> 1285 * A target may call dm_accept_partial_bio only from the map routine. It is
> 1286 * allowed for all bio types except REQ_PREFLUSH, REQ_OP_ZONE_* zone management
> 1287 * operations, zone append writes (native with REQ_OP_ZONE_APPEND or emulated
> 1288 * with write BIOs flagged with BIO_EMULATES_ZONE_APPEND) and any bio serviced
> 1289 * by __send_duplicate_bios().
> 1290 *
> 1291 * dm_accept_partial_bio informs the dm that the target only wants to process
> 1292 * additional n_sectors sectors of the bio and the rest of the data should be
> 1293 * sent in a next bio.
> 1294 *
> 1295 * A diagram that explains the arithmetics:
> 1296 * +--------------------+---------------+-------+
> 1297 * | 1 | 2 | 3 |
> 1298 * +--------------------+---------------+-------+
> 1299 *
> 1300 * <-------------- *tio->len_ptr --------------->
> 1301 * <----- bio_sectors ----->
> 1302 * <-- n_sectors -->
> 1303 *
> 1304 * Region 1 was already iterated over with bio_advance or similar function.
> 1305 * (it may be empty if the target doesn't use bio_advance)
> 1306 * Region 2 is the remaining bio size that the target wants to process.
> 1307 * (it may be empty if region 1 is non-empty, although there is no reason
> 1308 * to make it empty)
> 1309 * The target requires that region 3 is to be sent in the next bio.
> 1310 *
> 1311 * If the target wants to receive multiple copies of the bio (via num_*bios, etc),
> 1312 * the partially processed part (the sum of regions 1+2) must be the same for all
> 1313 * copies of the bio.
> 1314 */
> 1315 void dm_accept_partial_bio(struct bio *bio, unsigned int n_sectors)
> 1316 {
> 1317 struct dm_target_io *tio = clone_to_tio(bio);
> 1318 struct dm_io *io = tio->io;
> 1319 unsigned int bio_sectors = bio_sectors(bio);
> 1320
> 1321 BUG_ON(dm_tio_flagged(tio, DM_TIO_IS_DUPLICATE_BIO));
> 1322 BUG_ON(bio_sectors > *tio->len_ptr);
> 1323 BUG_ON(n_sectors > bio_sectors);
> > 1324 BUG_ON(bio->bi_opf & REQ_ATOMIC);
> 1325
> 1326 if (static_branch_unlikely(&zoned_enabled) &&
> 1327 unlikely(bdev_is_zoned(bio->bi_bdev))) {
> 1328 enum req_op op = bio_op(bio);
> 1329
> 1330 BUG_ON(op_is_zone_mgmt(op));
> 1331 BUG_ON(op == REQ_OP_WRITE);
> 1332 BUG_ON(op == REQ_OP_WRITE_ZEROES);
> 1333 BUG_ON(op == REQ_OP_ZONE_APPEND);
> 1334 }
> 1335
> 1336 *tio->len_ptr -= bio_sectors - n_sectors;
> 1337 bio->bi_iter.bi_size = n_sectors << SECTOR_SHIFT;
> 1338
> 1339 /*
> 1340 * __split_and_process_bio() may have already saved mapped part
> 1341 * for accounting but it is being reduced so update accordingly.
> 1342 */
> 1343 dm_io_set_flag(io, DM_IO_WAS_SPLIT);
> 1344 io->sectors = n_sectors;
> 1345 io->sector_offset = bio_sectors(io->orig_bio);
> 1346 }
> 1347 EXPORT_SYMBOL_GPL(dm_accept_partial_bio);
> 1348
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
>
next prev parent reply other threads:[~2026-03-18 14:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 6:49 kernel test robot
2026-03-18 14:12 ` Mikulas Patocka [this message]
2026-03-23 14:24 ` John Garry
2026-05-21 15:46 kernel test robot
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=1d017f62-99b4-6293-d57d-4a3063b6f79e@redhat.com \
--to=mpatocka@redhat.com \
--cc=john.g.garry@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--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
all inboxes | Powered by JetHome®