* Page allocation failure on v3.8-rc5
@ 2013-01-28 9:10 Felipe Balbi
2013-01-30 11:53 ` Ming Lei
0 siblings, 1 reply; 4+ messages in thread
From: Felipe Balbi @ 2013-01-28 9:10 UTC (permalink / raw)
To: Linux USB Mailing List, linux-mm
[-- Attachment #1: Type: text/plain, Size: 7730 bytes --]
Hi,
The following page allocation failure triggers sometimes when I plug my
memory card reader on a USB port.
[850845.928795] usb 1-4: new high-speed USB device number 48 using ehci-pci
[850846.300702] usb 1-4: New USB device found, idVendor=0bda, idProduct=0119
[850846.300707] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[850846.300711] usb 1-4: Product: USB2.0-CRW
[850846.300715] usb 1-4: Manufacturer: Generic
[850846.300718] usb 1-4: SerialNumber: 20090815198100000
[850846.302733] scsi86 : usb-storage 1-4:1.0
[850847.304359] scsi 86:0:0:0: Direct-Access Generic- SD/MMC 1.00 PQ: 0 ANSI: 0 CCS
[850847.305734] sd 86:0:0:0: Attached scsi generic sg4 type 0
[850848.456294] sd 86:0:0:0: [sdd] 7911424 512-byte logical blocks: (4.05 GB/3.77 GiB)
[850848.457160] sd 86:0:0:0: [sdd] Write Protect is off
[850848.457166] sd 86:0:0:0: [sdd] Mode Sense: 03 00 00 00
[850848.458054] sd 86:0:0:0: [sdd] No Caching mode page present
[850848.458060] sd 86:0:0:0: [sdd] Assuming drive cache: write through
[850848.461502] sd 86:0:0:0: [sdd] No Caching mode page present
[850848.461507] sd 86:0:0:0: [sdd] Assuming drive cache: write through
[850848.461963] kworker/u:0: page allocation failure: order:4, mode:0x2000d0
[850848.461969] Pid: 7122, comm: kworker/u:0 Tainted: G W 3.8.0-rc4+ #206
[850848.461972] Call Trace:
[850848.461984] [<ffffffff810d02a8>] ? warn_alloc_failed+0x116/0x128
[850848.461991] [<ffffffff810d31d9>] ? __alloc_pages_nodemask+0x6b5/0x751
[850848.462000] [<ffffffff81106297>] ? kmem_getpages+0x59/0x129
[850848.462006] [<ffffffff81106b88>] ? fallback_alloc+0x12f/0x1fc
[850848.462013] [<ffffffff811071c7>] ? kmem_cache_alloc_trace+0x87/0xf6
[850848.462021] [<ffffffff812a633c>] ? check_partition+0x28/0x1ac
[850848.462027] [<ffffffff812a60bd>] ? rescan_partitions+0xa4/0x27c
[850848.462034] [<ffffffff8113bcfb>] ? __blkdev_get+0x1ac/0x3d2
[850848.462040] [<ffffffff8113c0b1>] ? blkdev_get+0x190/0x2d8
[850848.462046] [<ffffffff8113b23f>] ? bdget+0x3b/0x12b
[850848.462052] [<ffffffff812a41a6>] ? add_disk+0x268/0x3e2
[850848.462058] [<ffffffff81382f3d>] ? sd_probe_async+0x11b/0x1cc
[850848.462066] [<ffffffff81055f74>] ? async_run_entry_fn+0xa2/0x173
[850848.462072] [<ffffffff81055ed2>] ? async_schedule+0x15/0x15
[850848.462079] [<ffffffff8104bb79>] ? process_one_work+0x172/0x2ca
[850848.462084] [<ffffffff8104b88a>] ? manage_workers+0x22a/0x23c
[850848.462090] [<ffffffff81055ed2>] ? async_schedule+0x15/0x15
[850848.462096] [<ffffffff8104bfa4>] ? worker_thread+0x11d/0x1b7
[850848.462102] [<ffffffff8104be87>] ? rescuer_thread+0x18c/0x18c
[850848.462109] [<ffffffff81050421>] ? kthread+0x86/0x8e
[850848.462116] [<ffffffff8105039b>] ? __kthread_parkme+0x60/0x60
[850848.462125] [<ffffffff814a306c>] ? ret_from_fork+0x7c/0xb0
[850848.462132] [<ffffffff8105039b>] ? __kthread_parkme+0x60/0x60
[850848.462135] Mem-Info:
[850848.462138] Node 0 DMA per-cpu:
[850848.462143] CPU 0: hi: 0, btch: 1 usd: 0
[850848.462147] CPU 1: hi: 0, btch: 1 usd: 0
[850848.462151] CPU 2: hi: 0, btch: 1 usd: 0
[850848.462154] CPU 3: hi: 0, btch: 1 usd: 0
[850848.462158] CPU 4: hi: 0, btch: 1 usd: 0
[850848.462161] CPU 5: hi: 0, btch: 1 usd: 0
[850848.462165] CPU 6: hi: 0, btch: 1 usd: 0
[850848.462168] CPU 7: hi: 0, btch: 1 usd: 0
[850848.462171] Node 0 DMA32 per-cpu:
[850848.462176] CPU 0: hi: 186, btch: 31 usd: 0
[850848.462180] CPU 1: hi: 186, btch: 31 usd: 0
[850848.462183] CPU 2: hi: 186, btch: 31 usd: 0
[850848.462185] CPU 3: hi: 186, btch: 31 usd: 0
[850848.462187] CPU 4: hi: 186, btch: 31 usd: 0
[850848.462189] CPU 5: hi: 186, btch: 31 usd: 0
[850848.462192] CPU 6: hi: 186, btch: 31 usd: 0
[850848.462194] CPU 7: hi: 186, btch: 31 usd: 0
[850848.462196] Node 0 Normal per-cpu:
[850848.462199] CPU 0: hi: 186, btch: 31 usd: 0
[850848.462201] CPU 1: hi: 186, btch: 31 usd: 0
[850848.462203] CPU 2: hi: 186, btch: 31 usd: 0
[850848.462206] CPU 3: hi: 186, btch: 31 usd: 0
[850848.462208] CPU 4: hi: 186, btch: 31 usd: 0
[850848.462210] CPU 5: hi: 186, btch: 31 usd: 0
[850848.462212] CPU 6: hi: 186, btch: 31 usd: 0
[850848.462215] CPU 7: hi: 186, btch: 31 usd: 0
[850848.462222] active_anon:24837 inactive_anon:19982 isolated_anon:0
[850848.462222] active_file:452273 inactive_file:418905 isolated_file:32
[850848.462222] unevictable:0 dirty:2445 writeback:0 unstable:0
[850848.462222] free:66997 slab_reclaimable:515526 slab_unreclaimable:12480
[850848.462222] mapped:4698 shmem:82 pagetables:2389 bounce:0
[850848.462222] free_cma:0
[850848.462228] Node 0 DMA free:15904kB min:168kB low:208kB high:252kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15680kB managed:15904kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[850848.462237] lowmem_reserve[]: 0 3012 6042 6042
[850848.462242] Node 0 DMA32 free:167276kB min:33604kB low:42004kB high:50404kB active_anon:0kB inactive_anon:3888kB active_file:1009068kB inactive_file:932732kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3084512kB managed:3051044kB mlocked:0kB dirty:3440kB writeback:0kB mapped:1748kB shmem:8kB slab_reclaimable:927596kB slab_unreclaimable:10460kB kernel_stack:64kB pagetables:336kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[850848.462251] lowmem_reserve[]: 0 0 3030 3030
[850848.462256] Node 0 Normal free:84808kB min:33804kB low:42252kB high:50704kB active_anon:99348kB inactive_anon:76040kB active_file:800024kB inactive_file:742888kB unevictable:0kB isolated(anon):0kB isolated(file):128kB present:3102720kB managed:3055508kB mlocked:0kB dirty:6340kB writeback:0kB mapped:17044kB shmem:320kB slab_reclaimable:1134508kB slab_unreclaimable:39460kB kernel_stack:2760kB pagetables:9220kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[850848.462265] lowmem_reserve[]: 0 0 0 0
[850848.462269] Node 0 DMA: 0*4kB 0*8kB 0*16kB 1*32kB (U) 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (R) 3*4096kB (M) = 15904kB
[850848.462287] Node 0 DMA32: 15740*4kB (UEM) 8959*8kB (UEM) 1829*16kB (UEM) 52*32kB (UEM) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 1*1024kB (R) 1*2048kB (R) 0*4096kB = 169016kB
[850848.462305] Node 0 Normal: 11559*4kB (UEM) 4308*8kB (UEM) 110*16kB (UEM) 2*32kB (R) 1*64kB (R) 0*128kB 1*256kB (R) 1*512kB (R) 1*1024kB (R) 1*2048kB (R) 0*4096kB = 86428kB
[850848.462324] 873577 total pagecache pages
[850848.462326] 2290 pages in swap cache
[850848.462328] Swap cache stats: add 100017, delete 97727, find 335070/338652
[850848.462330] Free swap = 11973912kB
[850848.462332] Total swap = 12037116kB
[850848.499266] 1572848 pages RAM
[850848.499269] 41638 pages reserved
[850848.499271] 910353 pages shared
[850848.499272] 962690 pages non-shared
[850848.499276] SLAB: Unable to allocate memory on node 0 (gfp=0xd0)
[850848.499279] cache: size-65536, object size: 65536, order: 4
[850848.499286] node 0: slabs: 42/42, objs: 42/42, free: 0
[850848.502355] sd 86:0:0:0: [sdd] No Caching mode page present
[850848.502361] sd 86:0:0:0: [sdd] Assuming drive cache: write through
[850848.502366] sd 86:0:0:0: [sdd] Attached SCSI removable disk
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Page allocation failure on v3.8-rc5
2013-01-28 9:10 Page allocation failure on v3.8-rc5 Felipe Balbi
@ 2013-01-30 11:53 ` Ming Lei
2013-01-31 23:43 ` Andrew Morton
0 siblings, 1 reply; 4+ messages in thread
From: Ming Lei @ 2013-01-30 11:53 UTC (permalink / raw)
To: balbi; +Cc: Linux USB Mailing List, linux-mm, linux-kernel, Jens Axboe
On Mon, Jan 28, 2013 at 5:10 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> The following page allocation failure triggers sometimes when I plug my
> memory card reader on a USB port.
>
>
> [850845.928795] usb 1-4: new high-speed USB device number 48 using ehci-pci
> [850846.300702] usb 1-4: New USB device found, idVendor=0bda, idProduct=0119
> [850846.300707] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [850846.300711] usb 1-4: Product: USB2.0-CRW
> [850846.300715] usb 1-4: Manufacturer: Generic
> [850846.300718] usb 1-4: SerialNumber: 20090815198100000
> [850846.302733] scsi86 : usb-storage 1-4:1.0
> [850847.304359] scsi 86:0:0:0: Direct-Access Generic- SD/MMC 1.00 PQ: 0 ANSI: 0 CCS
> [850847.305734] sd 86:0:0:0: Attached scsi generic sg4 type 0
> [850848.456294] sd 86:0:0:0: [sdd] 7911424 512-byte logical blocks: (4.05 GB/3.77 GiB)
> [850848.457160] sd 86:0:0:0: [sdd] Write Protect is off
> [850848.457166] sd 86:0:0:0: [sdd] Mode Sense: 03 00 00 00
> [850848.458054] sd 86:0:0:0: [sdd] No Caching mode page present
> [850848.458060] sd 86:0:0:0: [sdd] Assuming drive cache: write through
> [850848.461502] sd 86:0:0:0: [sdd] No Caching mode page present
> [850848.461507] sd 86:0:0:0: [sdd] Assuming drive cache: write through
> [850848.461963] kworker/u:0: page allocation failure: order:4, mode:0x2000d0
> [850848.461969] Pid: 7122, comm: kworker/u:0 Tainted: G W 3.8.0-rc4+ #206
> [850848.461972] Call Trace:
> [850848.461984] [<ffffffff810d02a8>] ? warn_alloc_failed+0x116/0x128
> [850848.461991] [<ffffffff810d31d9>] ? __alloc_pages_nodemask+0x6b5/0x751
> [850848.462000] [<ffffffff81106297>] ? kmem_getpages+0x59/0x129
> [850848.462006] [<ffffffff81106b88>] ? fallback_alloc+0x12f/0x1fc
> [850848.462013] [<ffffffff811071c7>] ? kmem_cache_alloc_trace+0x87/0xf6
> [850848.462021] [<ffffffff812a633c>] ? check_partition+0x28/0x1ac
> [850848.462027] [<ffffffff812a60bd>] ? rescan_partitions+0xa4/0x27c
> [850848.462034] [<ffffffff8113bcfb>] ? __blkdev_get+0x1ac/0x3d2
> [850848.462040] [<ffffffff8113c0b1>] ? blkdev_get+0x190/0x2d8
> [850848.462046] [<ffffffff8113b23f>] ? bdget+0x3b/0x12b
> [850848.462052] [<ffffffff812a41a6>] ? add_disk+0x268/0x3e2
> [850848.462058] [<ffffffff81382f3d>] ? sd_probe_async+0x11b/0x1cc
> [850848.462066] [<ffffffff81055f74>] ? async_run_entry_fn+0xa2/0x173
> [850848.462072] [<ffffffff81055ed2>] ? async_schedule+0x15/0x15
> [850848.462079] [<ffffffff8104bb79>] ? process_one_work+0x172/0x2ca
> [850848.462084] [<ffffffff8104b88a>] ? manage_workers+0x22a/0x23c
> [850848.462090] [<ffffffff81055ed2>] ? async_schedule+0x15/0x15
> [850848.462096] [<ffffffff8104bfa4>] ? worker_thread+0x11d/0x1b7
> [850848.462102] [<ffffffff8104be87>] ? rescuer_thread+0x18c/0x18c
> [850848.462109] [<ffffffff81050421>] ? kthread+0x86/0x8e
> [850848.462116] [<ffffffff8105039b>] ? __kthread_parkme+0x60/0x60
> [850848.462125] [<ffffffff814a306c>] ? ret_from_fork+0x7c/0xb0
> [850848.462132] [<ffffffff8105039b>] ? __kthread_parkme+0x60/0x60
The allocation failure is caused by the big sizeof(struct parsed_partitions),
which is 64K in my 32bit box, could you test the blow patch to see
if it can fix the allocation failure?
--
diff --git a/block/partition-generic.c b/block/partition-generic.c
index f1d1451..043d0bd 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -525,7 +525,7 @@ rescan:
md_autodetect_dev(part_to_dev(part)->devt);
#endif
}
- kfree(state);
+ release_partitions(state);
return 0;
}
diff --git a/block/partitions/check.c b/block/partitions/check.c
index bc90867..d89eef7 100644
--- a/block/partitions/check.c
+++ b/block/partitions/check.c
@@ -14,6 +14,7 @@
*/
#include <linux/slab.h>
+#include <linux/vmalloc.h>
#include <linux/ctype.h>
#include <linux/genhd.h>
@@ -106,18 +107,43 @@ static int (*check_part[])(struct parsed_partitions *) = {
NULL
};
+struct parsed_partitions *allocate_partitions(int nr)
+{
+ struct parsed_partitions *state;
+
+ state = kzalloc(sizeof(struct parsed_partitions), GFP_KERNEL);
+ if (!state)
+ return NULL;
+
+ state->parts = vzalloc(nr * sizeof(state->parts[0]));
+ if (!state->parts) {
+ kfree(state);
+ return NULL;
+ }
+
+ return state;
+}
+
+void release_partitions(struct parsed_partitions *state)
+{
+ vfree(state->parts);
+ kfree(state);
+}
+
struct parsed_partitions *
check_partition(struct gendisk *hd, struct block_device *bdev)
{
struct parsed_partitions *state;
int i, res, err;
- state = kzalloc(sizeof(struct parsed_partitions), GFP_KERNEL);
+ i = disk_max_parts(hd);
+ state = allocate_partitions(i);
if (!state)
return NULL;
+ state->limit = i;
state->pp_buf = (char *)__get_free_page(GFP_KERNEL);
if (!state->pp_buf) {
- kfree(state);
+ release_partitions(state);
return NULL;
}
state->pp_buf[0] = '\0';
@@ -128,10 +154,9 @@ check_partition(struct gendisk *hd, struct
block_device *bdev)
if (isdigit(state->name[strlen(state->name)-1]))
sprintf(state->name, "p");
- state->limit = disk_max_parts(hd);
i = res = err = 0;
while (!res && check_part[i]) {
- memset(&state->parts, 0, sizeof(state->parts));
+ memset(state->parts, 0, state->limit * sizeof(state->parts[0]));
res = check_part[i++](state);
if (res < 0) {
/* We have hit an I/O error which we don't report now.
@@ -161,6 +186,6 @@ check_partition(struct gendisk *hd, struct
block_device *bdev)
printk(KERN_INFO "%s", state->pp_buf);
free_page((unsigned long)state->pp_buf);
- kfree(state);
+ release_partitions(state);
return ERR_PTR(res);
}
diff --git a/block/partitions/check.h b/block/partitions/check.h
index 52b1003..8323808 100644
--- a/block/partitions/check.h
+++ b/block/partitions/check.h
@@ -15,13 +15,15 @@ struct parsed_partitions {
int flags;
bool has_info;
struct partition_meta_info info;
- } parts[DISK_MAX_PARTS];
+ } *parts;
int next;
int limit;
bool access_beyond_eod;
char *pp_buf;
};
+extern void release_partitions(struct parsed_partitions *state);
+
struct parsed_partitions *
check_partition(struct gendisk *, struct block_device *);
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: Page allocation failure on v3.8-rc5
2013-01-30 11:53 ` Ming Lei
@ 2013-01-31 23:43 ` Andrew Morton
2013-02-01 0:33 ` Ming Lei
0 siblings, 1 reply; 4+ messages in thread
From: Andrew Morton @ 2013-01-31 23:43 UTC (permalink / raw)
To: Ming Lei
Cc: balbi, Linux USB Mailing List, linux-mm, linux-kernel, Jens Axboe
On Wed, 30 Jan 2013 19:53:22 +0800
Ming Lei <ming.lei@canonical.com> wrote:
> The allocation failure is caused by the big sizeof(struct parsed_partitions),
> which is 64K in my 32bit box,
Geeze.
We could fix that nicely by making parsed_partitions.parts an array of
pointers to a single `struct parsed_partition' and allocating those
on-demand.
But given the short-lived nature of this storage and the infrequency of
check_partition(), that isn't necessary.
> could you test the blow patch to see
> if it can fix the allocation failure?
(The patch is wordwrapped)
> ...
>
> @@ -106,18 +107,43 @@ static int (*check_part[])(struct parsed_partitions *) = {
> NULL
> };
>
> +struct parsed_partitions *allocate_partitions(int nr)
> +{
> + struct parsed_partitions *state;
> +
> + state = kzalloc(sizeof(struct parsed_partitions), GFP_KERNEL);
I personally prefer sizefo(*state) here. It means the reader doesn't
have to scroll back to check things.
> + if (!state)
> + return NULL;
> +
> + state->parts = vzalloc(nr * sizeof(state->parts[0]));
> + if (!state->parts) {
> + kfree(state);
> + return NULL;
> + }
It doesn't really need to be this complex - we could just vmalloc the
entire `struct parsed_partitions'. But I see that your change will
cause us to allcoate much less memory in many situations, which is
good. It should be mentioned in the changelog!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Page allocation failure on v3.8-rc5
2013-01-31 23:43 ` Andrew Morton
@ 2013-02-01 0:33 ` Ming Lei
0 siblings, 0 replies; 4+ messages in thread
From: Ming Lei @ 2013-02-01 0:33 UTC (permalink / raw)
To: Andrew Morton
Cc: balbi, Linux USB Mailing List, linux-mm, linux-kernel, Jens Axboe
On Fri, Feb 1, 2013 at 7:43 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 30 Jan 2013 19:53:22 +0800
> Ming Lei <ming.lei@canonical.com> wrote:
>
>> The allocation failure is caused by the big sizeof(struct parsed_partitions),
>> which is 64K in my 32bit box,
>
> Geeze.
>
> We could fix that nicely by making parsed_partitions.parts an array of
> pointers to a single `struct parsed_partition' and allocating those
> on-demand.
>
> But given the short-lived nature of this storage and the infrequency of
> check_partition(), that isn't necessary.
>
>> could you test the blow patch to see
>> if it can fix the allocation failure?
>
> (The patch is wordwrapped)
Sorry for that, I send out it for test.
>
>> ...
>>
>> @@ -106,18 +107,43 @@ static int (*check_part[])(struct parsed_partitions *) = {
>> NULL
>> };
>>
>> +struct parsed_partitions *allocate_partitions(int nr)
>> +{
>> + struct parsed_partitions *state;
>> +
>> + state = kzalloc(sizeof(struct parsed_partitions), GFP_KERNEL);
>
> I personally prefer sizefo(*state) here. It means the reader doesn't
> have to scroll back to check things.
OK, will use sizeof(*state).
>> + if (!state)
>> + return NULL;
>> +
>> + state->parts = vzalloc(nr * sizeof(state->parts[0]));
>> + if (!state->parts) {
>> + kfree(state);
>> + return NULL;
>> + }
>
> It doesn't really need to be this complex - we could just vmalloc the
> entire `struct parsed_partitions'. But I see that your change will
The above approach can save one 32K allocation approximately.
> cause us to allcoate much less memory in many situations, which is
> good. It should be mentioned in the changelog!
OK, I will add the changelog later.
Thanks,
--
Ming Lei
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-02-01 0:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-28 9:10 Page allocation failure on v3.8-rc5 Felipe Balbi
2013-01-30 11:53 ` Ming Lei
2013-01-31 23:43 ` Andrew Morton
2013-02-01 0:33 ` Ming Lei
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).