Messages in this thread | | | Date | Fri, 4 Jul 2008 11:55:08 +0900 | From | "Magnus Damm" <> | Subject | Re: [PATCH] uio: User IRQ Mode |
| |
On Fri, Jul 4, 2008 at 4:55 AM, Hans J. Koch <hjk@linutronix.de> wrote: > On Thu, Jul 03, 2008 at 10:23:16PM +0900, Paul Mundt wrote: >> On Thu, Jul 03, 2008 at 02:45:05PM +0200, Hans J. Koch wrote: >> > On Thu, Jul 03, 2008 at 09:10:19AM +0200, Uwe Kleine-K??nig wrote: >> > > Moreover this might prevent some bugs. (And obviously this >> > > function has the potential to have a buggy implementation as >> > > the comment by Alan Cox shows.) >> > >> > For me, this shows two things: >> > >> > - I never ever had to use disable_irq_nosync() in any UIO driver yet, >> > otherwise I would have noticed. >> > >> > - Magnus turned in a patch that he never tested. >> > >> Note that the deadlock in question is in relation to SMP, it's true that >> the patch was never tested in an SMP environment and only on UP, but it >> certainly was tested. > > Ok, so I take back that accusation ;-)
That's good, thank you. In the future it would be even better if you didn't accuse to begin with, since that will only heat up the discussion.
> Nonetheless, the patch changes a UIO core file, and everything in there > should work in all situations on all architectures unless there is a > _very_ good reason to do something different. This not only applies to > SMP issues but also to the limitation to non-shared interrupts.
I will resolve the SMP issue and repost, no problem.
>> The vast majority of driver writers don't have a >> need to use disable_irq_nosync(), so whether you've had to use it or not >> is largely irrelevant to the conversation at hand ;-) > > Sure ;-) I merely wanted to point out that this is an unusual way to > handle an interrupt.
Grep shows that there is nothing unusual about it.
damm@rx1 ~/git/linux-2.6 $ find drivers/ | xargs grep -m 1 -e [[:blank:]]disable_irq\( -e [[:blank:]]disable_irq_nosync\( | wc -l 105
/ magnus
| |