All of lore.kernel.org
 help / color / mirror / Atom feed
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




  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.