On Wed, 27 Sep 2017 21:45:58 +0200 Linus Walleij wrote:
> On Wed, Sep 27, 2017 at 1:35 PM, Adrian Hunter
> wrote:
> >
> > BUG when removing, fixed by reverting this patch.
> >
> > [ 346.548512] mmc1: card 0001 removed
> > [ 346.552782] BUG: unable to handle kernel NULL pointer dereference at
On 2017/9/28 3:45, Linus Walleij wrote:
On Wed, Sep 27, 2017 at 1:35 PM, Adrian Hunter wrote:
BUG when removing, fixed by reverting this patch.
[ 346.548512] mmc1: card 0001 removed
[ 346.552782] BUG: unable to handle kernel NULL pointer dereference at
0070
How did you achiev
Hi Shahua,
On 17/9/28 05:38, Shaohua Li wrote:
> On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote:
>>
>>
>> On 17/9/26 10:48, Shaohua Li wrote:
>>> On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote:
Hi Shaohua,
On 17/9/26 01:22, Shaohua Li wrote:
> On Mon, Sep 2
On 09/28/2017 06:13 AM, Liu Bo wrote:
MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if
badblocks are disabled, otherwise, rdev_set_badblocks() will record
superblock changes and return success in that case and md will fail to
report an IO error which it should.
This bug has
On 2017/9/28 上午4:52, Jens Axboe wrote:
> On 09/27/2017 10:48 PM, Michael Lyle wrote:
>> Jens--
>>
>> I think it's a race condition-- the individual closures remain valid.
>> It's just that the list element has different meanings-- it's either a
>> list actively being used to wake, or a linkage on o
MD's rdev_set_badblocks() expects that badblocks_set() returns 1 if
badblocks are disabled, otherwise, rdev_set_badblocks() will record
superblock changes and return success in that case and md will fail to
report an IO error which it should.
This bug has existed since badblocks were introduced in
On Tue, Sep 26, 2017 at 11:16:05AM +0800, Joseph Qi wrote:
>
>
> On 17/9/26 10:48, Shaohua Li wrote:
> > On Tue, Sep 26, 2017 at 09:06:57AM +0800, Joseph Qi wrote:
> >> Hi Shaohua,
> >>
> >> On 17/9/26 01:22, Shaohua Li wrote:
> >>> On Mon, Sep 25, 2017 at 06:46:42PM +0800, Joseph Qi wrote:
> >>>
On 09/27/2017 10:48 PM, Michael Lyle wrote:
> Jens--
>
> I think it's a race condition-- the individual closures remain valid.
> It's just that the list element has different meanings-- it's either a
> list actively being used to wake, or a linkage on one of several lists
> that is being used to a
Jens--
I think it's a race condition-- the individual closures remain valid.
It's just that the list element has different meanings-- it's either a
list actively being used to wake, or a linkage on one of several lists
that is being used to await wake. If a closure goes back to wait very
quickly
On 09/26/2017 11:54 AM, Coly Li wrote:
> Commit 09b3efec ("bcache: Don't reinvent the wheel but use existing llist
> API") replaces the following while loop by llist_for_each_entry(),
If it's fixing a specific commit, please add a proper
Fixes: sha ("title")
line to your patch. That way automate
On 09/27/2017 09:16 PM, Coly Li wrote:
> Hi Jens,
>
> Could you please take a look on this patch? It will be helpful if we can
> have it in 4.14, then we can fix a bug introduced in 4.14-rc1.
>
> This patch is reported by Michael Lyle, reviewed by Byungchul Park, and
> finally verified by Michael
On Wed, Sep 27, 2017 at 2:02 PM, Adrian Hunter wrote:
> On 27/09/17 02:42, Linus Walleij wrote:
>> On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter
>> wrote:
>>
>>> Until mmc has blk-mq support fully implemented and tested, add a
>>> parameter use_blk_mq, default to false unless config option MMC_
On Wed, Sep 27, 2017 at 1:35 PM, Adrian Hunter wrote:
>
> BUG when removing, fixed by reverting this patch.
>
> [ 346.548512] mmc1: card 0001 removed
> [ 346.552782] BUG: unable to handle kernel NULL pointer dereference at
> 0070
How did you achieve this? I need to reproduce it.
R
On 09/27/2017 07:36 PM, Linus Torvalds wrote:
> On Wed, Sep 27, 2017 at 5:41 AM, Jens Axboe wrote:
>>
>> So I reworked the series, to include three prep patches that end up
>> killing off free_more_memory(). This means that we don't have to do the
>> 1024 -> 0 change in there. On top of that, I ad
Hi Jens,
Could you please take a look on this patch? It will be helpful if we can
have it in 4.14, then we can fix a bug introduced in 4.14-rc1.
This patch is reported by Michael Lyle, reviewed by Byungchul Park, and
finally verified by Michael Lyle after I posted the patch.
Many thanks in advan
On Wed, Sep 27, 2017 at 5:41 AM, Jens Axboe wrote:
>
> So I reworked the series, to include three prep patches that end up
> killing off free_more_memory(). This means that we don't have to do the
> 1024 -> 0 change in there. On top of that, I added a separate bit to
> manage range cyclic vs non r
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Linus Walleij
> Sent: Wednesday, September 27, 2017 2:42 AM
> To: Adrian Hunter
> Cc: Ulf Hansson ; linux-mmc m...@vger.kernel.org>; linux-block ; linux-
> kernel ; Boug
Travel stable again, catching up. Chris did a great job explaining what
our issues were, so thanks for that.
On 09/26/2017 12:21 AM, Linus Torvalds wrote:
> On Mon, Sep 25, 2017 at 2:17 PM, Chris Mason wrote:
>>
>> My understanding is that for order-0 page allocations and
>> kmem_cache_alloc(buf
On 27/09/17 02:42, Linus Walleij wrote:
> On Fri, Sep 22, 2017 at 2:36 PM, Adrian Hunter
> wrote:
>
>> Until mmc has blk-mq support fully implemented and tested, add a
>> parameter use_blk_mq, default to false unless config option MMC_MQ_DEFAULT
>> is selected.
>>
>> Signed-off-by: Adrian Hunter
BUG when removing, fixed by reverting this patch.
[ 346.548512] mmc1: card 0001 removed
[ 346.552782] BUG: unable to handle kernel NULL pointer dereference at
0070
[ 346.561539] IP: kernfs_find_ns+0xe/0xc0
[ 346.565822] PGD 179dc5067 P4D 179dc5067 PUD 171106067 PMD 0
[ 346.5721
On Wed, Sep 27, 2017 at 03:12:47AM +, Bart Van Assche wrote:
> On Tue, 2017-09-26 at 22:59 +0800, Ming Lei wrote:
> > On Tue, Sep 26, 2017 at 02:42:07PM +, Bart Van Assche wrote:
> > > On Tue, 2017-09-26 at 19:17 +0800, Ming Lei wrote:
> > > > Just test this patch a bit and the following fa
On Wed, Sep 27, 2017 at 09:54:09AM +, Bart Van Assche wrote:
> On Wed, 2017-09-27 at 13:48 +0800, Ming Lei wrote:
> > @@ -2928,12 +2929,28 @@ scsi_device_quiesce(struct scsi_device *sdev)
> > {
> > int err;
> >
> > + /*
> > +* Simply quiesing SCSI device isn't safe, it is easy
> >
On Wed, 2017-09-27 at 13:48 +0800, Ming Lei wrote:
> @@ -2928,12 +2929,28 @@ scsi_device_quiesce(struct scsi_device *sdev)
> {
> int err;
>
> + /*
> + * Simply quiesing SCSI device isn't safe, it is easy
> + * to use up requests because all these allocated requests
> + *
On Wed, Sep 27, 2017 at 04:27:51PM +0800, Ming Lei wrote:
> On Wed, Sep 27, 2017 at 09:57:37AM +0200, Martin Steigerwald wrote:
> > Hi Ming.
> >
> > Ming Lei - 27.09.17, 13:48:
> > > Hi,
> > >
> > > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock.
> > >
> > > Once SCSI devic
On Wed, Sep 27, 2017 at 09:57:37AM +0200, Martin Steigerwald wrote:
> Hi Ming.
>
> Ming Lei - 27.09.17, 13:48:
> > Hi,
> >
> > The current SCSI quiesce isn't safe and easy to trigger I/O deadlock.
> >
> > Once SCSI device is put into QUIESCE, no new request except for
> > RQF_PREEMPT can be disp
I just fixed the problem you pointed out, and ran a test where I did
sync;fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1
--name=test --filename=test --bs=8k --iodepth=256 --size=25G
--readwrite=randwrite --ramp_time=4
to generate a lot of 8k extents.
After letting things quiet d
Hi Ming.
Ming Lei - 27.09.17, 13:48:
> Hi,
>
> The current SCSI quiesce isn't safe and easy to trigger I/O deadlock.
>
> Once SCSI device is put into QUIESCE, no new request except for
> RQF_PREEMPT can be dispatched to SCSI successfully, and
> scsi_device_quiesce() just simply waits for complet
Tang--
This is a first step towards further stuff I want to do--
1. I want to allow blk_plug-- but to do that, a request needs to know
there are subsequent contiguous requests after it when issuing the
write. The new structure allows that.
2. I want to allow tuning to issue multiple requests and
From: Tang Junhui
Hello Mike:
For the second question, I thinks this modification is somewhat complex,
cannot we do something simple to resolve it? I remember there were some
patches trying to avoid too small writeback rate, Coly, is there any
progress now?
---
Tang Junhui
Ah-- re #1 -- I was investigating earlier why not as much was combined
as I thought should be when idle. This is surely a factor. Thanks
for the catch-- KEY_OFFSET is correct. I will fix and retest.
(Under heavy load, the correct thing still happens, but not under
light or intermediate load0.
30 matches
Mail list logo
