linux-kernel - Question pertaining to request_threaded

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAEtk5gdUeaCEtj6wG_ScuazNm=q74u0QBJ70Lz-x8+vXrzYnaw@mail.gmail.com>
Date:	Wed, 20 Mar 2013 00:12:32 -0700
From:	Vijay Dixit <thelonejoker@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Question pertaining to request_threaded_irq

Hello,
I am new to the Kernel-Mailing list. I am not subscribed at the moment
and would really appreciate it, if I can be CC'd in the
reply/responses for my question.

I have searched all over the web but haven't found a convincing answer
to a couple of related questions I have, with regard to the
"request_threaded_irq" feature.

---Firstly, I was reading this article, regarding threaded IRQ's:

http://lwn.net/Articles/302043/

and there is this one line that isn't clear to me:

"Converting an interrupt to threaded makes only sense when the handler
code takes advantage of it by integrating tasklet/softirq
functionality and simplifying the locking."

I understand had we gone ahead with a "traditional", top half/bottom
half approach, we would have needed either spin-locks or disable local
IRQ to meddle with shared data. But, what I don't understand is, how
would threaded interrupts simplify the need for locking by integrating
tasklet/softirq functionality.

---Secondly, what advantage (if any), does a request_threaded_handler
approach have over a work_queue based bottom half approach ? In both
cases it seems, as though the "work" is deferred to a dedicated
thread. So, what is the difference ?

---Lastly, in the following prototype:

int request_threaded_irq(unsigned int irq, irq_handler_t handler,
irq_handler_t thread_fn, unsigned long irqflags, const char *devname,
void *dev_id)

Is it possible that the "handler" part of the IRQ is continuously
triggered by the relevant IRQ (say a UART receving characters at a
high rate), even while the "thread_fn"(writing rx'd bytes to a
circular buffer) part of the interrupt handler is busy processing
IRQ's from previous wakeups ? So, wouldn't the handler be trying to
"wakeup" an already running "thread_fn" ? How would the running irq
thread_fn behave in that case ?

I would really appreciate if someone can help me understand this.

Thanks,
vj
--
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/