Hello FS community,
on a PPC 32-Bit board with a Linux Kernel v3.10.0 I see that seq_read tries to allocate
for a procfs entry 8 MB (max. should be 4 MB). It's basically a Device Tree entry (/proc/device-tree/localbus@5000/flash@0/partition@1/reg)
and why it needs 8 MB now, I don't know - the same Device Tree works fine on previous Kernel releases.
When it's happen it throw warnings from with kmalloc_slab.
I added some debug functions to seq_read, to see when allocating 8 MB or more
(Marked "DEBUG xxx ...")
..
UBI: background thread "ubi_bgt0d" started, PID 895
DEBUG xxx seq_read: m->size = 8388608
DEBUG xxx seq_read: path = /proc/device-tree/localbus@5000/flash@0/partition@1/reg
------------[ cut here ]------------
WARNING: at /var/fpwork/wiebe/newfsm/bld/bld-kernelsources-linux/results/linux/mm/slab_common.c:377
Modules linked in: ubi mddg_post(O) mddg_rpram(O) mddg_system_driver(O) mddg_watchdog(O)
CPU: 0 PID: 903 Comm: hexdump Tainted: G O 3.10.0-0-sampleversion-fcmd #60
task: cf97c230 ti: cfbf0000 task.ti: cfbf0000
NIP: c0098d98 LR: c00acf1c CTR: 00000000
REGS: cfbf1da0 TRAP: 0700 Tainted: G O (3.10.0-0-sampleversion-fcmd)
MSR: 00029000 <CE,EE,ME> CR: 22008444 XER: 00000000
GPR00: c00d2100 cfbf1e50 cf97c230 00800000 000000d0 00000000 ce7ffffc 00000000
GPR08: 00400000 c0380000 00000001 cfbf1e50 22008444 100a24dc 00000001 c030e2d0
GPR16: cfacac88 c030e2b0 007fffff fffff000 c028c80c 00000000 cfbf1e80 00000400
GPR24: 4801c000 cfbdf4e0 00000000 00000000 c00d2100 00000000 000000d0 cfacac80
NIP [c0098d98] kmalloc_slab+0x24/0xb0
LR [c00acf1c] __kmalloc+0x1c/0x154
Call Trace:
[cfbf1e50] [c00ac4d0] kfree+0x6c/0x120 (unreliable)
[cfbf1e70] [c00d2100] seq_read+0x328/0x5d4
[cfbf1ee0] [c00fb8b8] proc_reg_read+0x5c/0x90
[cfbf1ef0] [c00b27b8] vfs_read+0xa4/0x150
[cfbf1f10] [c00b29a8] SyS_read+0x4c/0x84
[cfbf1f40] [c000be3c] ret_from_syscall+0x0/0x3c
--- Exception: c01 at 0xfe63934
LR = 0xfe1a6a8
Instruction dump:
7c631910 7c6300d0 4e800020 3d200040 7f834840 409d003c 708a0200 39200000
40a20094 3d20c038 8949fe89 694a0001 <0f0a0000> 2f8a0000 39200000 41be0078
---[ end trace d2ede23251d61cd0 ]---
DEBUG xxx seq_read: m->size = 8388608
DEBUG xxx seq_read: path = /proc/device-tree/localbus@5000/flash@0/partition@1/reg
UBIFS: recovery needed
..
Basically we discussed this a bit with MM guys,
at the end there was a proposal from Christoph Lameter <cl@xxxxxxxxx> of using kmalloc_large instead of kmalloc.
####################
There is no point in using the slab allocation functions for
large page order allocation. Use kmalloc_large().
This fixes the warning about large allocs but it will still cause
large contiguous allocs that could fail because of memory fragmentation.
Signed-off-by: Christoph Lameter <cl@xxxxxxxxx>
Index: linux/fs/seq_file.c
===================================================================
--- linux.orig/fs/seq_file.c 2013-07-31 10:39:03.050472030 -0500
+++ linux/fs/seq_file.c 2013-07-31 10:39:03.050472030 -0500
@@ -136,7 +136,7 @@ static int traverse(struct seq_file *m,
Eoverflow:
m->op->stop(m, p);
kfree(m->buf);
- m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
+ m->buf = kmalloc_large(m->size <<= 1, GFP_KERNEL);
return !m->buf ? -ENOMEM : -EAGAIN;
}
@@ -232,7 +232,7 @@ ssize_t seq_read(struct file *file, char
goto Fill;
m->op->stop(m, p);
kfree(m->buf);
- m->buf = kmalloc(m->size <<= 1, GFP_KERNEL);
+ m->buf = kmalloc_large(m->size <<= 1, GFP_KERNEL);
if (!m->buf)
goto Enomem;
m->count = 0;
####################
What do you think about this, or do we have other alternatives?
Because with current Kernel releases is this kmalloc_large function not accessible in a easy "include and use" way.
you can follow the MM thread here:
http://linuxppc.10917.n7.nabble.com/mm-slab-ppc-ubi-kmalloc-slab-WARNING-PPC-UBI-driver-td74404.html
Thanks & BR,
Wladislav Wiebe
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
