linux-kernel - Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 26 Oct 2017 15:44:55 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Adrian Hunter <adrian.hunter@...el.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        linux-mm@...ck.org
Subject: Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card

On Mon, Oct 23, 2017 at 11:27 PM, Pavel Machek <pavel@....cz> wrote:
> On Mon 2017-10-23 14:16:40, Linus Walleij wrote:
>> On Mon, Oct 23, 2017 at 11:31 AM, Pavel Machek <pavel@....cz> wrote:
>>
>> >> > Thinkpad X220... how do I tell if I was using them? I believe so,
>> >> > because I uncovered bug in them before.
>> >>
>> >> You are certainly using bounce buffers.  What does lspci -knn show?
>> >
>> > Here is the output:
>> > 0d:00.0 System peripheral [0880]: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823] (rev 07)
>> >         Subsystem: Lenovo Device [17aa:21da]
>> >         Kernel driver in use: sdhci-pci
>>
>> So that is a Ricoh driver, one of the few that was supposed to benefit
>> from bounce buffers.
>>
>> Except that if you actually turned it on:
>> > [10994.302196] kworker/2:1: page allocation failure: order:4,
>> so it doesn't have enough memory to use these bounce buffers
>> anyway.
>
> Well, look at archives: driver failed completely when allocation failed.

What I mean is that the allocation probably failed if you
explicitly turned on the bounce buffer also *before*
my patches (like if you were shopping for performance with
the Ricoh driver and turn on bounce buffers) but I haven't tested
it so what do I know.

You could check out b5b6a5f4f06c0624886b2166e2e8580327f0b943
and enable MMC_BLOCK_BOUNCE and see what happens.
And/or benchmark to see if it was actually improving your
system or not.

>> I'm now feel it was the right thing to delete them.
>
> Which means I may have been geting benefit -- when it worked. I
> believe solution is to allocate at driver probing time.

I think the right way to get this benefit is to enhance the
Ricoh SDMA path with something similar to:
commit 0ccd76d4c236 ("omap_hsmmc: Implement scatter-gather
       emulation")

What it does is loop over the sglist and smatter out one DMA
transfer per sg index.

It's likely faster than copying back and forth to a bounce
buffer even if there is a deal of HW talk back and forth.

> (OTOH ... SPI is slow compared to rest of the system, right? Where
> does the benefit come from?)

I do not think you will see much performance improvement
on an SPI-based host. Pierre just vaguely remembered "some
Ricoh controllers" would get a benefit from bounce buffers,
no specifics, sorry...

Yours,
Linus Walleij