linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Linus Walleij <linus.walleij@linaro.org>,
	Adrian Hunter <adrian.hunter@intel.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Pavel Machek <pavel@ucw.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	linux-mm@kvack.org
Subject: Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
Date: Wed, 4 Oct 2017 10:01:45 +0200	[thread overview]
Message-ID: <CAPDyKFo+KehnATz5RWJN0JngZAYdCEd-EEjXbv9y8oU_Q1Leaw@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdYPn3xxZQP+xXggPpoHercBL3L7dmMBnbXww5SEsFx5tg@mail.gmail.com>

On 4 October 2017 at 09:53, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Oct 3, 2017 at 8:30 AM, Adrian Hunter <adrian.hunter@intel.com> wrote:
>> On 02/10/17 17:09, Linus Walleij wrote:
>>> On Sun, Oct 1, 2017 at 12:57 PM, Tetsuo Handa
>>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>>
>>>>>> I inserted u-SD card, only to realize that it is not detected as it
>>>>>> should be. And dmesg indeed reveals:
>>>>>
>>>>> Tetsuo asked me to report this to linux-mm.
>>>>>
>>>>> But 2^4 is 16 pages, IIRC that can't be expected to work reliably, and
>>>>> thus this sounds like MMC bug, not mm bug.
>>>
>>>
>>> I'm not sure I fully understand this error message:
>>> "worker/2:1: page allocation failure: order:4"
>>>
>>> What I guess from context is that the mmc_init_request()
>>> call is failing to allocate 16 pages, meaning for 4K pages
>>> 64KB which is the typical bounce buffer.
>>>
>>> This is what the code has always allocated as bounce buffer,
>>> but it used to happen upfront, when probing the MMC block layer,
>>> rather than when allocating the requests.
>>
>> That is not exactly right.  As I already wrote, the memory allocation used
>> to be optional but became mandatory with:
>>
>>   commit 304419d8a7e9204c5d19b704467b814df8c8f5b1
>>   Author: Linus Walleij <linus.walleij@linaro.org>
>>   Date:   Thu May 18 11:29:32 2017 +0200
>>
>>       mmc: core: Allocate per-request data using the block layer core
>
> Yes you are right, it used to look like this, with the bounce buffer
> hiding behind a Kconfig symbol:
>
> #ifdef CONFIG_MMC_BLOCK_BOUNCE
>     if (host->max_segs == 1) {
>         unsigned int bouncesz;
>
>         bouncesz = MMC_QUEUE_BOUNCESZ;
>
>         if (bouncesz > host->max_req_size)
>             bouncesz = host->max_req_size;
>         if (bouncesz > host->max_seg_size)
>             bouncesz = host->max_seg_size;
>         if (bouncesz > (host->max_blk_count * 512))
>             bouncesz = host->max_blk_count * 512;
>
>         if (bouncesz > 512 &&
>             mmc_queue_alloc_bounce_bufs(mq, bouncesz)) {
>             blk_queue_bounce_limit(mq->queue, BLK_BOUNCE_ANY);
>             blk_queue_max_hw_sectors(mq->queue, bouncesz / 512);
>             blk_queue_max_segments(mq->queue, bouncesz / 512);
>             blk_queue_max_segment_size(mq->queue, bouncesz);
>
>             ret = mmc_queue_alloc_bounce_sgs(mq, bouncesz);
>             if (ret)
>                 goto cleanup_queue;
>             bounce = true;
>         }
>     }
> #endif
>
> I recently concluded that I find no evidence whatsoever that anyone
> turned this symbol on. Actually. (Checked defconfigs and distro configs.)
> The option was just sitting there unused.
> This code was never exercised except by some people who turned it
> on on their custom kernels in the past. It's in practice dead code.
>
> My patch started to allocate and use bounce buffers for all hosts
> with max_segs == 1, unless specifically flagged NOT to use bounce
> buffers.
>
> That wasn't smart, I should have just deleted them. Mea culpa.
>
> So that is why I asked Ulf to simply put the patch deleting the bounce
> buffers that noone is using to fixes, and it should fix this problem.

Adrian, Linus,

Thanks for looking into the problem! I am queuing up the patch
deleting bounce buffers for fixes asap!

Kind regards
Uffe

  reply	other threads:[~2017-10-04  8:01 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-05 19:47 4.13 on thinkpad x220: oops when writing to SD card Pavel Machek
2017-09-06  2:44 ` Shawn Lin
2017-09-06  6:03   ` Adrian Hunter
2017-09-07  7:18     ` Ulf Hansson
2017-09-07  7:53       ` Adrian Hunter
2017-09-07 10:47         ` Seraphime Kirkovski
2017-09-07 12:06         ` Ulf Hansson
2017-09-07 12:55           ` Pavel Machek
2017-09-07 15:03             ` Ulf Hansson
2017-09-08  8:51           ` Pavel Machek
2017-09-07 19:58         ` Linus Walleij
2017-09-07 20:02       ` Linus Walleij
2017-09-08  2:51         ` Shawn Lin
2017-09-12  9:42           ` Linus Walleij
2017-09-13  4:04             ` Shawn Lin
2017-10-01  9:37 ` 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card Pavel Machek
2017-10-01 10:26   ` Pavel Machek
2017-10-01 10:57     ` Tetsuo Handa
2017-10-02  7:52       ` Adrian Hunter
2017-10-02  8:41         ` Pavel Machek
2017-10-02 12:06           ` Linus Walleij
2017-10-02 13:03             ` Pavel Machek
2017-10-03  6:27               ` Adrian Hunter
2017-10-23  9:31                 ` Pavel Machek
2017-10-23 12:13                   ` Adrian Hunter
2017-10-23 12:16                   ` Linus Walleij
2017-10-23 21:27                     ` Pavel Machek
2017-10-24  6:59                       ` Adrian Hunter
2017-10-26 13:44                       ` Linus Walleij
2017-10-02 14:09       ` Linus Walleij
2017-10-03  6:30         ` Adrian Hunter
2017-10-04  7:53           ` Linus Walleij
2017-10-04  8:01             ` Ulf Hansson [this message]
2017-10-02 14:44     ` Michal Hocko
2017-10-02 14:55       ` Tetsuo Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPDyKFo+KehnATz5RWJN0JngZAYdCEd-EEjXbv9y8oU_Q1Leaw@mail.gmail.com \
    --to=ulf.hansson@linaro.org \
    --cc=adrian.hunter@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).