| Message ID | 1446628721-11030-1-git-send-email-jack@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Jan,
[auto build test ERROR on: ext3/for_next]
[cannot apply to: v4.3 next-20151103]
url: https://github.com/0day-ci/linux/commits/Jan-Kara/block-Don-t-allow-illegal-discard-requests/20151104-172203
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
config: arm-prima2_defconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
block/built-in.o: In function `blkdev_issue_discard':
>> block/blk-lib.c:67: undefined reference to `__aeabi_uldivmod'
>> block/blk-lib.c:67: undefined reference to `__aeabi_uldivmod'
vim +67 block/blk-lib.c
61 if (!blk_queue_discard(q))
62 return -EOPNOTSUPP;
63
64 if (q->limits.discard_granularity) {
65 unsigned int gran_sect = q->limits.discard_granularity >> 9;
66
> 67 if (sector % gran_sect || nr_sects % gran_sect)
68 return -EINVAL;
69 }
70
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Jan,
[auto build test ERROR on: ext3/for_next]
[cannot apply to: v4.3 next-20151103]
url: https://github.com/0day-ci/linux/commits/Jan-Kara/block-Don-t-allow-illegal-discard-requests/20151104-172203
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
config: avr32-atngw100_defconfig (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=avr32
All errors (new ones prefixed by >>):
block/built-in.o: In function `ll_back_merge_fn':
>> (.text+0x90dc): undefined reference to `__avr32_umod64'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hi Jan,
[auto build test ERROR on: ext3/for_next]
[cannot apply to: v4.3 next-20151103]
url: https://github.com/0day-ci/linux/commits/Jan-Kara/block-Don-t-allow-illegal-discard-requests/20151104-172203
base: https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git for_next
config: arm-sa1100 (attached as .config)
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
block/built-in.o: In function `blkdev_issue_discard':
>> :(.text+0xcdf4): undefined reference to `__umoddi3'
:(.text+0xce0c): undefined reference to `__umoddi3'
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
On Wed, Nov 04, 2015 at 10:18:41AM +0100, Jan Kara wrote: > Currently blkdev_issue_discard() doesn't check that submitted discard > request matches granularity required by the underlying device. > Submitting such requests to the device can have unexpected consequences > (e.g. brd driver just discards more / less data depending on how exactly > the request is aligned). So test that submitted discard request has the > granularity required by the driver. How is this going to work with stacked drivers? I think brd needs to be fixed to take care of the granularity itself, just like we did for request based drivers. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed 04-11-15 03:30:19, Christoph Hellwig wrote: > On Wed, Nov 04, 2015 at 10:18:41AM +0100, Jan Kara wrote: > > Currently blkdev_issue_discard() doesn't check that submitted discard > > request matches granularity required by the underlying device. > > Submitting such requests to the device can have unexpected consequences > > (e.g. brd driver just discards more / less data depending on how exactly > > the request is aligned). So test that submitted discard request has the > > granularity required by the driver. > > How is this going to work with stacked drivers? I think brd needs to > be fixed to take care of the granularity itself, just like we did for > request based drivers. So you mean that a stacked driver would split a discard request so that it is no longer of the required granularity? OK, makes sense. I'll add the check directly into brd itself. Honza
diff --git a/block/blk-lib.c b/block/blk-lib.c index bd40292e5009..7170d02e9e9a 100644 --- a/block/blk-lib.c +++ b/block/blk-lib.c @@ -61,6 +61,13 @@ int blkdev_issue_discard(struct block_device *bdev, sector_t sector, if (!blk_queue_discard(q)) return -EOPNOTSUPP; + if (q->limits.discard_granularity) { + unsigned int gran_sect = q->limits.discard_granularity >> 9; + + if (sector % gran_sect || nr_sects % gran_sect) + return -EINVAL; + } + if (flags & BLKDEV_DISCARD_SECURE) { if (!blk_queue_secdiscard(q)) return -EOPNOTSUPP;
Currently blkdev_issue_discard() doesn't check that submitted discard request matches granularity required by the underlying device. Submitting such requests to the device can have unexpected consequences (e.g. brd driver just discards more / less data depending on how exactly the request is aligned). So test that submitted discard request has the granularity required by the driver. Signed-off-by: Jan Kara <jack@suse.com> --- block/blk-lib.c | 7 +++++++ 1 file changed, 7 insertions(+)