Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1262150 > unrolled thread

[PATCH] block: Don't allow illegal discard requests

Started byJan Kara <jack@suse.com>
First post2015-11-04 10:20 +0100
Last post2015-11-04 15:20 +0100
Articles 6 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] block: Don't allow illegal discard requests Jan Kara <jack@suse.com> - 2015-11-04 10:20 +0100
    Re: [PATCH] block: Don't allow illegal discard requests kbuild test robot <lkp@intel.com> - 2015-11-04 11:50 +0100
    Re: [PATCH] block: Don't allow illegal discard requests kbuild test robot <lkp@intel.com> - 2015-11-04 11:50 +0100
    Re: [PATCH] block: Don't allow illegal discard requests kbuild test robot <lkp@intel.com> - 2015-11-04 12:00 +0100
    Re: [PATCH] block: Don't allow illegal discard requests Christoph Hellwig <hch@infradead.org> - 2015-11-04 12:40 +0100
      Re: [PATCH] block: Don't allow illegal discard requests Jan Kara <jack@suse.cz> - 2015-11-04 15:20 +0100

#1262150 — [PATCH] block: Don't allow illegal discard requests

FromJan Kara <jack@suse.com>
Date2015-11-04 10:20 +0100
Subject[PATCH] block: Don't allow illegal discard requests
Message-ID<qr2oy-6Ys-7@gated-at.bofh.it>
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(+)

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;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1262196

Fromkbuild test robot <lkp@intel.com>
Date2015-11-04 11:50 +0100
Message-ID<qr3NE-7IS-13@gated-at.bofh.it>
In reply to#1262150

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]


#1262198

Fromkbuild test robot <lkp@intel.com>
Date2015-11-04 11:50 +0100
Message-ID<qr3NE-7IS-19@gated-at.bofh.it>
In reply to#1262150

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]


#1262209

Fromkbuild test robot <lkp@intel.com>
Date2015-11-04 12:00 +0100
Message-ID<qr3Xl-7Mx-25@gated-at.bofh.it>
In reply to#1262150

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]


#1262226

FromChristoph Hellwig <hch@infradead.org>
Date2015-11-04 12:40 +0100
Message-ID<qr4A2-8gn-5@gated-at.bofh.it>
In reply to#1262150
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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1262303

FromJan Kara <jack@suse.cz>
Date2015-11-04 15:20 +0100
Message-ID<qr74R-1xu-7@gated-at.bofh.it>
In reply to#1262226
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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web