Skip to contentSkip to conversation

aa-160-lru_release_check

PATCH Andrew Morton 6 participants 7 messages Mar 20, 2002

Subsystems (2)
Memory management Page allocator
lore
Share & tools
lore

Andrew Morton

author
#0 lore raw

Hugh's much-discussed check for releasing pages which are still on the LRU.

=====================================

mm/page_alloc.c renamed from mm/page_alloc.c~aa-160-lru_release_check +4 -1
@@ -102,8 +102,11 @@ static void __free_pages_ok (struct page
 	/* Yes, think what happens when other parts of the kernel take 
 	 * a reference to a page in order to pin it for io. -ben
 	 */
-	if (PageLRU(page))
+	if (PageLRU(page)) {
+		if (unlikely(in_interrupt()))
+			BUG();
 		lru_cache_del(page);
+	}
 
 	if (page->buffers)
 		BUG();

-

#1 lore raw

mm/page_alloc.c static void __free_pages_ok (struct page · line 107

Quoted 4 lines · Andrew Morton

...

mm/page_alloc.c renamed from mm/page_alloc.c~aa-160-lru_release_check +2 -0
+		if (unlikely(in_interrupt()))
+			BUG();
...

Is there a reason against intruducing BUG_ON in 2.4? It makes such things more readable.

cu
Adrian

#2 lore raw
In reply to Andrew Morton
Quoted 10 lines · Adrian Bunk

mm/page_alloc.c static void __free_pages_ok (struct page · line 107

Quoted 4 lines · Andrew Morton

...

mm/page_alloc.c renamed from mm/page_alloc.c~aa-160-lru_release_check +2 -0
+		if (unlikely(in_interrupt()))
+			BUG();
...

Is there a reason against intruducing BUG_ON in 2.4? It makes such things more readable.

I think there are plans to do so...

... But not in this patch.

author
#3 lore raw
In reply to Andrew Morton
Quoted 11 lines · Adrian Bunk

mm/page_alloc.c static void __free_pages_ok (struct page · line 107

Quoted 4 lines · Andrew Morton

...

mm/page_alloc.c renamed from mm/page_alloc.c~aa-160-lru_release_check +2 -0
+             if (unlikely(in_interrupt()))
+                     BUG();
...

Is there a reason against intruducing BUG_ON in 2.4? It makes such things more readable.

I hate BUG_ON() :) It's arse-about so you have to stare at it furiously to understand why your kernel still works.

I hope the Nobel committee is reading this mailing list: how about assert()?

-

#5 lore raw
In reply to Andrew Morton
Quoted 6 lines · Andrew Morton

I hate BUG_ON() :) It's arse-about so you have to stare at it furiously to understand why your kernel still works.

I hope the Nobel committee is reading this mailing list: how about assert()?

I vote 'aye'

It's the same thing just in another name.

I would call it kassert or fixup existing places that use 'assert' first, though.

Jeff

#6 lore raw
In reply to Andrew Morton
Quoted 4 lines · Andrew Morton
Quoted 2 lines

Is there a reason against intruducing BUG_ON in 2.4? It makes such things more readable.

I hate BUG_ON() :) It's arse-about so you have to stare at it furiously to understand why your kernel still works.

Preach on brother Morton.

Quoted 2 lines

I hope the Nobel committee is reading this mailing list: how about assert()?

Quite a few places in the kernel already are.
See drivers/net/pci-skeleton.c for one.

Signature · 2 lines
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
#4 lore raw
In reply to Andrew Morton
Quoted 5 lines · Andrew Morton

I hate BUG_ON() :) It's arse-about so you have to stare at it furiously to understand why your kernel still works.

I hope the Nobel committee is reading this mailing list: how about assert()?

I have a patch that introduces BUG_ON for 2.4. I like the idea of BUG_ON and it is certainly a place where the unlikely bit is useful. I've posted the patch here before; I was going to do so again against the next 2.4-pre.

Further, and most importantly, the patch provides compatibility with 2.5 code that uses it. I have no problems naming BUG_ON anything anyone wants (Jeff's suggestion of kassert seems sane) but we should then do the proper renaming in 2.5.

Robert Love