The memory allocation used to be optional but became mandatory with:
commit 304419d8a7e9204c5d19b704467b814df8c8f5b1
Author: Linus Walleij <linus.walleij@xxxxxxxxxx>
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.
Bounce buffers are being removed from v4.15 although you may experience
performance regression with that:
https://marc.info/?l=linux-mmc&m=150589778700551
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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
