linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-mm@kvack.org, linus walleij <linus.walleij@linaro.org>
Subject: Re: 4.14-rc2 on thinkpad x220: out of memory when inserting mmc card
Date: Mon, 2 Oct 2017 10:41:31 +0200	[thread overview]
Message-ID: <20171002084131.GA24414@amd> (raw)
In-Reply-To: <72c93a69-610f-027e-c028-379b97b6f388@intel.com>

[-- Attachment #1: Type: text/plain, Size: 3889 bytes --]

Hi!

> 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
> 
> There is also a bug in mmc_init_request() where it doesn't free it's
> allocations on the error path, so you might want to check if you are leaking
> memory.

At this point, I don't really care about memory leaks.

But allocating 64KiB, and expecting the allocation to work is quite a
big no-no. Does code need to switch to vmalloc or something?

> Bounce buffers are being removed from v4.15 although you may experience
> performance regression with that:
> 
> 	https://marc.info/?l=linux-mmc&m=150589778700551

Hmm. The performance of this is already pretty bad, I really hope it
does not get any worse.

								Pavel

> 
> 
> On 01/10/17 13:57, Tetsuo Handa wrote:
> > Pavel Machek wrote:
> >> Hi!
> >>
> >>> 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.
> > 
> > Yes, 16 pages is costly allocations which will fail without invoking the
> > OOM killer. But I thought this is an interesting case, for mempool
> > allocation should be able to handle memory allocation failure except
> > initial allocations, and initial allocation is failing.
> > 
> > I think that using kvmalloc() (and converting corresponding kfree() to
> > kvfree()) will make initial allocations succeed, but that might cause
> > needlessly succeeding subsequent mempool allocations under memory pressure?
> > 
> >>
> >>> [10994.299846] mmc0: new high speed SDHC card at address 0003
> >>> [10994.302196] kworker/2:1: page allocation failure: order:4,
> >>> mode:0x16040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK), nodemask=(null)
> >>> [10994.302212] CPU: 2 PID: 9500 Comm: kworker/2:1 Not tainted
> >>> 4.14.0-rc2 #135
> >>> [10994.302215] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET73WW
> >>> (1.43 ) 10/12/2016
> >>> [10994.302222] Workqueue: events_freezable mmc_rescan
> >>> [10994.302227] Call Trace:
> >>> [10994.302233]  dump_stack+0x4d/0x67
> >>> [10994.302239]  warn_alloc+0xde/0x180
> >>> [10994.302243]  __alloc_pages_nodemask+0xaa4/0xd30
> >>> [10994.302249]  ? cache_alloc_refill+0xb73/0xc10
> >>> [10994.302252]  cache_alloc_refill+0x101/0xc10
> >>> [10994.302258]  ? mmc_init_request+0x2d/0xd0
> >>> [10994.302262]  ? mmc_init_request+0x2d/0xd0
> >>> [10994.302265]  __kmalloc+0xaf/0xe0
> >>> [10994.302269]  mmc_init_request+0x2d/0xd0
> >>> [10994.302273]  alloc_request_size+0x45/0x60
> >>> [10994.302276]  ? free_request_size+0x30/0x30
> >>> [10994.302280]  mempool_create_node+0xd7/0x130
> >>> [10994.302283]  ? alloc_request_simple+0x20/0x20
> >>> [10994.302287]  blk_init_rl+0xe8/0x110
> >>> [10994.302290]  blk_init_allocated_queue+0x70/0x180
> >>> [10994.302294]  mmc_init_queue+0xdd/0x370
> >>> [10994.302297]  mmc_blk_alloc_req+0xf6/0x340
> >>> [10994.302301]  mmc_blk_probe+0x18b/0x4e0
> >>> [10994.302305]  mmc_bus_probe+0x12/0x20
> >>> [10994.302309]  driver_probe_device+0x2f4/0x490
> >>>
> >>> Order 4 allocations are not supposed to be reliable...
> >>>
> >>> Any ideas?
> >>>
> >>> Thanks,
> >>> 									Pavel
> >>>
> >>
> >>
> >>
> >> -- 
> >> (english) http://www.livejournal.com/~pavelmachek
> >> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-10-02  8:41 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 [this message]
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
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=20171002084131.GA24414@amd \
    --to=pavel@ucw.cz \
    --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=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).