I have tried with GFP_HIGHUSER and I am able to allocate 1M buffers of 24 bytes. But, it is not solving my purpose as it is coming from high memory and I need to map it from ZONE_HIGHMEM to ZONE_NORMAL before using.
I want to know why this panic is coming if I am giving GFP_KERNEL ? 1) May be that no more memory is available ? ( but it should return NULL in that case) 2) Or is it the responsibility of the module writer to handle this condition ? 3) Is there any BUG in kmem_cache_alloc that it goes panic instead of returning NULL or error ? regards -- Gagan "Find what you love, and love what you find". On Wed, Jul 9, 2008 at 2:56 PM, Lin Ming <[EMAIL PROTECTED]> wrote: > Disagree. > > kmalloc allocates from kmalloc_caches, > if kmalloc(24, ..), internally it allocates 32 (2^5) bytes. > > > On Wed, Jul 2, 2008 at 9:08 PM, Rajat Jain <[EMAIL PROTECTED]> > wrote: > >> Hi, >> >> Although kmalloc() gives you 24 bytes per call that you can use, >> but internally it allocates in pages, and hence 1 page (=4K bytes in each >> iteration) >> >> HTH, >> >> Rajat >> >> ------------------------------ >> *From:* [EMAIL PROTECTED] [mailto: >> [EMAIL PROTECTED] *On Behalf Of *gagan grover >> *Sent:* Wednesday, July 02, 2008 12:59 PM >> *To:* [email protected] >> *Subject:* getting panic during kmalloc >> >> Hi >> I have a requirement of creating 1M buffers of 24 bytes. >> So, my driver is calling kmalloc in loop but it is giving following panic >> after some iterations. >> System have 4 GB RAM and I was continuosly checking top, it had sufficient >> memory to allocate. >> >> ----------- [cut here ] --------- [please bite here ] --------- >> Kernel BUG at slab:1773 >> invalid operand: 0000 [1] SMP >> CPU 3 >> Modules linked in: dbg(U) md5 ipv6 parport_pc lp parport autofs4 i2c_dev >> i2c_core nfs lockd nfs_acl sunrpc rdma_ucm(U) rdma_cm(U) ib_addr(U) ds >> yenta_socked >> Pid: 16998, comm: dbg_fmr_create Not tainted 2.6.9-42.ELsmp >> RIP: 0010:[<ffffffff80161949>] <ffffffff80161949>{cache_alloc_refill+409} >> RSP: 0018:0000010134709e08 EFLAGS: 00010002 >> RAX: 0000000000000000 RBX: 00000100bff6f728 RCX: 00000100bff6f6e8 >> RDX: 00000100bff50000 RSI: 0000000000000018 RDI: 00000100bff6f728 >> RBP: 00000100bfe56000 R08: 0000000000000007 R09: 000001013162b000 >> R10: 0000000000000000 R11: 0000000000000000 R12: 00000100bff6f6c8 >> R13: 00000100bff6f680 R14: 0000000000000018 R15: 0000000000000003 >> FS: 0000002a95579b00(0000) GS:ffffffff804e5200(0000) >> knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b >> CR2: 00000036ea2befc0 CR3: 0000000005da4000 CR4: 00000000000006e0 >> Process dbg_fmr_create (pid: 16998, threadinfo 0000010134708000, task >> 0000010135cb4030) >> Stack: 0000000000000018 0000000000000018 00000100bff6f680 0000010130000000 >> 000001013162b000 0000007fbfffed20 0000000000000003 ffffffff8016174f >> 0000000000000202 0000000000003067 >> Call Trace:<ffffffff8016174f>{kmem_cache_alloc+90} >> <ffffffffa02571bc>{:dbg:dbg_fmr_create+114} >> <ffffffffa025252c>{:dbg:dbg_handle_ioctls+8712} >> <ffffffff8018ae05>{sys_ioctl+853} >> <ffffffff8011026a>{system_call+126} >> >> Code: 0f 0b cc 5d 32 80 ff ff ff ff ed 06 31 d2 41 f7 c6 00 20 00 >> RIP <ffffffff80161949>{cache_alloc_refill+409} RSP <0000010134709e08> >> <0>Kernel panic - not syncing: Oops >> >> -- >> "Find what you love, and love what you find". >> >> >
