On Wed, May 16, 2018 at 08:20:31PM -0600, Keith Busch wrote:
> On Thu, May 17, 2018 at 07:10:59AM +0800, Ming Lei wrote:
> > All simulation in block/011 may happen in reality.
>
> If this test actually simulates reality, then the following one line
> patch (plus explanation for why) would be a rea
Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
returns the return value of debugfs_create_dir() to bcache_init(). When
CONFIG_DEBUG_FS=n, bch_debug_init() always returns 1 and makes
bcache_init() failedi.
This patch makes bch_debug_init() always returns 0 if CONFIG_DEBU
2018-05-09 9:48 GMT+02:00 Christoph Hellwig :
> We only call into this function through the iomap iterators, so we already
> know the buffer is unwritten. In addition to that we always require the
> uptodate flag that is ORed with the result anyway.
Please update the page_cache_seek_hole_data des
On Thu, May 17, 2018 at 05:53:48PM +0800, Coly Li wrote:
> Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
> returns the return value of debugfs_create_dir() to bcache_init(). When
> CONFIG_DEBUG_FS=n, bch_debug_init() always returns 1 and makes
> bcache_init() failedi.
>
Omar, ping?
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9
On Thu, May 17, 2018 at 10:41:29AM +0200, Christoph Hellwig wrote:
> On Wed, May 16, 2018 at 08:20:31PM -0600, Keith Busch wrote:
> > On Thu, May 17, 2018 at 07:10:59AM +0800, Ming Lei wrote:
> > > All simulation in block/011 may happen in reality.
> >
> > If this test actually simulates reality,
On Thu, May 17, 2018 at 08:20:51AM -0600, Keith Busch wrote:
> > Heh. But yes, this test and the PCI "enable" interface in sysfs look
> > horribly wrong. pci_disable_device/pci_enable_device aren't something we
> > can just do underneath the driver. Even if injecting the lowlevel
> > config space
Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
returns the return value of debugfs_create_dir() to bcache_init(). When
CONFIG_DEBUG_FS=n, bch_debug_init() always returns 1 and makes
bcache_init() failedi.
This patch makes bch_debug_init() always returns 0 if CONFIG_DEBU
On 2018/5/17 7:35 PM, Kent Overstreet wrote:
> On Thu, May 17, 2018 at 05:53:48PM +0800, Coly Li wrote:
>> Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
>> returns the return value of debugfs_create_dir() to bcache_init(). When
>> CONFIG_DEBUG_FS=n, bch_debug_init() alw
On Thu, May 17, 2018 at 10:32:54PM +0800, Coly Li wrote:
> Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
> returns the return value of debugfs_create_dir() to bcache_init(). When
> CONFIG_DEBUG_FS=n, bch_debug_init() always returns 1 and makes
> bcache_init() failedi.
>
Hi Jenns,
We have reports that bcache does not work when CONFIG_DEBUG_FS=n, here is
the bug report on bugzilla.kernel.org:
https://bugzilla.kernel.org/show_bug.cgi?id=199683
This problem happens since v4.16 and I believe it still happens in v4.17.
This submission has one patch to fix this
Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
returns the return value of debugfs_create_dir() to bcache_init(). When
CONFIG_DEBUG_FS=n, bch_debug_init() always returns 1 and makes
bcache_init() failedi.
This patch makes bch_debug_init() always returns 0 if CONFIG_DEBU
On 5/17/18 9:33 AM, Coly Li wrote:
> Commit 539d39eb2708 ("bcache: fix wrong return value in bch_debug_init()")
> returns the return value of debugfs_create_dir() to bcache_init(). When
> CONFIG_DEBUG_FS=n, bch_debug_init() always returns 1 and makes
> bcache_init() failedi.
>
> This patch makes b
On Thu, 2017-10-19 at 16:21 -0400, Josef Bacik wrote:
> + blk_mq_start_request(req);
> if (unlikely(nsock->pending && nsock->pending != req)) {
> blk_mq_requeue_request(req, true);
> ret = 0;
(replying to an e-mail from seven months ago)
Hello Josef,
Are you
On Thu, May 17, 2018 at 06:21:40PM +, Bart Van Assche wrote:
> On Thu, 2017-10-19 at 16:21 -0400, Josef Bacik wrote:
> > + blk_mq_start_request(req);
> > if (unlikely(nsock->pending && nsock->pending != req)) {
> > blk_mq_requeue_request(req, true);
> > ret = 0;
>
On Thu, 2018-05-17 at 14:41 -0400, Josef Bacik wrote:
> Yup I can tell you why, on 4.11 where I originally did this work
> __blk_mq_requeue_request() did this
>
> static void __blk_mq_requeue_request(struct request *rq)
> {
> struct request_queue *q = rq->q;
>
> trace_block_rq_req
From: Adam Manzanares
This is the per-I/O equivalent of the ioprio_set system call.
See the following link for performance implications on a SATA HDD:
https://lkml.org/lkml/2016/12/6/495
First patch factors ioprio_check_cap function out of ioprio_set system call to
also be used by the aio ioprio
From: Adam Manzanares
Aio per command iopriority support introduces a second interface between
userland and the kernel capable of passing iopriority. The aio interface also
needs the ability to verify that the submitting context has sufficient
priviledges to submit IOPRIO_RT commands. This patch
From: Adam Manzanares
In order to avoid kiocb bloat for per command iopriority support, rw_hint
is converted from enum to a u16. Added a guard around ki_hint assigment.
Signed-off-by: Adam Manzanares
---
include/linux/fs.h | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
From: Adam Manzanares
This is the per-I/O equivalent of the ioprio_set system call.
When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the
newly added kiocb ki_ioprio field to the value in the iocb aio_reqprio field.
When a bio is created for an aio request by the block dev w
On Tue, 2018-05-08 at 21:33 -0400, Kent Overstreet wrote:
> [ ... ]
Hello Kent,
With Jens' latest for-next branch I hit the kernel warning shown below. Can
you have a look?
Thanks,
Bart.
==
BUG: KASAN: use-after-free in bio_advan
On Wed, May 16, 2018 at 08:20:31PM -0600, Keith Busch wrote:
> Hi Ming,
>
> I'm developing the answers in code the issues you raised. It will just
> take a moment to complete flushing those out. In the meantime just want
> to point out why I think block/011 isn't a real test.
>
> On Thu, May 17,
On Fri, May 18, 2018 at 08:19:58AM +0800, Ming Lei wrote:
> On Wed, May 16, 2018 at 08:20:31PM -0600, Keith Busch wrote:
> > Hi Ming,
> >
> > I'm developing the answers in code the issues you raised. It will just
> > take a moment to complete flushing those out. In the meantime just want
> > to po
On 5/17/18 2:38 PM, adam.manzana...@wdc.com wrote:
> From: Adam Manzanares
>
> This is the per-I/O equivalent of the ioprio_set system call.
> See the following link for performance implications on a SATA HDD:
> https://lkml.org/lkml/2016/12/6/495
>
> First patch factors ioprio_check_cap functio
24 matches
Mail list logo