linux-kernel - Re: [PATCH] irq: Start the transition of irq

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 21 Mar 2010 17:32:41 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Julia Lawall <julia@...u.dk>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org
Subject: Re: [PATCH] irq: Start the transition of irq_chip methods taking a desc

Thomas Gleixner <tglx@...utronix.de> writes:

> Eric,
>
> On Sun, 21 Mar 2010, Eric W. Biederman wrote:
>> 
>> With SPARSE_IRQ irq_to_desc becomes an unnecessary lookup operation on
>> the fast path of dispatching irqs to their handlers.  We can avoid
>> this cost by passing an irq_desc pointer instead of using an integer
>> irq token to the irq_chip methods.
>> 
>> A single patch to convert all of the architectures is an unreviewable
>> 2000+ line patch.  A gradual transition scenario with two sets of
>> irq_chip methods in irq_chip is an unmanageable mess in kernel/irq.
>> 
>> So instead I define some macros so the generic irq code in kernel/irq/
>> can compile either way based on a boolean Kconfig variable
>> CONFIG_CHIP_PARAM_DESC.  This allows us to convert one architecture at
>> a time, reducing the follow on patches to manageable proportions.  It
>> is a little bit ugly but it is much better than the alternatives, and
>> as soon as we finish the transition we can kill the macros.
>> 
>> I introduce the macros CHIP_ARG, CHIP_VAR, and CHIP_PARAM where
>> appropriate.  I change a few declarations of irq as int to unsigned
>> int.  I normalize the variables names in the functions that call
>> chip methods to ensure that I have the variables irq and desc present
>> allowing CHIP_ARG to work properly.  Most importantly none of the irq
>> logic changes with this patch.
>
> I like that approach very much. Is the output binary equivivalent?

Depends on what you mean.
- If you are concerned about ABI changes, non exist.
- If the question is will the compiler generate the same instruction sequences,
  I don't expect it will.

  In particular the bug fixes to use unsigned int instead of int should affect
  the tests used in the for_each_irq_desc.  Of less avoid-ability is the change
  to ack_bad to use desc->irq instead of cached irq value.

  Since this is the only patch in the entire series that could
  possibly be binary equivalent I don't find it a particularly
  interesting test.

Eric

--
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/