On Fri, Oct 26, 2018 at 9:00 AM Jens Axboe wrote:
>
> A followup pull request for this merge window.
Pulled,
Linus
On 10/26/2018 10:12 AM, Hans Holmberg wrote:
The check for chunk closes suffers from an off-by-one issue, leading
to chunk close events not being traced. Fix this.
Fixes: 4c44abf43d00 ("lightnvm: pblk: add trace events for chunk states")
Signed-off-by: Hans Holmberg
---
drivers/lightnvm/pbl
On 10/26/2018 01:49 PM, Hans Holmberg wrote:
Yes, please do.
Reviewed-by: Hans Holmberg
On Fri, Oct 26, 2018 at 10:08 AM Matias Bjørling wrote:
On 10/26/2018 01:38 AM, Zhoujie Wu wrote:
The smeta area l2p mapping is empty, and actually the
recovery procedure only need to restore data sector
fix for xen-blkfront (Vasilis Liaskovitis)
- Fixing the get_rq trace point placement in blk-mq (Xiaoguang Wang)
- Removal of a set-but-not-read variable in cdrom (zhong jiang)
Please pull!
git://git.kernel.dk/linux-block.git tags/for-linus-20181026
Thank you for your reply.
> Against which kernel tree did you prepare this patch? Just above the code
> you want to insert I found the following:
>
> if (ptr->cmd_count > 33) ...
Yes, I saw that code as well. But I find out there is no more
additional code relevant to it.
So I guess, that
On Fri, 2018-10-26 at 10:39 -0400, Kyungtae Kim wrote:
> setup_rw_floppy() writes some bytes of array cmd to the floppy disk
> controller, depending on cmd_count.
> Although the size of array cmd is fixed like 16, cmd_count can be much
> larger through raw_cmd_ioctl().
> Noticed there is no bound c
Let me try to use git as email client.
Thanks,
Kyungtae Kim
On Fri, Oct 26, 2018 at 10:57 AM Jens Axboe wrote:
>
> On 10/26/18 8:51 AM, Kyungtae Kim wrote:
> > Do you mean mail client?? Well, I'm currently using gmail.
>
> Yes, email client. I've never sent patches with gmail, so can't
> say if
On Fri, 2018-10-26 at 08:32 -0600, Jens Axboe wrote:
> On 10/26/18 1:08 AM, Hannes Reinecke wrote:
> > On 10/25/18 11:10 PM, Jens Axboe wrote:
> > > This check is only viable for non scsi-mq. Since that is going away,
> > > kill this legacy check.
> > >
> > > Cc: Bart Van Assche
> > > Cc: Parav P
On 10/26/18 8:51 AM, Kyungtae Kim wrote:
> Do you mean mail client?? Well, I'm currently using gmail.
Yes, email client. I've never sent patches with gmail, so can't
say if that works or not. OK, just checked
Documentation/process/email-clients.rst
and is states that:
"Gmail (Web GUI)
*
Do you mean mail client?? Well, I'm currently using gmail.
On Fri, Oct 26, 2018 at 10:41 AM Jens Axboe wrote:
>
> On 10/26/18 8:39 AM, Kyungtae Kim wrote:
>
> > diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> > index a8cfa01..41160a1 100644
> > --- a/drivers/block/floppy.c
> > +++
On Fri, Oct 26, 2018 at 09:08:38AM +0100, Stefan Hajnoczi wrote:
> On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> > + range[n].flags = cpu_to_le32(flags);
> > + range[n].num_sectors = cpu_to_le32(num_sectors);
> > + range[n].sector = cpu_to_le64(sect
On 10/26/18 8:39 AM, Kyungtae Kim wrote:
> diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c
> index a8cfa01..41160a1 100644
> --- a/drivers/block/floppy.c
> +++ b/drivers/block/floppy.c
> @@ -3146,6 +3146,9 @@ static int raw_cmd_copyin(int cmd, void __user *param,
>
setup_rw_floppy() writes some bytes of array cmd to the floppy disk
controller, depending on cmd_count.
Although the size of array cmd is fixed like 16, cmd_count can be much
larger through raw_cmd_ioctl().
Noticed there is no bound check for this, thereby leading to invalid
memory access.
This pa
On 10/26/18 1:08 AM, Hannes Reinecke wrote:
> On 10/25/18 11:10 PM, Jens Axboe wrote:
>> This check is only viable for non scsi-mq. Since that is going away,
>> kill this legacy check.
>>
>> Cc: Bart Van Assche
>> Cc: Parav Pandit
>> Cc: linux-s...@vger.kernel.org
>> Signed-off-by: Jens Axboe
>>
On 10/26/18 3:28 AM, Jianchao Wang wrote:
> There are two cases when handle DISCARD merge.
> If max_discard_segments == 1, the bios/requests need to be contiguous
> to merge. If max_discard_segments > 1, it takes every bio as a range
> and different range needn't to be contiguous.
>
> But now, att
On 10/26/18 7:22 AM, Kyungtae Kim wrote:
> I corrected the patch as follows:
OK, we're getting there! Please resend as a separate email, so that
the subject line is the patch header, and just the commit message
in the body. I'd fix that up for this one, but you also need to
fix up:
> diff --git a
I corrected the patch as follows:
[PATCH] floppy: Avoid memory access beyond the array bounds in setup_rw_floppy()
setup_rw_floppy() writes some bytes of array cmd to the floppy disk
controller, depending on cmd_count.
Although the size of array cmd is fixed like 16, cmd_count can be much
larger
On Fri, Oct 26, 2018 at 1:12 AM Zhoujie Wu wrote:
>
>
>
> On 10/25/2018 04:16 AM, Hans Holmberg wrote:
> > External Email
> >
> > --
> > On Thu, Oct 25, 2018 at 2:44 AM Zhoujie Wu wrote:
> >> The smeta area l2p mapping is empty,
Yes, please do.
Reviewed-by: Hans Holmberg
On Fri, Oct 26, 2018 at 10:08 AM Matias Bjørling wrote:
>
> On 10/26/2018 01:38 AM, Zhoujie Wu wrote:
> > The smeta area l2p mapping is empty, and actually the
> > recovery procedure only need to restore data sector's l2p
> > mapping. So ignore the smet
There are two cases when handle DISCARD merge.
If max_discard_segments == 1, the bios/requests need to be contiguous
to merge. If max_discard_segments > 1, it takes every bio as a range
and different range needn't to be contiguous.
But now, attempt_merge screws this up. It always consider contigui
> On 26 Oct 2018, at 01.35, Zhoujie Wu wrote:
>
> The smeta area l2p mapping is empty, and actually the
> recovery procedure only need to restore data sector's l2p
> mapping. So ignore the smeta oob scan.
>
> Signed-off-by: Zhoujie Wu
> ---
> v2: Modified based on suggestion from Hans. The sm
On Fri, Oct 26, 2018 at 01:28:54AM +0200, Paolo Bonzini wrote:
> On 15/10/2018 11:27, Christoph Hellwig wrote:
> > There is some issues in this spec. For one using the multiple ranges
> > also for write zeroes is rather inefficient. Write zeroes really should
> > use the same format as read and w
On 10/26/18 4:07 PM, Christoph Hellwig wrote:
> On Fri, Oct 26, 2018 at 04:05:00PM +0800, jianchao.wang wrote:
>> Would anyone please take a look at this ?
>
> I did take a look and reply to it..
Oh sorry, I missed it in my email client.
Got it from the https://lkml.org/lkml/2018/10/24/491
And
The check for chunk closes suffers from an off-by-one issue, leading
to chunk close events not being traced. Fix this.
Fixes: 4c44abf43d00 ("lightnvm: pblk: add trace events for chunk states")
Signed-off-by: Hans Holmberg
---
drivers/lightnvm/pblk-core.c | 2 +-
1 file changed, 1 insertion(+),
On Fri, Oct 12, 2018 at 02:06:28PM -0700, Daniel Verkamp wrote:
> + range[n].flags = cpu_to_le32(flags);
> + range[n].num_sectors = cpu_to_le32(num_sectors);
> + range[n].sector = cpu_to_le64(sector);
...
> +/* Discard/write zeroes range for each request. */
> +s
On 10/26/2018 01:38 AM, Zhoujie Wu wrote:
The smeta area l2p mapping is empty, and actually the
recovery procedure only need to restore data sector's l2p
mapping. So ignore the smeta oob scan.
Signed-off-by: Zhoujie Wu
---
v2: Modified based on suggestion from Hans. The smeta may not start from
On Fri, Oct 26, 2018 at 04:05:00PM +0800, jianchao.wang wrote:
> Would anyone please take a look at this ?
I did take a look and reply to it..
>
> Thanks in advance.
> Jianchao
>
> On 10/24/18 11:07 AM, Jianchao Wang wrote:
> > There are two cases when handle DISCARD merge.
> > If max_discard_s
Would anyone please take a look at this ?
Thanks in advance.
Jianchao
On 10/24/18 11:07 AM, Jianchao Wang wrote:
> There are two cases when handle DISCARD merge.
> If max_discard_segments == 1, the bios/requests need to be contiguous
> to merge. If max_discard_segments > 1, it takes every bio as
Merge blk_mq_try_issue_directly and __blk_mq_try_issue_directly
into one interface which is able to handle the return value from
.queue_rq callback. Due to we can only issue directly w/o io
scheduler, so remove the blk_mq_get_driver_tag.
Signed-off-by: Jianchao Wang
---
block/blk-mq.c | 109
It is not necessary to issue request directly with bypass 'true' in
blk_mq_sched_insert_requests and insert the non-issued requests
itself. Just set bypass to 'false' and let blk_mq_try_issue_directly
handle them.
Signed-off-by: Jianchao Wang
---
block/blk-mq-sched.c | 8 +++-
block/blk-mq.
When issue request directly and the task is migrated out of the
original cpu where it allocates request, hctx could be ran on
the cpu where it is not mapped. To fix this, insert the request
if BLK_MQ_F_BLOCKING is set, check whether the current is mapped
to the hctx and invoke __blk_mq_issue_direct
Hi Jens
The 1st patch refactors the code of issue request directly.
It merges the blk_mq_try_issue_directly and __blk_mq_try_issue_directly
and make blk_mq_try_issue_directly handle return value of .queue_rq itself.
The 2nd patch make blk_mq_sched_insert_requests issue request directly with
bypas
On Fri, 26 Oct 2018 at 07:27, Ming Lei wrote:
>
> The patch titled with 'block: make sure discard bio is aligned with logical
> block size'
> in the list may fix this issue, please test and see if it works.
>
> Thanks,
> Ming
Hi, Ming,
Thanks for the quick reply. Unfortunately, it doesn't seem
On Fri, Oct 26, 2018 at 02:24:34PM +0800, Ming Lei wrote:
> Cleanup __blkdev_issue_discard().
It would help to explain what you clean up..
> + unsigned int req_sects = min(nr_sects, (UINT_MAX >> 9) &
> ~bs_mask);
This creates an overly long line.
> if (req_sects > UINT_MAX >> 9)
> - req_sects = UINT_MAX >> 9;
> + req_sects = (UINT_MAX >> 9) & ~bs_mask;
Given that we have this same thing duplicated in write zeroes
what about a documented helper?
On 10/25/18 11:10 PM, Jens Axboe wrote:
This check is only viable for non scsi-mq. Since that is going away,
kill this legacy check.
Cc: Bart Van Assche
Cc: Parav Pandit
Cc: linux-s...@vger.kernel.org
Signed-off-by: Jens Axboe
---
drivers/infiniband/ulp/srp/ib_srp.c | 7 ---
1 file cha
36 matches
Mail list logo
