| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 15 Apr 2010 08:58:47 -0700 From: Dan Williams <dan.j.williams@...el.com> To: melwyn lobo <linux.melwyn@...il.com> Cc: linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org Subject: Re: DMA Engine API performance issues On Thu, Apr 15, 2010 at 2:13 AM, melwyn lobo <linux.melwyn@...il.com> wrote: > Thanks so much for your explanation. > OK..Looking at IPU implementation, irq handling is enrtirely in the > interrupt routine, therefore no need for spin_lock_bh stuff. > But for lower interrupt latency reasons we need to stick with the > tasklet handling for processing interrupts. > > We were contemplating another solution for locking at our end for DMA > implementation > For locking > if(irqs_disabled()) > spin_lock(&chan->lock); > else > spin_lock_bh(&chan->lock); > > for unlocking: > if(irqs_disabled()) > spin_unlock(&chan->lock); > else > spin_unlock_bh(&chan->lock); > > Although this works fine, but will this be OK when we submit the driver. > This won't work and lockdep should complain about this situation. The minute you need to take the lock in the interrupt handler then all other occurrences of the lock need to be promoted to _irq or _irqsave() [1]. -- Dan [1]: http://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/c214.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists