Re: [PATCH V5 3/4] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

On Mon, Feb 13, 2017 at 6:07 PM, David Laight wrote: > From: Arnd Bergmann >> Sent: 13 February 2017 17:02 > ... >> >> > + ioctl_ptr = memdup_user(arg, _IOC_SIZE(cmd)); >> >> > + if (IS_ERR_OR_NULL(ioctl_ptr)) { >> >> > + ret = PTR_ERR(ioctl_ptr); >> >> > +

Re: [PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

On 02/13/2017 03:28 PM, Jens Axboe wrote: > On 02/13/2017 03:09 PM, Omar Sandoval wrote: >> On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote: >>> If, at boot, a legacy I/O scheduler is chosen for a device using blk-mq, >>> or, viceversa, a blk-mq scheduler is chosen for a device using

Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq

> Il giorno 10 feb 2017, alle ore 20:49, Paolo Valente > ha scritto: > >> >> Il giorno 10 feb 2017, alle ore 19:13, Bart Van Assche >> ha scritto: >> >> On 02/10/2017 08:49 AM, Paolo Valente wrote: $ grep '^C.*_MQ_' .config

Re: [PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

On Mon, 2017-02-13 at 22:01 +0100, Paolo Valente wrote: > -static struct elevator_type *elevator_get(const char *name, bool try_loading) > +static struct elevator_type *elevator_get(const char *name, bool try_loading, > + bool mq_ops) Please choose a better

Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq

> Il giorno 07 feb 2017, alle ore 18:24, Paolo Valente > ha scritto: > > Hi, > > I have finally pushed here [1] the current WIP branch of bfq for > blk-mq, which I have tentatively named bfq-mq. > > This branch *IS NOT* meant for merging into mainline and contain

Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq

On Mon, 2017-02-13 at 22:07 +, Bart Van Assche wrote: > On Mon, 2017-02-13 at 22:07 +0100, Paolo Valente wrote: > > but what do you think about trying this fix? > > Sorry but with ... the same server I used for the previous test still > didn't boot up properly. A screenshot is available at >

[PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

If, at boot, a legacy I/O scheduler is chosen for a device using blk-mq, or, viceversa, a blk-mq scheduler is chosen for a device using blk, then that scheduler is set and initialized without any check, driving the system into an inconsistent state. This commit addresses this issue by letting

[PATCH BUGFIX] attempt to fix wrong scheduler selection

Hi, if, at boot, a legacy I/O scheduler is chosen for a device using blk-mq, or, viceversa, a blk-mq scheduler is chosen for a device using blk, then that scheduler is set and initialized without any check, driving the system into an inconsistent state. The purpose of this message is, first, to

Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq

On Mon, 2017-02-13 at 22:07 +0100, Paolo Valente wrote: > but what do you think about trying this fix? Sorry but with ... the same server I used for the previous test still didn't boot up properly. A screenshot is available at https://goo.gl/photos/Za9QVGCNe2BJBwxVA. > Otherwise, if you have no

Re: [PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

On 02/13/2017 03:09 PM, Omar Sandoval wrote: > On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote: >> If, at boot, a legacy I/O scheduler is chosen for a device using blk-mq, >> or, viceversa, a blk-mq scheduler is chosen for a device using blk, then >> that scheduler is set and

Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq

On 02/13/2017 02:09 PM, Paolo Valente wrote: > >> Il giorno 07 feb 2017, alle ore 18:24, Paolo Valente >> ha scritto: >> >> Hi, >> >> I have finally pushed here [1] the current WIP branch of bfq for >> blk-mq, which I have tentatively named bfq-mq. >> >> This branch

Re: [PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote: > If, at boot, a legacy I/O scheduler is chosen for a device using blk-mq, > or, viceversa, a blk-mq scheduler is chosen for a device using blk, then > that scheduler is set and initialized without any check, driving the > system into

[PATCH 4/7] nonblocking aio: return on congested block device

From: Goldwyn Rodrigues A new flag BIO_NONBLOCKING is introduced to identify bio's orignating from iocb with IOCB_NONBLOCKING. struct request are requested using BLK_MQ_REQ_NOWAIT if BIO_NONBLOCKING is set. Signed-off-by: Goldwyn Rodrigues ---

Re: [PATCH v1 1/5] block: introduce bio_clone_bioset_partial()

On Mon, Feb 13, 2017 at 9:46 PM, Christoph Hellwig wrote: > On Fri, Feb 10, 2017 at 06:56:13PM +0800, Ming Lei wrote: >> md still need bio clone(not the fast version) for behind write, >> and it is more efficient to use bio_clone_bioset_partial(). >> >> The idea is simple and

Re: [PATCH 4/7] nonblocking aio: return on congested block device

On Tue, Feb 14, 2017 at 10:46 AM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > A new flag BIO_NONBLOCKING is introduced to identify bio's > orignating from iocb with IOCB_NONBLOCKING. struct request > are requested using BLK_MQ_REQ_NOWAIT if

Re: [PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

On Tue, Feb 14, 2017 at 07:58:22AM +0100, Hannes Reinecke wrote: > While we're at the topic: > > Can't we use the same names for legacy and mq scheduler? > It's quite an unnecessary complication to have > 'noop', 'deadline', and 'cfq' for legacy, but 'none' and 'mq-deadline' > for mq. If we could

Re: [PATCH BUGFIX] block: make elevator_get robust against cross blk/blk-mq choice

On 02/13/2017 11:28 PM, Jens Axboe wrote: > On 02/13/2017 03:09 PM, Omar Sandoval wrote: >> On Mon, Feb 13, 2017 at 10:01:07PM +0100, Paolo Valente wrote: >>> If, at boot, a legacy I/O scheduler is chosen for a device using blk-mq, >>> or, viceversa, a blk-mq scheduler is chosen for a device using

Re: [BUG] Potential deadlock in the block layer

On 02/13/2017 07:14 AM, Thomas Gleixner wrote: > Gabriel reported the lockdep splat below while investigating something > different. > > Explanation for the splat is in the function comment above > del_timer_sync(). > > I can reproduce it as well and it's clearly broken. Agree, the disable

Re: [PATCHv6 03/37] page-flags: relax page flag policy for few flags

On Wed, Feb 08, 2017 at 08:01:13PM -0800, Matthew Wilcox wrote: > On Thu, Jan 26, 2017 at 02:57:45PM +0300, Kirill A. Shutemov wrote: > > These flags are in use for filesystems with backing storage: PG_error, > > PG_writeback and PG_readahead. > > Oh ;-) Then I amend my comment on patch 1 to be

[BUG] Potential deadlock in the block layer

Gabriel reported the lockdep splat below while investigating something different. Explanation for the splat is in the function comment above del_timer_sync(). I can reproduce it as well and it's clearly broken. Thanks, tglx --- [ 81.518032]

Re: [PATCHv6 07/37] filemap: allocate huge page in page_cache_read(), if allowed

On Thu, Feb 09, 2017 at 01:18:35PM -0800, Matthew Wilcox wrote: > On Thu, Jan 26, 2017 at 02:57:49PM +0300, Kirill A. Shutemov wrote: > > Later we can add logic to accumulate information from shadow entires to > > return to caller (average eviction time?). > > I would say minimum rather than

Re: [PATCHv6 08/37] filemap: handle huge pages in do_generic_file_read()

On Thu, Feb 09, 2017 at 01:55:05PM -0800, Matthew Wilcox wrote: > On Thu, Jan 26, 2017 at 02:57:50PM +0300, Kirill A. Shutemov wrote: > > +++ b/mm/filemap.c > > @@ -1886,6 +1886,7 @@ static ssize_t do_generic_file_read(struct file > > *filp, loff_t *ppos, > > if (unlikely(page

[PATCH] blk-mq: Call bio_io_error if request returned is NULL

From: Goldwyn Rodrigues If blk_mq_map_request returns NULL, bio_endio() function is not called. Call bio_io_error() in case request returned is NULL. Signed-off-by: Goldwyn Rodrigues --- block/blk-mq.c | 8 ++-- 1 file changed, 6 insertions(+), 2

Re: [PATCHv6 08/37] filemap: handle huge pages in do_generic_file_read()

On Thu, Jan 26, 2017 at 02:57:50PM +0300, Kirill A. Shutemov wrote: > Most of work happans on head page. Only when we need to do copy data to > userspace we find relevant subpage. > > We are still limited by PAGE_SIZE per iteration. Lifting this limitation > would require some more work. Now

RE: [PATCH V5 3/4] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

From: Scott Bauer Sent: 13 February 2017 16:11 > When CONFIG_KASAN is enabled, compilation fails: > > block/sed-opal.c: In function 'sed_ioctl': > block/sed-opal.c:2447:1: error: the frame size of 2256 bytes is larger than > 2048 bytes [-Werror=frame- > larger-than=] > > Moved all the ioctl

[PATCH V5 3/4] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

When CONFIG_KASAN is enabled, compilation fails: block/sed-opal.c: In function 'sed_ioctl': block/sed-opal.c:2447:1: error: the frame size of 2256 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Moved all the ioctl structures off the stack and dynamically activate using _IOC_SIZE()

[PATCH V5 2/4] uapi: sed-opal fix IOW for activate lsp to use correct struct

the IOW for the IOC_OPAL_ACTIVATE_LSP took the wrong strcure which would give us the wrong size when using _IOC_SIZE, switch it to the right structure. Fixes: 058f8a2 ("Include: Uapi: Add user ABI for Sed/Opal") Signed-off-by: Scott Bauer ---

[PATCH V5 4/4] Maintainers: Modify SED list from nvme to block

Signed-off-by: Scott Bauer --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e325373..b983b25 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11094,7 +11094,7 @@ SECURE ENCRYPTING DEVICE (SED) OPAL DRIVER M:

Re: [PATCH V5 3/4] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

On Mon, Feb 13, 2017 at 04:30:36PM +, David Laight wrote: > From: Scott Bauer Sent: 13 February 2017 16:11 > > When CONFIG_KASAN is enabled, compilation fails: > > > > block/sed-opal.c: In function 'sed_ioctl': > > block/sed-opal.c:2447:1: error: the frame size of 2256 bytes is larger than >

Re: [PATCH V5 3/4] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

On Mon, Feb 13, 2017 at 5:29 PM, Scott Bauer wrote: > On Mon, Feb 13, 2017 at 04:30:36PM +, David Laight wrote: >> From: Scott Bauer Sent: 13 February 2017 16:11 >> > When CONFIG_KASAN is enabled, compilation fails: >> > >> > block/sed-opal.c: In function 'sed_ioctl':

Re: [PATCHv6 08/37] filemap: handle huge pages in do_generic_file_read()

On Mon, Feb 13, 2017 at 06:33:42PM +0300, Kirill A. Shutemov wrote: > No. pagecache_get_page() returns subpage. See description of the first > patch. Your description says: > We also change interface for page-cache lookup function: > > - functions that lookup for pages[1] would return

Re: [PATCHv6 08/37] filemap: handle huge pages in do_generic_file_read()

On Mon, Feb 13, 2017 at 08:01:17AM -0800, Matthew Wilcox wrote: > On Mon, Feb 13, 2017 at 06:33:42PM +0300, Kirill A. Shutemov wrote: > > No. pagecache_get_page() returns subpage. See description of the first > > patch. Oh, I re-read patch 1 and it made sense now. I missed the bit where

[PATCH V5 1/4] block: sed-opal: change ioctl to take user pointer instead of unsinged long

Signed-off-by: Scott Bauer --- block/sed-opal.c | 6 -- drivers/nvme/host/core.c | 3 ++- include/linux/sed-opal.h | 4 ++-- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/block/sed-opal.c b/block/sed-opal.c index bf1406e..2448d4a 100644 ---

Re: [PATCH] blk-mq: Call bio_io_error if request returned is NULL

On 02/13/2017 09:04 AM, Goldwyn Rodrigues wrote: > From: Goldwyn Rodrigues > > If blk_mq_map_request returns NULL, bio_endio() function is not > called. Call bio_io_error() in case request returned is NULL. That's currently not a possible condition, since the main request

SED Opal Fixups

So we have a few patches here, they're pretty small. First patch changes the sed-opal ioctl function parameters to take a void __user* instead of an unsigned long, this required a small cast in the nvme driver. Patch 2 is a UAPI fixup for the IOW to make an ioctl the right size. Patch 3 fixes a

Re: [PATCH V5 1/4] block: sed-opal: change ioctl to take user pointer instead of unsinged long

esOn Mon, Feb 13, 2017 at 09:11:09AM -0700, Scott Bauer wrote: > Signed-off-by: Scott Bauer > --- > block/sed-opal.c | 6 -- > drivers/nvme/host/core.c | 3 ++- > include/linux/sed-opal.h | 4 ++-- > 3 files changed, 8 insertions(+), 5 deletions(-) > > diff

Re: [PATCH v2 4/4] Maintainers: Add Information for SED Opal library

On Fri, Feb 10, 2017 at 09:44:59AM -0700, Scott Bauer wrote: > > > +F:include/linux/sed* > > > +F:include/uapi/linux/sed* > > > > Since this is in the block tree and is not nvme specific, could you use > > linux-block as the main list? > > Sure, that's fine. Is there a way to denote "main list"

RE: [PATCH V5 3/4] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN

From: Arnd Bergmann > Sent: 13 February 2017 17:02 ... > >> > + ioctl_ptr = memdup_user(arg, _IOC_SIZE(cmd)); > >> > + if (IS_ERR_OR_NULL(ioctl_ptr)) { > >> > + ret = PTR_ERR(ioctl_ptr); > >> > + goto out; > >> ... > >> > + out: > >> > + kfree(ioctl_ptr); > >> > +

[PATCH] nbd: use bdget_disk to get bdev

In preparation for the upcoming netlink interface we need to not rely on already having the bdev for the NBD device we are doing operations on. Instead of passing the bdev from the bdev ioctl around, use bdget_disk() wherever we need the bdev and pass that down to the helpers as necessary.

Re: [PATCHv6 01/37] mm, shmem: swich huge tmpfs to multi-order radix-tree entries

On Thu, Feb 09, 2017 at 07:58:20PM +0300, Kirill A. Shutemov wrote: > I'll look into it. I ended up with this (I'll test it more later): void filemap_map_pages(struct vm_fault *vmf, pgoff_t start_pgoff, pgoff_t end_pgoff) { struct radix_tree_iter iter; void

Re: [PATCH v1 3/5] md: fail if mddev->bio_set can't be created

Looks fine, Reviewed-by: Christoph Hellwig but this really needs to be patch 2 in this series.

Re: [PATCH v1 1/5] block: introduce bio_clone_bioset_partial()

On Fri, Feb 10, 2017 at 06:56:13PM +0800, Ming Lei wrote: > md still need bio clone(not the fast version) for behind write, > and it is more efficient to use bio_clone_bioset_partial(). > > The idea is simple and just copy the bvecs range specified from > parameters. Given how few users

Re: [PATCH v1 2/5] md/raid1: use bio_clone_bioset_partial() in case of write behind

> + struct bio *mbio = NULL; > + int offset; > if (!r1_bio->bios[i]) > continue; > > - mbio = bio_clone_mddev(bio, GFP_NOIO, mddev); > - bio_trim(mbio, r1_bio->sector - bio->bi_iter.bi_sector, > -

Re: [PATCH v1 5/5] md: fast clone bio in bio_clone_mddev()

Please use bio_clone_fast directly and kill the wrapper.

Re: [PATCH v1 4/5] md: remove unnecessary check on mddev

Looks fine, Reviewed-by: Christoph Hellwig