From: Jeff Garzik <jeff@garzik.org>
To: Rene Herman <rene.herman@keyaccess.nl>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Adrian Bunk <bunk@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
rmk@arm.linux.org.uk, "Eric W. Biederman" <ebiederm@xmission.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [git patch] free_irq() fixes
Date: Wed, 23 Apr 2008 22:10:35 -0400 [thread overview]
Message-ID: <480FEC1B.6040102@garzik.org> (raw)
In-Reply-To: <480F3ECC.1090809@keyaccess.nl>
Rene Herman wrote:
> On 23-04-08 02:16, Linus Torvalds wrote:
>
>> On Wed, 23 Apr 2008, Adrian Bunk wrote:
>>> If it goes like the regs removal in one big patch around -rc1 into
>>> your tree this shouldn't be a problem.
>>
>> Well, the regs removal had a real upside (it wasn't even sensible for
>> all irq types), and really nobody used it apart from "system users"
>> (ie Sysrq etc).
>>
>> I'm still waiting for anybody mentioning any upside at _all_ on
>> removing "irq".
>
> Saves another 4 bytes of stack? :-/ Seriously, Jeff can probably better
> answer himself but when this was posted before:
>
> http://lkml.org/lkml/2007/5/19/23
>
> Eric Biederman said it fit nicely into his "nefarious plan of making
> everything use a struct irq pointer". A later mention:
>
> http://lkml.org/lkml/2007/10/19/66
>
> got strong ACKs from Thomas Gleixner, Ingo Molnar and Greg KH. Remember
> due to working on a local driver at the time and deleting the "irq"
> argument usage from its handler (unneccesarily used in a debugging
> printk) from it in response.
Thanks. I was hoping that some of the people who expressed interest in
prior threads would appear.
Answering Linus's question, the things I tend to think of are
* it's not used in overwhelming majority of cases
* irq number has morphed over time with MSI-X and APICs and such from a
direct "reference" to a hardware line to a more abstract cookie value.
* the need for a struct [pci_]device everywhere means drivers have ready
access to irq number _anyway_
* it has clearly led to many helpful cleanups and bug fixes, by both me
and others [and yes, for the sake of argument I'm excluding those
discussed in this thread]
* it helps clean up abuses like HPET where it is used to encode data
(ignoring dev_id unnecessarily... I posted a patch to fix this):
if (rtc_int_flag) {
rtc_int_flag |= (RTC_IRQF | (RTC_NUM_INTS << 8));
if (irq_handler)
irq_handler(rtc_int_flag, dev_id);
}
["irq_handler" is a function passed to request_irq, as well as being
called here]
dev_id exists for passing various data to the irq_handler... with some
drivers abusing the 'irq' argument to pass data, that potential opens
holes for bugs whenever the irq numbering (aka cookie) scheme is changed
-- because changing the cookie scheme could potentially trigger code like
if (irq == MAGIC_NUMBER)
this is an internal self-call, do some polling
else
handle real hardware-raised interrupt
When drivers make assumptions about system irq numbering, particularly
on x86, IMO the situation is fragile.
Jeff
next prev parent reply other threads:[~2008-04-24 2:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 22:17 [git patch] free_irq() fixes Jeff Garzik
2008-04-22 22:25 ` Linus Torvalds
2008-04-22 22:59 ` Jeff Garzik
2008-04-22 23:20 ` Linus Torvalds
2008-04-22 23:49 ` Jeff Garzik
2008-04-22 23:52 ` Linus Torvalds
2008-04-23 0:05 ` Adrian Bunk
2008-04-23 0:16 ` Linus Torvalds
2008-04-23 13:51 ` Rene Herman
2008-04-24 2:10 ` Jeff Garzik [this message]
2008-04-24 2:19 ` Linus Torvalds
2008-04-24 5:59 ` Eric W. Biederman
2008-04-24 10:53 ` Jeff Garzik
2008-04-24 15:16 ` Linus Torvalds
2008-04-24 15:40 ` Jeff Garzik
2008-04-24 15:55 ` Linus Torvalds
2008-04-24 15:37 ` Alan Cox
2008-04-24 16:20 ` Jeff Garzik
2008-04-24 16:16 ` Jeff Garzik
2008-04-24 16:48 ` Eric W. Biederman
2008-04-24 16:58 ` Linus Torvalds
2008-04-24 18:15 ` Eric W. Biederman
2008-04-24 17:30 ` Jeff Garzik
2008-04-25 2:53 ` Eric W. Biederman
2008-04-25 3:33 ` MSI, fun for the whole family (was Re: [git patch] free_irq() fixes) Jeff Garzik
2008-04-25 3:57 ` MSI, fun for the whole family Roland Dreier
2008-04-25 4:19 ` David Miller
2008-04-25 4:35 ` Jeff Garzik
2008-04-25 5:48 ` Eric W. Biederman
2008-04-25 22:44 ` Roland Dreier
2008-04-25 5:08 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=480FEC1B.6040102@garzik.org \
--to=jeff@garzik.org \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rene.herman@keyaccess.nl \
--cc=rmk@arm.linux.org.uk \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.