Greetings,
	Just a quick recap - there are at least 4 reports of 2.6.15 users 
experiencing severe slab leaks with scsi_cmd_cache. It seems that a few of us 
have a board (Asus P5GDC-V Deluxe) in common. We seem to have raid in common. 
	After dealing with this leak for a while, I decided to do some dancing around 
with git bisect. I've landed on a possible point of regression:

commit: a9701a30470856408d08657eb1bd7ae29a146190
[PATCH] md: support BIO_RW_BARRIER for md/raid1

	I spent about an hour and a half reading through the patch, trying to see if 
I could make sense of what might be wrong. The result (after I dug into the 
code to make a change I foolishly thought made sense) was a hung kernel.
	This is important because when I rebooted into the kernel that had been 
giving me trouble, it started an md resync and I'm now watching (at least 
during this resync) the slab usage for scsi_cmd_cache stay sane:

turbotaz ~ # cat /proc/slabinfo | grep scsi_cmd_cache
scsi_cmd_cache        30     30    384   10    1 : tunables   54   27    8 : 
slabdata      3      3      0

	I guess I'm going to have to wait for this resync to finish and see if the 
slab leak starts back up.
	Other data: I've done an mdadm --stop on my raid1 /boot partition, leaving 
only my raid10 / partition active. The slab continues to leak long after md0 
(raid1) is stopped. Boot is also never mounted except when explicitly needed.
	As I was going through bisect iterations, the cache on good kernels would 
report no more than 9 objects right after boot (granted, I built the bisect 
kernels with support for basically nothing but my USB keyboard and SATA). The 
bad kernels would vary from 350 on up to somewhere around 600 right after 
boot.
	All bisect kernels were built from the same .config, and "make clean; make 
mrproper" was executed between each compile. (Do I really need to do that? 
How does git handle timestamps? I assumed I didn't really need to but did it 
to be thorough).
	I've attached my bisect log in case anyone wants to trace my steps, as well 
as the config I was using to build the bisect kernels.
	I can't rule Neil's patch out as being inherently responsible, but I'm sure 
lots of people are using it now, so perhaps issuing these barriers in 
md_super_write are having an interaction elsewhere?
	I thought super_written_barrier looked funny in terms of how bio_put is 
called on the original bio before the barrier bio is sent to super_written 
(looked backwards), but altering it caused the hang. I guess I'm not quite 
there yet in understanding block IO :P

Thanks,
Chase