Memory management bug
Quoted 7 lines
Quoted 3 lines
before I hit yet another BUG in swap_state.c:60.
The bug in swap_state:60 shows a kernel bug in the VM or random memory corruption. Make sure you can reproduce on x86 to be sure it's not a s390 that is randomly corrupting memory. If you read the oops after the BUG
message
Quoted 1 line
with asm at hand you will see in the registers the value of
page->mapping
and
Quoted 3 lines
you can guess if it's random memory corruption or bug in VM this way (for example if `reg & 3 != 0' it's memory corruption for sure, you should also if it's pointing to a suitable kernel-heap address).
I did a little closer investigation. The BUG was triggered by a page with page->mapping pointing to an address space of a mapped ext2 file (page->mapping->a_ops == &ext2_aops). The page had PG_locked, PG_uptodate, PG_active and PG_swap_cache set. The stack backstrace showed that kswapd called do_try_to_free_pages, refill_inactive, swap_out, swap_out_mm, swap_out_vma, try_to_swap_out and add_to_swap_cache where BUG hit. The registers look good, the struct page looks good. I don't think that this
was a random memory corruption.
Quoted 3 lines
Quoted 1 line
Whats the reasoning behind these ifs ?
To catch memory corruption or things running out of control in the kernel.
I was refering to the "if (!order) goto try_again" ifs in alloc_pages, not the "if (something) BUG()" ifs.
blue skies,
Martin
Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · On Fri, 17 Nov 2000 [email protected] wrote:
Quoted 4 lines
Quoted 2 lines
Whats the reasoning behind these ifs ?
To catch memory corruption or things running out of control in the kernel.
I was refering to the "if (!order) goto
try_again" ifs inalloc_pages, not the "if (something)BUG()" ifs.
Basically, if you try to wait for orders > 0, you may have to wait for a LOONG time.
It actually works reasonably well on machines with big memories, because a buddy allocator _will_ try to coalesce memory allocations as much as possible. But it has nasty cases where you can be really unlucky. Feel free to run simulations to see, but basically if you have reasonably random allocation and free patterns and you want to get an order-X contiguous allocation, you may have to free up a noticeable portion of your memory before it succeeds.
Sure, you could do "directed freeing", where you actually try to look at which pages would be worth freeing to find a large free area, but the complexity is not insignificant, and quite frankly the proper approach has always been "don't do that then". Don't rely on big contiguous chunks of memory. Having an mm that can guarantee contiguous chunks of physical memory would be cool, but I suspect strongly that it would have some serious downsides.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 8 lines · On Fri, Nov 17, 2000 at 05:35:53PM +0100, [email protected] wrote:
I did a little closer investigation. The BUG was triggered by a page with
page->mappingpointing to an address space of a mapped ext2 file (page->mapping->a_ops==&ext2_aops). The page hadPG_locked,PG_uptodate,PG_activeandPG_swap_cacheset. The stack backstrace showed that kswapd calleddo_try_to_free_pages,refill_inactive,swap_out,swap_out_mm,swap_out_vma,try_to_swap_outandadd_to_swap_cachewhere BUG hit. The registers look good, the struct page looks good. I don't think that this was a random memory corruption.
Agreed, that's almost sure _not_ random memory corruption of the page structure. It looks like a VM bug (if you can reproduce trivially I'd give a try to test8 too since test8 is rock solid for me while test10 lockups in VM core at the second bonnie if using emulated highmem).
Quoted 2 lines
I was refering to the "if (!order) goto
try_again" ifs inalloc_pages, not the "if (something)BUG()" ifs.
Ah ok :), see Linus's answer: in your case the "don't do that" means to implement the:
#define SOFT_PAGE_SIZE (PAGE_SIZE<<2)
thing we were talking about yesterday of course.
Plus I add that the "if (!order) goto try_again" is an obvious deadlock prone bug introduce in test9 that should be removed.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 2 lines · Andrea Arcangeli
Plus I add that the "if (!order) goto
try_again" is an obvious deadlock prone bug introduce in test9 that should be removed.
1) how would this cause deadlocks?
2) how would this somehow be worse than the
unconditional 'goto try_again' we had before?
This goto is ok because we have the OOM killer, which will select a process to kill when we run out of memory. Also, the goto will make sure that OTHER processes will survive while the "guilty" process will be killed.
The guilty process will never get to the goto because it will have PF_MEMALLOC set.
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/