* Re: [PATCHv6 15/37] thp: do not threat slab pages as huge in hpage_{nr_pages,size,mask}
From: Matthew Wilcox @ 2017-02-10 22:13 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, Andrew Morton,
Alexander Viro, Hugh Dickins, Andrea Arcangeli, Dave Hansen,
Vlastimil Babka, Ross Zwisler, linux-ext4, linux-fsdevel,
linux-kernel, linux-mm, linux-block
In-Reply-To: <20170126115819.58875-16-kirill.shutemov@linux.intel.com>
On Thu, Jan 26, 2017 at 02:57:57PM +0300, Kirill A. Shutemov wrote:
> Slab pages can be compound, but we shouldn't threat them as THP for
> pupose of hpage_* helpers, otherwise it would lead to confusing results.
>
> For instance, ext4 uses slab pages for journal pages and we shouldn't
> confuse them with THPs. The easiest way is to exclude them in hpage_*
> helpers.
Well ... I think we should just deal with compound pages instead of just
huge or regular. So I'm deferring comment on this patch.
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
> include/linux/huge_mm.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index e5c9c26d2439..5e6c408f5b47 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -137,21 +137,21 @@ static inline spinlock_t *pmd_trans_huge_lock(pmd_t *pmd,
> }
> static inline int hpage_nr_pages(struct page *page)
> {
> - if (unlikely(PageTransHuge(page)))
> + if (unlikely(!PageSlab(page) && PageTransHuge(page)))
> return HPAGE_PMD_NR;
> return 1;
> }
>
> static inline int hpage_size(struct page *page)
> {
> - if (unlikely(PageTransHuge(page)))
> + if (unlikely(!PageSlab(page) && PageTransHuge(page)))
> return HPAGE_PMD_SIZE;
> return PAGE_SIZE;
> }
>
> static inline unsigned long hpage_mask(struct page *page)
> {
> - if (unlikely(PageTransHuge(page)))
> + if (unlikely(!PageSlab(page) && PageTransHuge(page)))
> return HPAGE_PMD_MASK;
> return PAGE_MASK;
> }
> --
> 2.11.0
>
> --
> 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
^ permalink raw reply
* Re: [Nbd] [PATCH] nbd: set the logical and physical blocksize properly
From: Josef Bacik @ 2017-02-10 21:47 UTC (permalink / raw)
To: Alex Bligh
Cc: axboe, linux-block, kernel-team,
nbd-general@lists.sourceforge.net
In-Reply-To: <59F046CB-9EE6-4E45-A06D-3F352218E91B@alex.org.uk>
On Fri, 2017-02-10 at 21:07 +0100, Alex Bligh wrote:
> >
> > On 10 Feb 2017, at 19:06, Josef Bacik <jbacik@fb.com> wrote:
> >
> > We noticed when trying to do O_DIRECT to an export on the server
> > side
> > that we were getting requests smaller than the 4k sectorsize of the
> > device. This is because the client isn't setting the logical and
> > physical blocksizes properly for the underlying device. Fix this
> > up by
> > setting the queue blocksizes and then calling bd_set_size.
> Interesting. Some input into the info extension (re blocksizes) would
> definitely be appreciated.
>
What do you mean? Right now the client is just calling NBD_SET_BLKSIZE
with 4k blocksize since all of our devices are 4k drives. Thanks,
Josef
^ permalink raw reply
* Re: [Nbd] [PATCH] nbd: set the logical and physical blocksize properly
From: Alex Bligh @ 2017-02-10 20:07 UTC (permalink / raw)
To: Josef Bacik
Cc: Alex Bligh, axboe, linux-block, kernel-team,
nbd-general@lists.sourceforge.net
In-Reply-To: <1486750004-2988-1-git-send-email-jbacik@fb.com>
> On 10 Feb 2017, at 19:06, Josef Bacik <jbacik@fb.com> wrote:
>
> We noticed when trying to do O_DIRECT to an export on the server side
> that we were getting requests smaller than the 4k sectorsize of the
> device. This is because the client isn't setting the logical and
> physical blocksizes properly for the underlying device. Fix this up by
> setting the queue blocksizes and then calling bd_set_size.
Interesting. Some input into the info extension (re blocksizes) would
definitely be appreciated.
--
Alex Bligh
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Paolo Valente @ 2017-02-10 19:49 UTC (permalink / raw)
To: Bart Van Assche
Cc: tj@kernel.org, axboe@kernel.dk, ulf.hansson@linaro.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org
In-Reply-To: <4a893c20-5a6b-a16c-073a-57c1a3d91b5a@sandisk.com>
> Il giorno 10 feb 2017, alle ore 19:13, Bart Van Assche =
<bart.vanassche@sandisk.com> ha scritto:
>=20
> On 02/10/2017 08:49 AM, Paolo Valente wrote:
>>> $ grep '^C.*_MQ_' .config
>>> CONFIG_BLK_MQ_PCI=3Dy
>>> CONFIG_MQ_IOSCHED_BFQ=3Dy
>>> CONFIG_MQ_IOSCHED_DEADLINE=3Dy
>>> CONFIG_MQ_IOSCHED_NONE=3Dy
>>> CONFIG_DEFAULT_MQ_BFQ_MQ=3Dy
>>> CONFIG_DEFAULT_MQ_IOSCHED=3D"bfq-mq"
>>> CONFIG_SCSI_MQ_DEFAULT=3Dy
>>> CONFIG_DM_MQ_DEFAULT=3Dy
>>>=20
>>=20
>> Could you reconfigure with none or mq-deadline as default, check
>> whether the system boots, and, it it does, switch manually to bfq-mq,
>> check what happens, and, in the likely case of a failure, try to get
>> the oops?
>=20
> Hello Paolo,
>=20
> I just finished performing that test with the following kernel config:
> $ grep '^C.*_MQ_' .config
> CONFIG_BLK_MQ_PCI=3Dy
> CONFIG_MQ_IOSCHED_BFQ=3Dy
> CONFIG_MQ_IOSCHED_DEADLINE=3Dy
> CONFIG_MQ_IOSCHED_NONE=3Dy
> CONFIG_DEFAULT_MQ_DEADLINE=3Dy
> CONFIG_DEFAULT_MQ_IOSCHED=3D"mq-deadline"
> CONFIG_SCSI_MQ_DEFAULT=3Dy
> CONFIG_DM_MQ_DEFAULT=3Dy
>=20
> After the system came up I logged in, switched to the bfq-mq scheduler
> and ran several I/O tests against the boot disk.
Without any failure, right?
Unfortunately, as you can imagine, no boot failure occurred on
any of my test systems so far :(
This version of bfq-mq can be configured to print all its activity in
the kernel log, by just defining a macro. This will of course slow
down the system so much to make it probably unusable, if bfq-mq is
active from boot. Yet, the failure may still occur so early to make
this approach useful to discover where bfq-mq gets stuck. As of now I
have no better ideas. Any suggestion is welcome.
Thanks,
Paolo
> Sorry but nothing
> interesting appeared in the kernel log.
>=20
> Bart.
> Western Digital Corporation (and its subsidiaries) E-mail =
Confidentiality Notice & Disclaimer:
>=20
> This e-mail and any files transmitted with it may contain confidential =
or legally privileged information of WDC and/or its affiliates, and are =
intended solely for the use of the individual or entity to which they =
are addressed. If you are not the intended recipient, any disclosure, =
copying, distribution or any action taken or omitted to be taken in =
reliance on it, is prohibited. If you have received this e-mail in =
error, please notify the sender immediately and delete the e-mail in its =
entirety from your system.
>=20
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Paolo Valente @ 2017-02-10 19:33 UTC (permalink / raw)
To: Bart Van Assche
Cc: tj@kernel.org, axboe@kernel.dk, ulf.hansson@linaro.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org
In-Reply-To: <1486751635.2840.5.camel@sandisk.com>
> Il giorno 10 feb 2017, alle ore 19:34, Bart Van Assche =
<bart.vanassche@sandisk.com> ha scritto:
>=20
> On Tue, 2017-02-07 at 18:24 +0100, Paolo Valente wrote:
>> (lock assertions, BUG_ONs, ...).
>=20
> Hello Paolo,
>=20
> If you are using BUG_ON(), does that mean that you are not aware of =
Linus'
> opinion about BUG_ON()? Please read https://lkml.org/lkml/2016/10/4/1.
>=20
I am, thanks. But this is a testing version, overfull of assertions
as a form of hysteric defensive programming. I will of course remove
all halting assertions in the submission for merging.
Thanks,
Paolo
> Thanks,
>=20
> Bart.
> Western Digital Corporation (and its subsidiaries) E-mail =
Confidentiality Notice & Disclaimer:
>=20
> This e-mail and any files transmitted with it may contain confidential =
or legally privileged information of WDC and/or its affiliates, and are =
intended solely for the use of the individual or entity to which they =
are addressed. If you are not the intended recipient, any disclosure, =
copying, distribution or any action taken or omitted to be taken in =
reliance on it, is prohibited. If you have received this e-mail in =
error, please notify the sender immediately and delete the e-mail in its =
entirety from your system.
>=20
^ permalink raw reply
* Re: [PATCH] blk-mq-sched: don't hold queue_lock when calling exit_icq
From: Jens Axboe @ 2017-02-10 18:35 UTC (permalink / raw)
To: Omar Sandoval, linux-block; +Cc: Paolo Valente, kernel-team
In-Reply-To: <73cd0cf484e8b75a771d908c172cd3a931dc00a3.1486751329.git.osandov@fb.com>
On 02/10/2017 11:32 AM, Omar Sandoval wrote:
> From: Omar Sandoval <osandov@fb.com>
>
> None of the other blk-mq elevator hooks are called with this lock held.
> Additionally, it can lead to circular locking dependencies between
> queue_lock and the private scheduler lock.
Applied, thanks Omar.
--
Jens Axboe
^ permalink raw reply
* [PATCH] blk-mq-sched: don't hold queue_lock when calling exit_icq
From: Omar Sandoval @ 2017-02-10 18:32 UTC (permalink / raw)
To: Jens Axboe, linux-block; +Cc: Paolo Valente, kernel-team
From: Omar Sandoval <osandov@fb.com>
None of the other blk-mq elevator hooks are called with this lock held.
Additionally, it can lead to circular locking dependencies between
queue_lock and the private scheduler lock.
Reported-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Omar Sandoval <osandov@fb.com>
---
block/blk-ioc.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index fe186a9eade9..b12f9c87b4c3 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -35,7 +35,10 @@ static void icq_free_icq_rcu(struct rcu_head *head)
kmem_cache_free(icq->__rcu_icq_cache, icq);
}
-/* Exit an icq. Called with both ioc and q locked. */
+/*
+ * Exit an icq. Called with both ioc and q locked for sq, only ioc locked for
+ * mq.
+ */
static void ioc_exit_icq(struct io_cq *icq)
{
struct elevator_type *et = icq->q->elevator->type;
@@ -166,6 +169,7 @@ EXPORT_SYMBOL(put_io_context);
*/
void put_io_context_active(struct io_context *ioc)
{
+ struct elevator_type *et;
unsigned long flags;
struct io_cq *icq;
@@ -184,13 +188,19 @@ void put_io_context_active(struct io_context *ioc)
hlist_for_each_entry(icq, &ioc->icq_list, ioc_node) {
if (icq->flags & ICQ_EXITED)
continue;
- if (spin_trylock(icq->q->queue_lock)) {
+
+ et = icq->q->elevator->type;
+ if (et->uses_mq) {
ioc_exit_icq(icq);
- spin_unlock(icq->q->queue_lock);
} else {
- spin_unlock_irqrestore(&ioc->lock, flags);
- cpu_relax();
- goto retry;
+ if (spin_trylock(icq->q->queue_lock)) {
+ ioc_exit_icq(icq);
+ spin_unlock(icq->q->queue_lock);
+ } else {
+ spin_unlock_irqrestore(&ioc->lock, flags);
+ cpu_relax();
+ goto retry;
+ }
}
}
spin_unlock_irqrestore(&ioc->lock, flags);
--
2.11.1
^ permalink raw reply related
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Bart Van Assche @ 2017-02-10 18:34 UTC (permalink / raw)
To: tj@kernel.org, paolo.valente@linaro.org, axboe@kernel.dk
Cc: ulf.hansson@linaro.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, broonie@kernel.org,
linus.walleij@linaro.org
In-Reply-To: <20170207172446.4528-1-paolo.valente@linaro.org>
On Tue, 2017-02-07 at 18:24 +0100, Paolo Valente wrote:
> (lock assertions, BUG_ONs, ...).
Hello Paolo,
If you are using BUG_ON(), does that mean that you are not aware of Linus'
opinion about BUG_ON()? Please read https://lkml.org/lkml/2016/10/4/1.
Thanks,
Bart.
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality N=
otice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or l=
egally privileged information of WDC and/or its affiliates, and are intende=
d solely for the use of the individual or entity to which they are addresse=
d. If you are not the intended recipient, any disclosure, copying, distribu=
tion or any action taken or omitted to be taken in reliance on it, is prohi=
bited. If you have received this e-mail in error, please notify the sender =
immediately and delete the e-mail in its entirety from your system.
^ permalink raw reply
* Re: [PATCH] block: set make_request_fn manually in blk_mq_update_nr_hw_queues
From: Jens Axboe @ 2017-02-10 18:15 UTC (permalink / raw)
To: Josef Bacik, axboe, linux-block, kernel-team
In-Reply-To: <1486749813-2167-1-git-send-email-jbacik@fb.com>
On 02/10/2017 11:03 AM, Josef Bacik wrote:
> Calling blk_queue_make_request resets a bunch of settings on the
> request_queue, but all we really want is to update the make_request_fn,
> so do this directly so we don't lose things like the logical and
> physical block sizes.
Applied, thanks Josef.
--
Jens Axboe
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Bart Van Assche @ 2017-02-10 18:13 UTC (permalink / raw)
To: Paolo Valente
Cc: tj@kernel.org, axboe@kernel.dk, ulf.hansson@linaro.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org
In-Reply-To: <1241B224-A446-4C76-87BB-4EA63852B6D1@linaro.org>
On 02/10/2017 08:49 AM, Paolo Valente wrote:
>> $ grep '^C.*_MQ_' .config
>> CONFIG_BLK_MQ_PCI=3Dy
>> CONFIG_MQ_IOSCHED_BFQ=3Dy
>> CONFIG_MQ_IOSCHED_DEADLINE=3Dy
>> CONFIG_MQ_IOSCHED_NONE=3Dy
>> CONFIG_DEFAULT_MQ_BFQ_MQ=3Dy
>> CONFIG_DEFAULT_MQ_IOSCHED=3D"bfq-mq"
>> CONFIG_SCSI_MQ_DEFAULT=3Dy
>> CONFIG_DM_MQ_DEFAULT=3Dy
>>
> =
> Could you reconfigure with none or mq-deadline as default, check
> whether the system boots, and, it it does, switch manually to bfq-mq,
> check what happens, and, in the likely case of a failure, try to get
> the oops?
Hello Paolo,
I just finished performing that test with the following kernel config:
$ grep '^C.*_MQ_' .config
CONFIG_BLK_MQ_PCI=3Dy
CONFIG_MQ_IOSCHED_BFQ=3Dy
CONFIG_MQ_IOSCHED_DEADLINE=3Dy
CONFIG_MQ_IOSCHED_NONE=3Dy
CONFIG_DEFAULT_MQ_DEADLINE=3Dy
CONFIG_DEFAULT_MQ_IOSCHED=3D"mq-deadline"
CONFIG_SCSI_MQ_DEFAULT=3Dy
CONFIG_DM_MQ_DEFAULT=3Dy
After the system came up I logged in, switched to the bfq-mq scheduler
and ran several I/O tests against the boot disk. Sorry but nothing
interesting appeared in the kernel log.
Bart.
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality N=
otice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or l=
egally privileged information of WDC and/or its affiliates, and are intende=
d solely for the use of the individual or entity to which they are addresse=
d. If you are not the intended recipient, any disclosure, copying, distribu=
tion or any action taken or omitted to be taken in reliance on it, is prohi=
bited. If you have received this e-mail in error, please notify the sender =
immediately and delete the e-mail in its entirety from your system.
^ permalink raw reply
* [PATCH] nbd: set the logical and physical blocksize properly
From: Josef Bacik @ 2017-02-10 18:06 UTC (permalink / raw)
To: axboe, linux-block, kernel-team, nbd-general
We noticed when trying to do O_DIRECT to an export on the server side
that we were getting requests smaller than the 4k sectorsize of the
device. This is because the client isn't setting the logical and
physical blocksizes properly for the underlying device. Fix this up by
setting the queue blocksizes and then calling bd_set_size.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
drivers/block/nbd.c | 39 ++++++++++++++++-----------------------
1 file changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 34a280a..e0d770c 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -183,7 +183,7 @@ static int nbd_clear_reconnect(struct nbd_device *nbd)
static int nbd_size_clear(struct nbd_device *nbd, struct block_device *bdev)
{
- bdev->bd_inode->i_size = 0;
+ bd_set_size(bdev, 0);
set_capacity(nbd->disk, 0);
kobject_uevent(&nbd_to_dev(nbd)->kobj, KOBJ_CHANGE);
@@ -192,29 +192,20 @@ static int nbd_size_clear(struct nbd_device *nbd, struct block_device *bdev)
static void nbd_size_update(struct nbd_device *nbd, struct block_device *bdev)
{
- if (!nbd_is_connected(nbd))
- return;
-
- bdev->bd_inode->i_size = nbd->bytesize;
+ blk_queue_logical_block_size(nbd->disk->queue, nbd->blksize);
+ blk_queue_physical_block_size(nbd->disk->queue, nbd->blksize);
+ bd_set_size(bdev, nbd->bytesize);
set_capacity(nbd->disk, nbd->bytesize >> 9);
kobject_uevent(&nbd_to_dev(nbd)->kobj, KOBJ_CHANGE);
}
-static int nbd_size_set(struct nbd_device *nbd, struct block_device *bdev,
+static void nbd_size_set(struct nbd_device *nbd, struct block_device *bdev,
loff_t blocksize, loff_t nr_blocks)
{
- int ret;
-
- ret = set_blocksize(bdev, blocksize);
- if (ret)
- return ret;
-
nbd->blksize = blocksize;
nbd->bytesize = blocksize * nr_blocks;
-
- nbd_size_update(nbd, bdev);
-
- return 0;
+ if (nbd_is_connected(nbd))
+ nbd_size_update(nbd, bdev);
}
static void nbd_end_request(struct nbd_cmd *cmd)
@@ -875,6 +866,7 @@ static void send_disconnects(struct nbd_device *nbd)
static int nbd_disconnect(struct nbd_device *nbd, struct block_device *bdev)
{
+ printk(KERN_ERR "%u is the blocksize at disconnect\n", bdev_logical_block_size(bdev));
dev_info(disk_to_dev(nbd->disk), "NBD_DISCONNECT\n");
if (!nbd_socks_get_unless_zero(nbd))
return -EINVAL;
@@ -997,15 +989,16 @@ static int __nbd_ioctl(struct block_device *bdev, struct nbd_device *nbd,
case NBD_SET_SOCK:
return nbd_add_socket(nbd, bdev, arg);
case NBD_SET_BLKSIZE:
- return nbd_size_set(nbd, bdev, arg,
- div_s64(nbd->bytesize, arg));
+ nbd_size_set(nbd, bdev, arg,
+ div_s64(nbd->bytesize, arg));
+ return 0;
case NBD_SET_SIZE:
- return nbd_size_set(nbd, bdev, nbd->blksize,
- div_s64(arg, nbd->blksize));
-
+ nbd_size_set(nbd, bdev, nbd->blksize,
+ div_s64(arg, nbd->blksize));
+ return 0;
case NBD_SET_SIZE_BLOCKS:
- return nbd_size_set(nbd, bdev, nbd->blksize, arg);
-
+ nbd_size_set(nbd, bdev, nbd->blksize, arg);
+ return 0;
case NBD_SET_TIMEOUT:
nbd->tag_set.timeout = arg * HZ;
return 0;
--
2.7.4
^ permalink raw reply related
* [PATCH] block: set make_request_fn manually in blk_mq_update_nr_hw_queues
From: Josef Bacik @ 2017-02-10 18:03 UTC (permalink / raw)
To: axboe, linux-block, kernel-team
Calling blk_queue_make_request resets a bunch of settings on the
request_queue, but all we really want is to update the make_request_fn,
so do this directly so we don't lose things like the logical and
physical block sizes.
Signed-off-by: Josef Bacik <jbacik@fb.com>
---
block/blk-mq.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index be183e61..eccbb13 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2627,10 +2627,14 @@ void blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set, int nr_hw_queues)
list_for_each_entry(q, &set->tag_list, tag_set_list) {
blk_mq_realloc_hw_ctxs(set, q);
+ /*
+ * Manually set the make_request_fn as blk_queue_make_request
+ * resets a lot of the queue settings.
+ */
if (q->nr_hw_queues > 1)
- blk_queue_make_request(q, blk_mq_make_request);
+ q->make_request_fn = blk_mq_make_request;
else
- blk_queue_make_request(q, blk_sq_make_request);
+ q->make_request_fn = blk_sq_make_request;
blk_mq_queue_reinit(q, cpu_online_mask);
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCHv6 17/37] fs: make block_read_full_page() be able to read huge page
From: Matthew Wilcox @ 2017-02-10 17:58 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, Andrew Morton,
Alexander Viro, Hugh Dickins, Andrea Arcangeli, Dave Hansen,
Vlastimil Babka, Ross Zwisler, linux-ext4, linux-fsdevel,
linux-kernel, linux-mm, linux-block
In-Reply-To: <20170126115819.58875-18-kirill.shutemov@linux.intel.com>
On Thu, Jan 26, 2017 at 02:57:59PM +0300, Kirill A. Shutemov wrote:
> The approach is straight-forward: for compound pages we read out whole
> huge page.
Ouch. bufferheads must die ;-)
> For huge page we cannot have array of buffer head pointers on stack --
> it's 4096 pointers on x86-64 -- 'arr' is allocated with kmalloc() for
> huge pages.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
^ permalink raw reply
* Re: [PATCHv6 16/37] thp: make thp_get_unmapped_area() respect S_HUGE_MODE
From: Matthew Wilcox @ 2017-02-10 17:50 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, Andrew Morton,
Alexander Viro, Hugh Dickins, Andrea Arcangeli, Dave Hansen,
Vlastimil Babka, Ross Zwisler, linux-ext4, linux-fsdevel,
linux-kernel, linux-mm, linux-block
In-Reply-To: <20170126115819.58875-17-kirill.shutemov@linux.intel.com>
On Thu, Jan 26, 2017 at 02:57:58PM +0300, Kirill A. Shutemov wrote:
> We want mmap(NULL) to return PMD-aligned address if the inode can have
> huge pages in page cache.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
^ permalink raw reply
* Re: [PATCHv6 13/37] mm: make write_cache_pages() work on huge pages
From: Matthew Wilcox @ 2017-02-10 17:46 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, Andrew Morton,
Alexander Viro, Hugh Dickins, Andrea Arcangeli, Dave Hansen,
Vlastimil Babka, Ross Zwisler, linux-ext4, linux-fsdevel,
linux-kernel, linux-mm, linux-block
In-Reply-To: <20170126115819.58875-14-kirill.shutemov@linux.intel.com>
On Thu, Jan 26, 2017 at 02:57:55PM +0300, Kirill A. Shutemov wrote:
> We writeback whole huge page a time. Let's adjust iteration this way.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
I think a lot of the complexity in this patch is from pagevec_lookup_tag
giving you subpages rather than head pages...
> @@ -2268,7 +2273,8 @@ int write_cache_pages(struct address_space *mapping,
> * not be suitable for data integrity
> * writeout).
> */
> - done_index = page->index + 1;
> + done_index = compound_head(page)->index
> + + hpage_nr_pages(page);
> done = 1;
> break;
> }
you'd still need this line, but it'd only be:
done_index = page->index +
(1 << compound_order(page));
I think we want:
#define nr_pages(page) (1 << compound_order(page))
because we seem to be repeating that idiom quite a lot in these patches.
done_index = page->index +
nr_pages(page);
Still doesn't quite fit on one line, but it's closer, and it's the
ridiculous indentation in that function that's the real problem.
^ permalink raw reply
* Re: [PATCHv6 12/37] brd: make it handle huge pages
From: Matthew Wilcox @ 2017-02-10 17:24 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, Andrew Morton,
Alexander Viro, Hugh Dickins, Andrea Arcangeli, Dave Hansen,
Vlastimil Babka, Ross Zwisler, linux-ext4, linux-fsdevel,
linux-kernel, linux-mm, linux-block
In-Reply-To: <20170126115819.58875-13-kirill.shutemov@linux.intel.com>
On Thu, Jan 26, 2017 at 02:57:54PM +0300, Kirill A. Shutemov wrote:
> Do not assume length of bio segment is never larger than PAGE_SIZE.
> With huge pages it's HPAGE_PMD_SIZE (2M on x86-64).
I don't think we even need hugepages for BRD to be buggy. I think there are
already places which allocate compound pages (not in highmem, obviously ...)
and put them in biovecs. So this is pure and simple a bugfix.
That said, I find the current code in brd a bit inelegant, and I don't
think this patch helps... indeed, I think it's buggy:
> @@ -202,12 +202,15 @@ static int copy_to_brd_setup(struct brd_device *brd, sector_t sector, size_t n)
> size_t copy;
>
> copy = min_t(size_t, n, PAGE_SIZE - offset);
> + n -= copy;
> if (!brd_insert_page(brd, sector))
> return -ENOSPC;
> - if (copy < n) {
> + while (n) {
> sector += copy >> SECTOR_SHIFT;
> if (!brd_insert_page(brd, sector))
> return -ENOSPC;
> + copy = min_t(size_t, n, PAGE_SIZE);
> + n -= copy;
> }
We're decrementing 'n' to 0, then testing it, so we never fill in the
last page ... right?
Anyway, here's my effort. Untested.
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 3adc32a3153b..0802a6abcd81 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -202,12 +202,14 @@ static int copy_to_brd_setup(struct brd_device *brd, sector_t sector, size_t n)
size_t copy;
copy = min_t(size_t, n, PAGE_SIZE - offset);
- if (!brd_insert_page(brd, sector))
- return -ENOSPC;
- if (copy < n) {
- sector += copy >> SECTOR_SHIFT;
+ for (;;) {
if (!brd_insert_page(brd, sector))
return -ENOSPC;
+ n -= copy;
+ if (!n)
+ break;
+ sector += copy >> SECTOR_SHIFT;
+ copy = min_t(size_t, n, PAGE_SIZE);
}
return 0;
}
@@ -239,26 +241,23 @@ static void copy_to_brd(struct brd_device *brd, const void *src,
struct page *page;
void *dst;
unsigned int offset = (sector & (PAGE_SECTORS-1)) << SECTOR_SHIFT;
- size_t copy;
+ size_t copy = min_t(size_t, n, PAGE_SIZE - offset);
- copy = min_t(size_t, n, PAGE_SIZE - offset);
- page = brd_lookup_page(brd, sector);
- BUG_ON(!page);
-
- dst = kmap_atomic(page);
- memcpy(dst + offset, src, copy);
- kunmap_atomic(dst);
-
- if (copy < n) {
- src += copy;
- sector += copy >> SECTOR_SHIFT;
- copy = n - copy;
+ for (;;) {
page = brd_lookup_page(brd, sector);
BUG_ON(!page);
dst = kmap_atomic(page);
- memcpy(dst, src, copy);
+ memcpy(dst + offset, src, copy);
kunmap_atomic(dst);
+
+ n -= copy;
+ if (!n)
+ break;
+ src += copy;
+ sector += copy >> SECTOR_SHIFT;
+ offset = 0;
+ copy = min_t(size_t, n, PAGE_SIZE);
}
}
@@ -271,28 +270,24 @@ static void copy_from_brd(void *dst, struct brd_device *brd,
struct page *page;
void *src;
unsigned int offset = (sector & (PAGE_SECTORS-1)) << SECTOR_SHIFT;
- size_t copy;
+ size_t copy = min_t(size_t, n, PAGE_SIZE - offset);
- copy = min_t(size_t, n, PAGE_SIZE - offset);
- page = brd_lookup_page(brd, sector);
- if (page) {
- src = kmap_atomic(page);
- memcpy(dst, src + offset, copy);
- kunmap_atomic(src);
- } else
- memset(dst, 0, copy);
-
- if (copy < n) {
- dst += copy;
- sector += copy >> SECTOR_SHIFT;
- copy = n - copy;
+ for (;;) {
page = brd_lookup_page(brd, sector);
if (page) {
src = kmap_atomic(page);
- memcpy(dst, src, copy);
+ memcpy(dst, src + offset, copy);
kunmap_atomic(src);
} else
memset(dst, 0, copy);
+
+ n -= copy;
+ if (!n)
+ break;
+ dst += copy;
+ sector += copy >> SECTOR_SHIFT;
+ offset = 0;
+ copy = min_t(size_t, n, PAGE_SIZE);
}
}
^ permalink raw reply related
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Paolo Valente @ 2017-02-10 16:49 UTC (permalink / raw)
To: Bart Van Assche
Cc: tj@kernel.org, axboe@kernel.dk, ulf.hansson@linaro.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org
In-Reply-To: <1486742918.2840.1.camel@sandisk.com>
> Il giorno 10 feb 2017, alle ore 17:08, Bart Van Assche =
<bart.vanassche@sandisk.com> ha scritto:
>=20
> On Tue, 2017-02-07 at 18:24 +0100, Paolo Valente wrote:
>> [1] https://github.com/Algodev-github/bfq-mq
>=20
> Hello Paolo,
>=20
> That branch includes two changes of the version suffix (EXTRAVERSION =
in Makefile).
> Please don't do that but set CONFIG_LOCALVERSION in .config to add a =
suffix to
> the kernel version string.
>=20
I know it, thanks. Unfortunately, many other irregular things you will =
probably find in that sort of private branch (as for that suffix, for =
some reason it was handy for me to have it tracked by git).
Thanks,
Paolo
> Thanks,
>=20
> Bart.
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Paolo Valente @ 2017-02-10 16:49 UTC (permalink / raw)
To: Bart Van Assche
Cc: tj@kernel.org, axboe@kernel.dk, ulf.hansson@linaro.org,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
broonie@kernel.org, linus.walleij@linaro.org
In-Reply-To: <1486745110.2840.3.camel@sandisk.com>
> Il giorno 10 feb 2017, alle ore 17:45, Bart Van Assche =
<Bart.VanAssche@sandisk.com> ha scritto:
>=20
> On Tue, 2017-02-07 at 18:24 +0100, Paolo Valente wrote:
>> 2) Enable people to test this first version bfq-mq.
>=20
> Hello Paolo,
>=20
> I installed this version of bfq-mq on a server that boots from a SATA
> disk. That server boots fine with kernel v4.10-rc7 but not with this
> tree. The first 30 seconds of the boot process seem to proceed =
normally
> but after that time the messages on the console stop scrolling and
> about another 30 seconds later the server reboots. I haven't found
> anything useful in the system log. I configured the block layer as
> follows:
>=20
> $ grep '^C.*_MQ_' .config
> CONFIG_BLK_MQ_PCI=3Dy
> CONFIG_MQ_IOSCHED_BFQ=3Dy
> CONFIG_MQ_IOSCHED_DEADLINE=3Dy
> CONFIG_MQ_IOSCHED_NONE=3Dy
> CONFIG_DEFAULT_MQ_BFQ_MQ=3Dy
> CONFIG_DEFAULT_MQ_IOSCHED=3D"bfq-mq"
> CONFIG_SCSI_MQ_DEFAULT=3Dy
> CONFIG_DM_MQ_DEFAULT=3Dy
>=20
Could you reconfigure with none or mq-deadline as default, check
whether the system boots, and, it it does, switch manually to bfq-mq,
check what happens, and, in the likely case of a failure, try to get
the oops?
Thank you very much,
Paolo
> Bart.
> Western Digital Corporation (and its subsidiaries) E-mail =
Confidentiality Notice & Disclaimer:
>=20
> This e-mail and any files transmitted with it may contain confidential =
or legally privileged information of WDC and/or its affiliates, and are =
intended solely for the use of the individual or entity to which they =
are addressed. If you are not the intended recipient, any disclosure, =
copying, distribution or any action taken or omitted to be taken in =
reliance on it, is prohibited. If you have received this e-mail in =
error, please notify the sender immediately and delete the e-mail in its =
entirety from your system.
>=20
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Bart Van Assche @ 2017-02-10 16:45 UTC (permalink / raw)
To: tj@kernel.org, paolo.valente@linaro.org, axboe@kernel.dk
Cc: ulf.hansson@linaro.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, broonie@kernel.org,
linus.walleij@linaro.org
In-Reply-To: <20170207172446.4528-1-paolo.valente@linaro.org>
On Tue, 2017-02-07 at 18:24 +0100, Paolo Valente wrote:
> 2) Enable people to test this first version bfq-mq.
Hello Paolo,
I installed this version of bfq-mq on a server that boots from a SATA
disk. That server boots fine with kernel v4.10-rc7 but not with this
tree. The first 30 seconds of the boot process seem to proceed normally
but after that time the messages on the console stop scrolling and
about another 30 seconds later the server reboots. I haven't found
anything useful in the system log. I configured the block layer as
follows:
$ grep '^C.*_MQ_' .config
CONFIG_BLK_MQ_PCI=3Dy
CONFIG_MQ_IOSCHED_BFQ=3Dy
CONFIG_MQ_IOSCHED_DEADLINE=3Dy
CONFIG_MQ_IOSCHED_NONE=3Dy
CONFIG_DEFAULT_MQ_BFQ_MQ=3Dy
CONFIG_DEFAULT_MQ_IOSCHED=3D"bfq-mq"
CONFIG_SCSI_MQ_DEFAULT=3Dy
CONFIG_DM_MQ_DEFAULT=3Dy
Bart.
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality N=
otice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or l=
egally privileged information of WDC and/or its affiliates, and are intende=
d solely for the use of the individual or entity to which they are addresse=
d. If you are not the intended recipient, any disclosure, copying, distribu=
tion or any action taken or omitted to be taken in reliance on it, is prohi=
bited. If you have received this e-mail in error, please notify the sender =
immediately and delete the e-mail in its entirety from your system.
^ permalink raw reply
* Re: [WIP PATCHSET 1/4] blk-mq: pass bio to blk_mq_sched_get_rq_priv
From: Jens Axboe @ 2017-02-10 16:10 UTC (permalink / raw)
To: Paolo Valente, Tejun Heo
Cc: linux-block, linux-kernel, ulf.hansson, linus.walleij, broonie
In-Reply-To: <20170207172446.4528-2-paolo.valente@linaro.org>
On 02/07/2017 10:24 AM, Paolo Valente wrote:
> bio is used in bfq-mq's get_rq_priv, to get the request group. We could
> pass directly the group here, but I thought that passing the bio was
> more general, giving the possibility to get other pieces of information
> if needed.
I applied this one, thanks Paolo.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH] bfq-mq: cause deadlock by executing exit_icq body immediately
From: Jens Axboe @ 2017-02-10 16:09 UTC (permalink / raw)
To: Paolo Valente, Omar Sandoval
Cc: Tejun Heo, linux-block, Linux-Kernal, Ulf Hansson, Linus Walleij,
broonie
In-Reply-To: <016A8353-195C-42EB-A3D6-05E769C1EB4D@linaro.org>
On 02/10/2017 06:00 AM, Paolo Valente wrote:
>
>> Il giorno 08 feb 2017, alle ore 18:17, Omar Sandoval <osandov@osandov.com> ha scritto:
>>
>> On Wed, Feb 08, 2017 at 11:39:24AM +0100, Paolo Valente wrote:
>>>
>>>> Il giorno 08 feb 2017, alle ore 11:33, Omar Sandoval <osandov@osandov.com> ha scritto:
>>>>
>>>> On Wed, Feb 08, 2017 at 11:03:01AM +0100, Paolo Valente wrote:
>>>>>
>>>>>> Il giorno 07 feb 2017, alle ore 22:45, Omar Sandoval <osandov@osandov.com> ha scritto:
>>>>>>
>>>>>> On Tue, Feb 07, 2017 at 06:33:46PM +0100, Paolo Valente wrote:
>>>>>>> Hi,
>>>>>>> this patch is meant to show that, if the body of the hook exit_icq is executed
>>>>>>> from inside that hook, and not as deferred work, then a circular deadlock
>>>>>>> occurs.
>>>>>>>
>>>>>>> It happens if, on a CPU
>>>>>>> - the body of icq_exit takes the scheduler lock,
>>>>>>> - it does so from inside the exit_icq hook, which is invoked with the queue
>>>>>>> lock held
>>>>>>>
>>>>>>> while, on another CPU
>>>>>>> - bfq_bio_merge, after taking the scheduler lock, invokes bfq_bic_lookup,
>>>>>>> which, in its turn, takes the queue lock. bfq_bic_lookup needs to take such a
>>>>>>> lock, because it invokes ioc_lookup_icq.
>>>>>>>
>>>>>>> For more details, here is a lockdep report, right before the deadlock did occur.
>>>>>>>
>>>>>>> [ 44.059877] ======================================================
>>>>>>> [ 44.124922] [ INFO: possible circular locking dependency detected ]
>>>>>>> [ 44.125795] 4.10.0-rc5-bfq-mq+ #38 Not tainted
>>>>>>> [ 44.126414] -------------------------------------------------------
>>>>>>> [ 44.127291] sync/2043 is trying to acquire lock:
>>>>>>> [ 44.128918] (&(&bfqd->lock)->rlock){-.-...}, at: [<ffffffff90484195>] bfq_exit_icq_bfqq+0x55/0x140
>>>>>>> [ 44.134052]
>>>>>>> [ 44.134052] but task is already holding lock:
>>>>>>> [ 44.134868] (&(&q->__queue_lock)->rlock){-.....}, at: [<ffffffff9044738e>] put_io_context_active+0x6e/0xc0
>>>>>>
>>>>>> Hey, Paolo,
>>>>>>
>>>>>> I only briefly skimmed the code, but what are you using the queue_lock
>>>>>> for? You should just use your scheduler lock everywhere. blk-mq doesn't
>>>>>> use the queue lock, so the scheduler is the only thing you need mutual
>>>>>> exclusion against.
>>>>>
>>>>> Hi Omar,
>>>>> the cause of the problem is that the hook functions bfq_request_merge
>>>>> and bfq_allow_bio_merge invoke, directly or through other functions,
>>>>> the function bfq_bic_lookup, which, in its turn, invokes
>>>>> ioc_lookup_icq. The latter must be invoked with the queue lock held.
>>>>> In particular the offending lines in bfq_bic_lookup are:
>>>>>
>>>>> spin_lock_irqsave(q->queue_lock, flags);
>>>>> icq = icq_to_bic(ioc_lookup_icq(ioc, q));
>>>>> spin_unlock_irqrestore(q->queue_lock, flags);
>>>>>
>>>>> Maybe I'm missing something and we can avoid taking this lock?
>>>>
>>>> Ah, I didn't realize we still used the q->queue_lock for the icq stuff.
>>>> You're right, you still need that lock for ioc_lookup_icq(). Unless
>>>> there's something else I'm forgetting, that should be the only thing you
>>>> need it for in the core code, and you should use your scheduler lock for
>>>> everything else. What else are you using q->queue_lock for?
>>>
>>> Nothing. The deadlock follows from that bfq_request_merge gets called
>>> with the scheduler lock already held. Problematic paths start from:
>>> bfq_bio_merge and bfq_insert_request.
>>>
>>> I'm trying to understand whether I/we can reorder operations in some
>>> way that avoids the nested locking, but at no avail so far.
>>>
>>> Thanks,
>>> Paolo
>>
>> Okay, I understand what you're saying now. It was all in the first email
>> but I didn't see it right away, sorry about that.
>>
>> I don't think it makes sense for ->exit_icq() to be invoked while
>> holding q->queue_lock for blk-mq -- we don't hold that lock for any of
>> the other hooks. Could you try the below? I haven't convinced myself
>> that there isn't a circular locking dependency between bfqd->lock and
>> ioc->lock now, but it's probably easiest for you to just try it.
>>
>
> Just passed the last of a heavy batch of tests!
Omar, care to turn this into a real patch and submit it?
--
Jens Axboe
^ permalink raw reply
* Re: [WIP PATCHSET 0/4] WIP branch for bfq-mq
From: Bart Van Assche @ 2017-02-10 16:08 UTC (permalink / raw)
To: tj@kernel.org, paolo.valente@linaro.org, axboe@kernel.dk
Cc: ulf.hansson@linaro.org, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, broonie@kernel.org,
linus.walleij@linaro.org
In-Reply-To: <20170207172446.4528-1-paolo.valente@linaro.org>
On Tue, 2017-02-07 at 18:24 +0100, Paolo Valente wrote:
> [1] https://github.com/Algodev-github/bfq-mq
Hello Paolo,
That branch includes two changes of the version suffix (EXTRAVERSION in Mak=
efile).
Please don't do that but set CONFIG_LOCALVERSION in .config to add a suffix=
to
the kernel version string.
Thanks,
Bart.
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality N=
otice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or l=
egally privileged information of WDC and/or its affiliates, and are intende=
d solely for the use of the individual or entity to which they are addresse=
d. If you are not the intended recipient, any disclosure, copying, distribu=
tion or any action taken or omitted to be taken in reliance on it, is prohi=
bited. If you have received this e-mail in error, please notify the sender =
immediately and delete the e-mail in its entirety from your system.
^ permalink raw reply
* [PATCH V4 2/2] Move stack parameters for sed_ioctl to prevent oversized stack with CONFIG_KASAN
From: Scott Bauer @ 2017-02-10 16:00 UTC (permalink / raw)
To: linux-nvme
Cc: keith.busch, arnd, hch, linux-kernel, axboe, David.Laight,
linux-block, Scott Bauer, jonathan.derrick
In-Reply-To: <1486742454-3254-1-git-send-email-scott.bauer@intel.com>
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()
Fixes: 455a7b238cd6 ("block: Add Sed-opal library")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Scott Bauer <scott.bauer@intel.com>
---
block/sed-opal.c | 132 ++++++++++++++++++++-----------------------------------
1 file changed, 48 insertions(+), 84 deletions(-)
diff --git a/block/sed-opal.c b/block/sed-opal.c
index bf1406e..d09a089 100644
--- a/block/sed-opal.c
+++ b/block/sed-opal.c
@@ -2346,7 +2346,10 @@ EXPORT_SYMBOL(opal_unlock_from_suspend);
int sed_ioctl(struct opal_dev *dev, unsigned int cmd, unsigned long ptr)
{
+ void *ioctl_ptr;
+ int ret = -ENOTTY;
void __user *arg = (void __user *)ptr;
+ unsigned int cmd_size = _IOC_SIZE(cmd);
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
@@ -2355,94 +2358,55 @@ int sed_ioctl(struct opal_dev *dev, unsigned int cmd, unsigned long ptr)
return -ENOTSUPP;
}
- switch (cmd) {
- case IOC_OPAL_SAVE: {
- struct opal_lock_unlock lk_unlk;
-
- if (copy_from_user(&lk_unlk, arg, sizeof(lk_unlk)))
- return -EFAULT;
- return opal_save(dev, &lk_unlk);
- }
- case IOC_OPAL_LOCK_UNLOCK: {
- struct opal_lock_unlock lk_unlk;
-
- if (copy_from_user(&lk_unlk, arg, sizeof(lk_unlk)))
- return -EFAULT;
- return opal_lock_unlock(dev, &lk_unlk);
- }
- case IOC_OPAL_TAKE_OWNERSHIP: {
- struct opal_key opal_key;
-
- if (copy_from_user(&opal_key, arg, sizeof(opal_key)))
- return -EFAULT;
- return opal_take_ownership(dev, &opal_key);
- }
- case IOC_OPAL_ACTIVATE_LSP: {
- struct opal_lr_act opal_lr_act;
-
- if (copy_from_user(&opal_lr_act, arg, sizeof(opal_lr_act)))
- return -EFAULT;
- return opal_activate_lsp(dev, &opal_lr_act);
- }
- case IOC_OPAL_SET_PW: {
- struct opal_new_pw opal_pw;
-
- if (copy_from_user(&opal_pw, arg, sizeof(opal_pw)))
- return -EFAULT;
- return opal_set_new_pw(dev, &opal_pw);
- }
- case IOC_OPAL_ACTIVATE_USR: {
- struct opal_session_info session;
-
- if (copy_from_user(&session, arg, sizeof(session)))
- return -EFAULT;
- return opal_activate_user(dev, &session);
- }
- case IOC_OPAL_REVERT_TPR: {
- struct opal_key opal_key;
-
- if (copy_from_user(&opal_key, arg, sizeof(opal_key)))
- return -EFAULT;
- return opal_reverttper(dev, &opal_key);
- }
- case IOC_OPAL_LR_SETUP: {
- struct opal_user_lr_setup lrs;
-
- if (copy_from_user(&lrs, arg, sizeof(lrs)))
- return -EFAULT;
- return opal_setup_locking_range(dev, &lrs);
- }
- case IOC_OPAL_ADD_USR_TO_LR: {
- struct opal_lock_unlock lk_unlk;
-
- if (copy_from_user(&lk_unlk, arg, sizeof(lk_unlk)))
- return -EFAULT;
- return opal_add_user_to_lr(dev, &lk_unlk);
- }
- case IOC_OPAL_ENABLE_DISABLE_MBR: {
- struct opal_mbr_data mbr;
-
- if (copy_from_user(&mbr, arg, sizeof(mbr)))
- return -EFAULT;
- return opal_enable_disable_shadow_mbr(dev, &mbr);
- }
- case IOC_OPAL_ERASE_LR: {
- struct opal_session_info session;
-
- if (copy_from_user(&session, arg, sizeof(session)))
- return -EFAULT;
- return opal_erase_locking_range(dev, &session);
+ ioctl_ptr = memdup_user(arg, cmd_size);
+ if (IS_ERR_OR_NULL(ioctl_ptr)) {
+ ret = PTR_ERR(ioctl_ptr);
+ goto out;
}
- case IOC_OPAL_SECURE_ERASE_LR: {
- struct opal_session_info session;
- if (copy_from_user(&session, arg, sizeof(session)))
- return -EFAULT;
- return opal_secure_erase_locking_range(dev, &session);
- }
+ switch (cmd) {
+ case IOC_OPAL_SAVE:
+ ret = opal_save(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_LOCK_UNLOCK:
+ ret = opal_lock_unlock(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_TAKE_OWNERSHIP:
+ ret = opal_take_ownership(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_ACTIVATE_LSP:
+ ret = opal_activate_lsp(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_SET_PW:
+ ret = opal_set_new_pw(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_ACTIVATE_USR:
+ ret = opal_activate_user(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_REVERT_TPR:
+ ret = opal_reverttper(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_LR_SETUP:
+ ret = opal_setup_locking_range(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_ADD_USR_TO_LR:
+ ret = opal_add_user_to_lr(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_ENABLE_DISABLE_MBR:
+ ret = opal_enable_disable_shadow_mbr(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_ERASE_LR:
+ ret = opal_erase_locking_range(dev, ioctl_ptr);
+ break;
+ case IOC_OPAL_SECURE_ERASE_LR:
+ ret = opal_secure_erase_locking_range(dev, ioctl_ptr);
+ break;
default:
pr_warn("No such Opal Ioctl %u\n", cmd);
}
- return -ENOTTY;
+
+ out:
+ kfree(ioctl_ptr);
+ return ret;
}
EXPORT_SYMBOL_GPL(sed_ioctl);
--
2.7.4
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related
* [PATCH V4 1/2] uapi: sed-opal fix IOW for activate lsp to use correct struct
From: Scott Bauer @ 2017-02-10 16:00 UTC (permalink / raw)
To: linux-nvme
Cc: keith.busch, arnd, hch, linux-kernel, axboe, David.Laight,
linux-block, Scott Bauer, jonathan.derrick
In-Reply-To: <1486742454-3254-1-git-send-email-scott.bauer@intel.com>
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 <scott.bauer@intel.com>
---
include/uapi/linux/sed-opal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/sed-opal.h b/include/uapi/linux/sed-opal.h
index fc06e3a..c72e073 100644
--- a/include/uapi/linux/sed-opal.h
+++ b/include/uapi/linux/sed-opal.h
@@ -106,7 +106,7 @@ struct opal_mbr_data {
#define IOC_OPAL_SAVE _IOW('p', 220, struct opal_lock_unlock)
#define IOC_OPAL_LOCK_UNLOCK _IOW('p', 221, struct opal_lock_unlock)
#define IOC_OPAL_TAKE_OWNERSHIP _IOW('p', 222, struct opal_key)
-#define IOC_OPAL_ACTIVATE_LSP _IOW('p', 223, struct opal_key)
+#define IOC_OPAL_ACTIVATE_LSP _IOW('p', 223, struct opal_lr_act)
#define IOC_OPAL_SET_PW _IOW('p', 224, struct opal_new_pw)
#define IOC_OPAL_ACTIVATE_USR _IOW('p', 225, struct opal_session_info)
#define IOC_OPAL_REVERT_TPR _IOW('p', 226, struct opal_key)
--
2.7.4
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related
* Sed-opal Fixes
From: Scott Bauer @ 2017-02-10 16:00 UTC (permalink / raw)
To: linux-nvme
Cc: keith.busch, arnd, hch, linux-kernel, axboe, David.Laight,
linux-block, jonathan.derrick
changes from v3->v4:
Changed manual kzalloc + copy from user to memdup_user.
This small series fixes a small ABI issue when using the _IOC_SIZE
with the Activate Locking SP ioctl. I had put the wrong structure
in the IOW macro in the uapi header which caused issues when trying
to copy in the contents for the command.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox