poll-related "scheduling while atomic", 2.5.44-mm6

DISCUSSION Paolo Ciarrocchi 2 participants 2 messages Oct 29, 2002 – Oct 30, 2002 Memory management

Share & tools

Paolo Ciarrocchi

author

2002-10-29 22:59 UTC #0 lore raw

Quoted 3 lines

Quoted 2 lines
So my guess is somewhere between -mm5 and -mm6 we
screwed up the atomicity count.
Mine too. I'll check it out, thanks.

The same here as well

Quoted 1 line

Do you have preemption enabled?

yes

Paolo

Signature · 1 line

Powered by Outblaze

Andrew Morton

2002-10-30 06:20 UTC #1 lore raw

Quoted 7 lines · Paolo Ciarrocchi

Quoted 4 lines
Quoted 3 lines
So my guess is somewhere between -mm5 and -mm6 we
screwed up the atomicity count.
Mine too. I'll check it out, thanks.
The same here as well

This'll fix it up. Whoever invented cut-n-paste has a lot to answer for.

mm/swap.c renamed from mm/swap.c~preempt-count-fix +3 -2

@@ -90,11 +90,12 @@ void lru_cache_add_active(struct page *p
 
 void lru_add_drain(void)
 {
-	struct pagevec *pvec = &per_cpu(lru_add_pvecs, get_cpu());
+	int cpu = get_cpu();
+	struct pagevec *pvec = &per_cpu(lru_add_pvecs, cpu);
 
 	if (pagevec_count(pvec))
 		__pagevec_lru_add(pvec);
-	pvec = &per_cpu(lru_add_active_pvecs, get_cpu());
+	pvec = &per_cpu(lru_add_active_pvecs, cpu);
 	if (pagevec_count(pvec))
 		__pagevec_lru_add_active(pvec);
 	put_cpu();

I had a crash while testing SMP+preempt btw. Nasty one - took a pagefault from userspace but do_page_fault() decided that the fault was in-kernel or something. It fell all the way through to die() and, well, died. I saw the same happen some months ago.