Messages in this thread | | | Date | Mon, 25 Feb 2008 14:17:26 -0800 | From | Andrew Morton <> | Subject | Re: 2.6.24-git: kmap_atomic() WARN_ON() |
| |
On Mon, 25 Feb 2008 23:01:59 +0100 (CET) Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 25 Feb 2008, Andrew Morton wrote: > > On Mon, 25 Feb 2008 15:08:35 -0500 Jeff Garzik <jgarzik@pobox.com> wrote: > > > There are plenty of drivers that do the same thing that ahci does, in > > > terms of interrupt handler locking... and I will definitely push back > > > on efforts to convert otherwise-100%-safe spin_lock() into > > > spin_lock_irqsave() just to quiet lockdep. > > > > > > Very interesting email, thanks... > > > > > > > I suspect this is a bug in my old kmap_atomic debugging patch. It doesn't > > know about the implicit irq-disablememnt which interrupt handlers enjoy. I > > don't think... > > I suspect here is confusion. The implicit irq-disablement of lockdep > is actually hiding the warning. > > The code which emits the warning is: > > if (type == KM_IRQ0 || type == KM_IRQ1 || type == KM_BOUNCE_READ || > type == KM_BIO_SRC_IRQ || type == KM_BIO_DST_IRQ) { > if (!irqs_disabled()) { > WARN_ON(1); > warn_count--; > } > > It checks for _NOT_ irqs_disabled. The calling code is > ata_scsi_rbuf_get() which calls with: > > buf = kmap_atomic(sg_page(sg), KM_IRQ0) + sg->offset; > > This happens with interrupts enabled. So the warning is according to > the well documented km_type enum and the equally well documented > highmem debug code correct. > > Bjoern decoded it very well, just Jeff jumped to very interesting > conclusions. >
Ah, OK, yes. ata is wrong. It must disable interrupts here. Otherwise this CPU could get interrupted by some other device whose handler also uses KM_IRQ0, resulting in data corruption.
| |