> Am 25.07.2018 um 08:16 schrieb Stefan Priebe - Profihost AG
> :
>
>> Am 24.07.2018 um 18:36 schrieb Coly Li:
>>> On 2018/7/24 4:33 PM, Stefan Priebe - Profihost AG wrote:
Am 24.07.2018 um 10:28 schrieb Coly Li:
> On 2018/7/24 3:16 PM, Stefan Priebe - Profihost AG wrote:
>> Am
From: Arnd Bergmann
The get_seconds function is deprecated now since it returns a 32-bit
value that will eventually overflow, and we are replacing it throughout
the kernel with ktime_get_seconds() or ktime_get_real_seconds() that
return a time64_t.
bcache uses get_seconds() to read the current
From: Shenghui Wang
Free the cache_set->flush_bree heap memory on journal free.
Signed-off-by: Wang Sheng-Hui
Signed-off-by: Coly Li
---
drivers/md/bcache/journal.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/md/bcache/journal.c b/drivers/md/bcache/journal.c
index
From: Florian Schmaus
Fixes an error condition reported by checkpatch.pl which is caused by
assigning a variable in an if condition.
Signed-off-by: Florian Schmaus
Signed-off-by: Coly Li
---
drivers/md/bcache/super.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff
From: Tang Junhui
I attached several backend devices in the same cache set, and produced lots
of dirty data by running small rand I/O writes in a long time, then I
continue run I/O in the others cached devices, and stopped a cached device,
after a mean while, I register the stopped device again,
From: Florian Schmaus
Fixes an error condition reported by checkpatch.pl which is caused by
assigning a variable in an if condition.
Signed-off-by: Florian Schmaus
Signed-off-by: Coly Li
---
drivers/md/bcache/super.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
From: Florian Schmaus
Fixes an error condition reported by checkpatch.pl which is caused by
assigning a variable in an if condition.
Signed-off-by: Florian Schmaus
Signed-off-by: Coly Li
---
drivers/md/bcache/super.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
From: Tang Junhui
This patch base on "[PATCH] bcache: finish incremental GC".
Since incremental GC would stop 100ms when front side I/O comes, so when
there are many btree nodes, if GC only processes constant (100) nodes each
time, GC would last a long time, and the front I/Os would run out of
From: Tang Junhui
In GC thread, we record the latest GC key in gc_done, which is expected
to be used for incremental GC, but in currently code, we didn't realize
it. When GC runs, front side IO would be blocked until the GC over, it
would be a long time if there is a lot of btree nodes.
This
From: Tang Junhui
Currently we calculate the total amount of flash only devices dirty data
by adding the dirty data of each flash only device under registering
locker. It is very inefficient.
In this patch, we add a member flash_dev_dirty_sectors in struct cache_set
to record the total amount
Hi Jenns,
Here is the first wave bcache patches for Linnux v4.19.
Florian Schmaus contributes useful chagnes for code cleanup, and
Arnd Bergmann replaces get_seconds() by ktime_get_real_seconds().
Shenghui Wang contributes a patch to fix a memory leak in bcache. And
patches from Tang Junhui
Hi Bart
On 07/26/2018 06:26 AM, Bart Van Assche wrote:
> +
> +void blk_pm_runtime_lock(struct request_queue *q)
> +{
> + spin_lock(>rpm_lock);
> + wait_event_interruptible_locked(q->rpm_wq,
> + q->rpm_owner == NULL || q->rpm_owner == current);
> + if
Hi Bart
On 07/26/2018 06:26 AM, Bart Van Assche wrote:
> @@ -102,9 +109,11 @@ int blk_pre_runtime_suspend(struct request_queue *q)
> return ret;
>
> blk_pm_runtime_lock(q);
> + blk_set_preempt_only(q);
We only stop non-RQF_PM request entering when RPM_SUSPENDING and
Thanks for the report and correction. I was able to run the test and reproduce
the problem, I also confirm that it is not that consistent.
As I suspected the problem is in the nvme disconnect in the following call
chain:-
nvme_sysfs_delete
nvme_delete_ctrl_sync
nvme_delete_ctrl_work
Max,
> Also moved the logic of the remapping to the nvme core driver instead
> of implementing it in the nvme pci driver. This way all the other nvme
> transport drivers will benefit from it (in case they'll implement metadata
> support).
Reviewed-by: Martin K. Petersen
--
Martin K.
Max,
> Currently these functions are implemented in the scsi layer, but their
> actual place should be the block layer since T10-PI is a general data
> integrity feature that is used in the nvme protocol as well. Also, use
> the tuple size from the integrity profile since it may vary between
>
Max,
> Currently this function is implemented in the scsi layer, but it's
> actual place should be the block layer since T10-PI is a general
> data integrity feature that is used in the nvme protocol as well.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux
Move the code for runtime power management from blk-core.c into the
new source file blk-pm.c. Move the declarations of the moved functions
from into . For CONFIG_PM=n, leave
out the declarations of the functions that are not used in that mode.
This patch not only reduces the number of #ifdefs in
Instead of allowing requests that are not power management requests
to enter the queue in runtime suspended status (RPM_SUSPENDED), make
the blk_get_request() caller block. This change fixes a starvation
issue: it is now guaranteed that power management requests will be
executed no matter how many
Hello Jens,
This patch series not only enables runtime power management for blk-mq but also
simplifies power management for the legacy block layer. Please consider this
patch series for kernel v4.19.
Thanks,
Bart.
Changes compared to v1:
- Moved the runtime power management code into a
Since the REQ_PREEMPT flag has been renamed into RQF_PREEMPT, update the
comment that refers to that flag.
Signed-off-by: Bart Van Assche
Reviewed-by: Johannes Thumshirn
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Alan Stern
---
include/linux/blkdev.h | 2 +-
1 file changed, 1 insertion(+), 1
Serialize these operations because the next patch will add code into
blk_pre_runtime_suspend() that should not run concurrently with queue
freezing nor unfreezing.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Johannes Thumshirn
Cc: Alan Stern
---
block/blk-core.c
Now that the blk-mq core processes power management requests
(marked with RQF_PREEMPT) in other states than RPM_ACTIVE, enable
runtime power management for blk-mq.
Signed-off-by: Bart Van Assche
Cc: Christoph Hellwig
Cc: Ming Lei
Cc: Alan Stern
Cc: Johannes Thumshirn
---
block/blk-pm.c | 4
On Wed, Jul 04, 2018 at 01:29:56PM +0800, Ming Lei wrote:
> SCSI may have lots of channels, targets or LUNs, so it may
> take long time for creating and cleaning up queues.
>
> So introduce block/023 and uses null_blk to run this test
> on both blk-mq and legacy mode, then compare both and check
Hi Christoph, Jens, Jan, all,
while pondering over blkdev_direct_IO(), I found the following semantic change
introduced by 542ff7b in the "normal" (i.e. not "simple") path, and came up
with this patch. Please tell me what you think.
Thanks
Martin
For the blkdev_direc_IO() path, the call to
On Tue, Jul 17, 2018 at 03:27:50PM +0200, Hannes Reinecke wrote:
> Adding an option '--outdir' to store results in a different
> director so as not to clutter the git repository itself.
>
> Signed-off-by: Hannes Reinecke
> ---
> check | 14 ++
> 1 file changed, 10 insertions(+), 4
On Wed, 25 Jul 2018 10:37:23 +0800 Coly Li wrote:
> > IIUC this series in Andrew's quilt. So, it's still possible to replace
> > it with better one, I suppose. Ask Andrew (at least I remember recent
> > case where he just replaced series by fixed one).
>
> Hi Andrew,
>
> It seems there should
If the last page of the bio is not "full", the length of the last
vector slot needs to be corrected. This slot has the index
(bio->bi_vcnt - 1), but only in bio->bi_io_vec. In the "bv" helper
array, which is shifted by the value of bio->bi_vcnt at function
invocation, the correct index is
Fixes: 72ecad22d9f1 ("block: support a full bio worth of IO for
simplified bdev direct-io")
Reviewed-by: Ming Lei
Signed-off-by: Martin Wilck
---
fs/block_dev.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 0dd87aa..aba2541
bio_iov_iter_get_pages() currently only adds pages for the
next non-zero segment from the iov_iter to the bio. That's
suboptimal for callers, which typically try to pin as many
pages as fit into the bio. This patch converts the current
bio_iov_iter_get_pages() into a static helper, and introduces
Hello Jens, Ming, Jan, and all others,
the following patches have been verified by a customer to fix a silent data
corruption which he has been seeing since "72ecad2 block: support a full bio
worth of IO for simplified bdev direct-io".
The patches are based on our observation that the corruption
On Wed, Jul 25, 2018 at 07:27:35PM +, Chaitanya Kulkarni wrote:
>
> Thanks, Omar.
Tests nvme/014 and nvme/015 had a pretty bad typo that I didn't notice
last time:
dd=/dev/urandom of="/dev/${nvmedev}n1" count=128000 bs=4k
That should be
dd if=/dev/urandom of="/dev/${nvmedev}n1"
Hi there,
I'm investigating an problem where I see block I/O twice the maximum
allowed size in max_hw_sectors_kb. In my case the device driver simply
fails. I have to investigate that part further... Nevertheless I think there
might be some strange calculation bug in ondemand_readahead().
Assume
Thanks, Omar.
From: Omar Sandoval
Sent: Wednesday, July 25, 2018 12:17 PM
To: Chaitanya Kulkarni
Cc: Hannes Reinecke; Omar Sandoval; Christoph Hellwig; Sagi Grimberg; Keith
Busch; linux-n...@lists.infradead.org; linux-block@vger.kernel.org
Subject: Re: [PATCH 0/2] blktests: test ANA base
On Sat, Jul 21, 2018 at 09:23:32PM +, Chaitanya Kulkarni wrote:
> Hi Hannes,
>
> Thanks for the test, this is really helpful, please see my inline comments to
> individual patches.
>
> Also, the test number should be I guess 18, 14-17 testcases are still in the
> queue.
Yeah, sorry about
On 07/25/2018 02:17 PM, Jens Axboe wrote:
On 7/25/18 10:28 AM, Peter Geis wrote:
Good Afternoon,
I have encountered an issue on both Tegra 2 and Tegra 3 devices
accessing emmc following the 25 July 2018 remote tracking merge.
The offending commit is:
6ce3dd6eec114930cf2035a8bcb1e80477ed79a8
On 7/25/18 10:28 AM, Peter Geis wrote:
> Good Afternoon,
>
> I have encountered an issue on both Tegra 2 and Tegra 3 devices
> accessing emmc following the 25 July 2018 remote tracking merge.
>
> The offending commit is:
> 6ce3dd6eec114930cf2035a8bcb1e80477ed79a8
> blk-mq: issue directly if hw
On Fri, 2018-07-13 at 15:29 +0200, Patrick Steinhardt wrote:
> When power management for SCSI is enabled and if a device uses blk-mq,
> it is possible to trigger a `NULL` pointer exception when resuming that
> device. The NPE is triggered when trying to dereference the `request_fn`
> function
On 7/25/18 4:08 AM, Christoph Hellwig wrote:
> Hi Jens,
>
> below is the first batch of NVMe updates for Linux 4.19.
>
> Highlights:
>
> - massively improved tracepoints (Keith Busch)
> - support for larger inline data in the RDMA host and target
>(Steve Wise)
> - RDMA setup/teardown
On 7/25/18 12:42 AM, Juergen Gross wrote:
> Remove some macros not used anywhere.
Applied, thanks.
--
Jens Axboe
On Wed, Jul 25, 2018 at 4:32 AM, Rafael J. Wysocki wrote:
> On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
>> In the quest to remove all stack VLA usage from the kernel[1], this
>> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
>> shash directly and allocating the
On Wed, Jul 25, 2018 at 06:46:17PM +0300, Max Gurtovoy wrote:
> Also moved the logic of the remapping to the nvme core driver instead
> of implementing it in the nvme pci driver. This way all the other nvme
> transport drivers will benefit from it (in case they'll implement metadata
> support).
Good Afternoon,
I have encountered an issue on both Tegra 2 and Tegra 3 devices
accessing emmc following the 25 July 2018 remote tracking merge.
The offending commit is:
6ce3dd6eec114930cf2035a8bcb1e80477ed79a8
blk-mq: issue directly if hw queue isn't busy in case of 'none'.
Reverting this
On Wed, Jul 25, 2018 at 03:52:17PM +, Bart Van Assche wrote:
> On Mon, 2018-07-23 at 08:37 -0600, Keith Busch wrote:
> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 8932ae81a15a..2715cdaa669c 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++
On Mon, 2018-07-23 at 08:37 -0600, Keith Busch wrote:
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 8932ae81a15a..2715cdaa669c 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -296,6 +296,20 @@ enum blk_eh_timer_return
Currently this function is implemented in the scsi layer, but it's
actual place should be the block layer since T10-PI is a general
data integrity feature that is used in the nvme protocol as well.
Suggested-by: Christoph Hellwig
Cc: Jens Axboe
Cc: Martin K. Petersen
Signed-off-by: Max
Also moved the logic of the remapping to the nvme core driver instead
of implementing it in the nvme pci driver. This way all the other nvme
transport drivers will benefit from it (in case they'll implement metadata
support).
Suggested-by: Christoph Hellwig
Cc: Jens Axboe
Cc: Martin K. Petersen
Currently these functions are implemented in the scsi layer, but their
actual place should be the block layer since T10-PI is a general data
integrity feature that is used in the nvme protocol as well. Also, use
the tuple size from the integrity profile since it may vary between
integrity types.
On Wed, Jul 25, 2018 at 01:22:47PM +0200, Christoph Hellwig wrote:
> > + pmap = kmap_atomic(iv.bv_page) + iv.bv_offset;
> > + p = pmap;
>
> Maybe:
>
> pmap = p = kmap_atomic(iv.bv_page) + iv.bv_offset;
Max pointed out that even with
This allows bio_integrity_bytes() to be called from drivers instead of
open coding it.
Signed-off-by: Greg Edwards
---
block/bio-integrity.c | 22 --
include/linux/blkdev.h | 34 ++
2 files changed, 34 insertions(+), 22 deletions(-)
diff
The current calculation for pi_bytes{out,in} assumes a 512 byte logical
block size and a protection interval exponent of 0, i.e. 512 bytes data
+ 8 bytes PI. When run on a 4 KiB logical block size device with a
protection interval exponent of 0, i.e. 4096 bytes data + 8 bytes PI,
the driver
When the VIRTIO_SCSI_F_T10_PI feature bit is enabled, the virtio_scsi driver
does not correctly calculate pi_bytes{out,in} when the underlying device has a
4 KiB logical block size. The current code assumes a 512 byte logical block
size and protection interval exponent of 0 (512 bytes + 8 bytes
On 7/25/2018 2:22 PM, Christoph Hellwig wrote:
+ pmap = kmap_atomic(iv.bv_page) + iv.bv_offset;
+ p = pmap;
Maybe:
pmap = p = kmap_atomic(iv.bv_page) + iv.bv_offset;
+ for (j = 0; j < iv.bv_len; j
On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
> shash directly and allocating the descriptor in heap memory (which should
> be fine: the tfm has
> + pmap = kmap_atomic(iv.bv_page) + iv.bv_offset;
> + p = pmap;
Maybe:
pmap = p = kmap_atomic(iv.bv_page) + iv.bv_offset;
> + for (j = 0; j < iv.bv_len; j += tuple_sz) {
> + pi =
Hi Jens,
below is the first batch of NVMe updates for Linux 4.19.
Highlights:
- massively improved tracepoints (Keith Busch)
- support for larger inline data in the RDMA host and target
(Steve Wise)
- RDMA setup/teardown path fixes and refactor (Sagi Grimberg)
- Command Supported and
On Wed, Jul 25, 2018 at 09:42:07AM +0200, Juergen Gross wrote:
> Remove some macros not used anywhere.
>
> Signed-off-by: Juergen Gross
Acked-by: Roger Pau Monné
Thanks, Roger.
Currently these functions are implemented in the scsi layer, but their
actual place should be the block layer since T10-PI is a general data
integrity feature that is used in the nvme protocol as well. Also, use
the tuple size from the integrity profile since it may vary between
integrity types.
Currently this function is implemented in the scsi layer, but it's
actual place should be the block layer since T10-PI is a general
data integrity feature that is used in the nvme protocol as well.
Suggested-by: Christoph Hellwig
Cc: Jens Axboe
Cc: Martin K. Petersen
Signed-off-by: Max
Also moved the logic of the remapping to the nvme core driver instead
of implementing it in the nvme pci driver. This way all the other nvme
transport drivers will benefit from it (in case they'll implement metadata
support).
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Cc:
On Wed, 2018-07-25 at 09:46 +0200, Christoph Hellwig wrote:
> On Wed, Jul 25, 2018 at 08:28:37AM +0200, Hannes Reinecke wrote:
> > Update __device_add_disk() to take an 'groups' argument so that
> > individual drivers can register a device with additional sysfs
> > attributes.
> > This avoids race
Remove some macros not used anywhere.
Signed-off-by: Juergen Gross
---
drivers/block/xen-blkfront.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index b5cedccb5d7d..94300dbe358b 100644
--- a/drivers/block/xen-blkfront.c
+++
On Wed, Jul 25, 2018 at 08:28:37AM +0200, Hannes Reinecke wrote:
> Update __device_add_disk() to take an 'groups' argument so that
> individual drivers can register a device with additional sysfs
> attributes.
> This avoids race condition the driver would otherwise have if these
> groups need to
> +void __device_get_disk(struct gendisk *disk)
This function can be static. Also it is a bit misnamed. I'm not
really sure this split is worth it, but if we really want to kill
off the argument it might be worth to just open code the new
__device_get_disk in both callers.
On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote:
> In preparing to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
> the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
> to direct shash. By removing a
Split off the last part of __device_add_disk() into __device_get_disk().
With that we can drop the 'bool' argument and streamline the function.
Signed-off-by: Hannes Reinecke
---
block/genhd.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/block/genhd.c
When creating a block device some drivers need to create additional sysfs
groups to store driver-specific informations.
With the current workflow of adding these groups with a separate call to
sysfs after the device has been created we are introducing a race with udev,
as the uevent is generated
Update __device_add_disk() to take an 'groups' argument so that
individual drivers can register a device with additional sysfs
attributes.
This avoids race condition the driver would otherwise have if these
groups need to be created with sysfs_add_groups().
Signed-off-by: Martin Wilck
Use device_add_disk_with_groups() to avoid a race condition with
udev during startup.
Signed-off-by: Hannes Reinecke
---
drivers/block/aoe/aoe.h| 1 -
drivers/block/aoe/aoeblk.c | 21 +++--
drivers/block/aoe/aoedev.c | 1 -
3 files changed, 7 insertions(+), 16 deletions(-)
We should be registering the ns_id attribute as default sysfs
attribute groups, otherwise we have a race condition between
the uevent and the attributes appearing in sysfs.
Signed-off-by: Hannes Reinecke
---
drivers/nvme/host/core.c | 14 +++---
drivers/nvme/host/multipath.c | 12
Use device_add_disk_with_groups() to avoid a race condition with
udev during startup.
Signed-off-by: Hannes Reinecke
---
drivers/block/zram/zram_drv.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c
Am 24.07.2018 um 18:36 schrieb Coly Li:
> On 2018/7/24 4:33 PM, Stefan Priebe - Profihost AG wrote:
>> Am 24.07.2018 um 10:28 schrieb Coly Li:
>>> On 2018/7/24 3:16 PM, Stefan Priebe - Profihost AG wrote:
Am 24.07.2018 um 06:03 schrieb Coly Li:
> Commit b1092c9af9ed ("bcache: allow quick
72 matches
Mail list logo
