On Tue, 06 Aug 2013 15:26:23 +0200 Wladislav Wiebe <wladislav.kw@xxxxxxxxx> wrote: > 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? kmalloc_large() only exists in slub, so this will break slab and slob builds. Did you try adding __GFP_NOWARN? That's appropriate in this case. -- 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
