From: kernel test robot <lkp@intel.com>
To: kbuild@lists.01.org
Subject: Re: [PATCH alternative 2] block: fix the REQ_OP_SECURE_ERASE handling to not leak erased data
Date: Sat, 19 Mar 2022 06:31:44 +0800 [thread overview]
Message-ID: <202203190620.wyBlW8VG-lkp@intel.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 4218 bytes --]
CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
In-Reply-To: <20220316093855.GC7714@lst.de>
References: <20220316093855.GC7714@lst.de>
TO: Christoph Hellwig <hch@lst.de>
TO: axboe(a)kernel.dk
CC: jaegeuk(a)kernel.org
CC: chao(a)kernel.org
CC: ulf.hansson(a)linaro.org
CC: Adrian Hunter <adrian.hunter@intel.com>
CC: Daeho Jeong <daehojeong@google.com>
CC: Eric Biggers <ebiggers@google.com>
CC: linux-block(a)vger.kernel.org
CC: linux-kernel(a)vger.kernel.org
CC: linux-mmc(a)vger.kernel.org
Hi Christoph,
I love your patch! Perhaps something to improve:
[auto build test WARNING on jaegeuk-f2fs/dev-test]
[also build test WARNING on linux/master linus/master v5.17-rc8]
[cannot apply to axboe-block/for-next next-20220318]
[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]
url: https://github.com/0day-ci/linux/commits/Christoph-Hellwig/block-fix-the-REQ_OP_SECURE_ERASE-handling-to-not-leak-erased-data/20220316-174028
base: https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git dev-test
:::::: branch date: 3 days ago
:::::: commit date: 3 days ago
config: x86_64-randconfig-m001-20220314 (https://download.01.org/0day-ci/archive/20220319/202203190620.wyBlW8VG-lkp(a)intel.com/config)
compiler: gcc-9 (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
New smatch warnings:
block/blk-lib.c:464 blkdev_issue_secure_erase() warn: should 'len << 9' be a 64 bit type?
Old smatch warnings:
block/blk-lib.c:465 blkdev_issue_secure_erase() warn: should 'len << 9' be a 64 bit type?
vim +464 block/blk-lib.c
04d790607abc51e Christoph Hellwig 2022-03-16 436
04d790607abc51e Christoph Hellwig 2022-03-16 437 int blkdev_issue_secure_erase(struct block_device *bdev, sector_t sector,
04d790607abc51e Christoph Hellwig 2022-03-16 438 sector_t nr_sects, gfp_t gfp)
04d790607abc51e Christoph Hellwig 2022-03-16 439 {
04d790607abc51e Christoph Hellwig 2022-03-16 440 sector_t bs_mask = (bdev_logical_block_size(bdev) >> 9) - 1;
04d790607abc51e Christoph Hellwig 2022-03-16 441 unsigned int max_sectors =
04d790607abc51e Christoph Hellwig 2022-03-16 442 bdev_get_queue(bdev)->limits.max_discard_sectors;
04d790607abc51e Christoph Hellwig 2022-03-16 443 struct bio *bio = NULL;
04d790607abc51e Christoph Hellwig 2022-03-16 444 struct blk_plug plug;
04d790607abc51e Christoph Hellwig 2022-03-16 445 int ret = 0;
04d790607abc51e Christoph Hellwig 2022-03-16 446
04d790607abc51e Christoph Hellwig 2022-03-16 447 if (max_sectors == 0)
04d790607abc51e Christoph Hellwig 2022-03-16 448 return -EOPNOTSUPP;
04d790607abc51e Christoph Hellwig 2022-03-16 449 if ((sector | nr_sects) & bs_mask)
04d790607abc51e Christoph Hellwig 2022-03-16 450 return -EINVAL;
04d790607abc51e Christoph Hellwig 2022-03-16 451 if (bdev_read_only(bdev))
04d790607abc51e Christoph Hellwig 2022-03-16 452 return -EPERM;
04d790607abc51e Christoph Hellwig 2022-03-16 453
04d790607abc51e Christoph Hellwig 2022-03-16 454 blk_start_plug(&plug);
04d790607abc51e Christoph Hellwig 2022-03-16 455 for (;;) {
04d790607abc51e Christoph Hellwig 2022-03-16 456 unsigned int len = min_t(sector_t, nr_sects, max_sectors);
04d790607abc51e Christoph Hellwig 2022-03-16 457
04d790607abc51e Christoph Hellwig 2022-03-16 458 bio = blk_next_bio(bio, 0, gfp);
04d790607abc51e Christoph Hellwig 2022-03-16 459 bio_set_dev(bio, bdev);
04d790607abc51e Christoph Hellwig 2022-03-16 460 bio->bi_opf = REQ_OP_SECURE_ERASE;
04d790607abc51e Christoph Hellwig 2022-03-16 461 bio->bi_iter.bi_sector = sector;
04d790607abc51e Christoph Hellwig 2022-03-16 462 bio->bi_iter.bi_size = len;
04d790607abc51e Christoph Hellwig 2022-03-16 463
04d790607abc51e Christoph Hellwig 2022-03-16 @464 sector += len << SECTOR_SHIFT;
---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
next reply other threads:[~2022-03-18 22:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 22:31 kernel test robot [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-03-16 9:37 security issue: data exposure when using block layer secure erase Christoph Hellwig
2022-03-16 9:38 ` [PATCH alternative 2] block: fix the REQ_OP_SECURE_ERASE handling to not leak erased data Christoph Hellwig
2022-03-17 9:44 ` Ulf Hansson
2022-03-18 9:11 ` Christoph Hellwig
2022-03-18 10:36 ` Ulf Hansson
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=202203190620.wyBlW8VG-lkp@intel.com \
--to=lkp@intel.com \
--cc=kbuild@lists.01.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.