From:  dipankar@in.ibm.com
  Well, my earlier find_first_bit() implementation was completely bogus.
  My sanity has now returned and I coded this patch below that fixes 
  find_find_bit() to return "size" if all bits are zero. I have tested it 
  extensively in userspace and it boots 2.5.44-mm5 which crashed with the earlier
  version of the bitops_fix patch. I have coded the assembly routine
  as optimal as I could think of and without introducing any new
  branches or memory loads.
  
  Along with this patch, I applied the larger_cpu_mask patch to -mm5
  and sanity tested both UP and SMP kernels for dcache leaks in a 4CPU P3 box.
  An ls -lR and subsequent unmounting of that filesystems showed that
  the dentries were correctly getting returned the dcache slab and
  that indicates that the larger_cpu_mask patch no longer breaks RCU.
  I will do some more testing with this combination later with
  rcu_stats applied on this tree (just to be sure), but so far it looks good.
  
  Thanks
  -- 
  Dipankar Sarma  <dipankar@in.ibm.com> http://lse.sourceforge.net
  Linux Technology Center, IBM Software Lab, Bangalore, India.
  
  
  bitops_fix.patch
  -----------------
  
--- trivial-2.5-bk/include/asm-i386/bitops.h.orig	2002-11-08 18:47:20.000000000 +1100
+++ trivial-2.5-bk/include/asm-i386/bitops.h	2002-11-08 18:47:20.000000000 +1100
@@ -311,12 +311,13 @@
 		"repe; scasl\n\t"
 		"jz 1f\n\t"
 		"leal -4(%%edi),%%edi\n\t"
-		"bsfl (%%edi),%%eax\n"
-		"1:\tsubl %%ebx,%%edi\n\t"
+		"bsfl (%%edi),%%edx\n"
+		"subl %%ebx,%%edi\n\t"
 		"shll $3,%%edi\n\t"
-		"addl %%edi,%%eax"
+		"addl %%edi,%%edx\n\t"
+		"1:\tmovl %%edx,%%eax\n\t"
 		:"=a" (res), "=&c" (d0), "=&D" (d1)
-		:"1" ((size + 31) >> 5), "2" (addr), "b" (addr));
+		:"1" ((size + 31) >> 5), "2" (addr), "b" (addr), "d" (size));
 	return res;
 }
 
-- Don't blame me: the Monkey is driving File: dipankar@in.ibm.com: Re: [long]2.5.44-mm3 UP went into unexpected trashing - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/