linux-kernel - Re: [PATCH 06/12] genericirq: make 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]

Message-ID: <m1iq8p23af.fsf@fess.ebiederm.org>
Date:	Sun, 21 Mar 2010 06:49:12 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Julia Lawall <julia@...u.dk>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/12] genericirq: make irq_chip related function to take desc

Julia Lawall <julia@...u.dk> writes:

> I also worked on this, but only sent it to Thomas and Yinghai.  Onthe 
> other hand, I mostly like your solution better, because it has the 
> unintended side-effect of getting rid of some blank spaces after {s.

Wow I hadn't noticed that {s removal. That is an old coding style
violation on alpha.  There was an intentional effect of not breaking
up { }'s.  But I hadn't realized I was also fixing whitespace.

> My rule was also more complicated in that it also searches for conditions 
> in which it is not sure to be doing the right thing.  I will send those in 
> another message.
>
>> @ DECL @
>> struct irq_chip CHIP;
>> identifier METHOD;
>> identifier METHOD_NAME;
>> @@
>>  CHIP.METHOD_NAME = METHOD;
>> 
>> @ @
>> identifier DECL.METHOD;
>> identifier IRQ;
>> @@
>>  METHOD(
>> -		unsigned int IRQ
>> +		struct irq_desc *unused
>>  , ...) {
>>  }
>
> I didn't think of making a special rule for this.  It could consider any 
> case where the body is ... when != IRQ

Nice addition.

>> @ @
>> identifier DECL.METHOD;
>> identifier IRQ;
>> identifier DESC;
>> @@
>>  METHOD(
>> -		unsigned int IRQ
>> +		struct irq_desc *DESC
>>  , ...) {
>> +	unsigned int IRQ = DESC->irq;
>>  	...
>> -	struct irq_desc *DESC = irq_to_desc(IRQ);
>> 	...
>>  }
>> 
>> @ @
>> identifier DECL.METHOD;
>> identifier IRQ;
>> identifier DESC;
>> @@
>>  METHOD(
>> -		unsigned int IRQ
>> +		struct irq_desc *DESC
>>  , ...) {
>> +	unsigned int IRQ = DESC->irq;
>>  	...
>> -	struct irq_desc *DESC;
>> 	...
>> -	DESC = irq_to_desc(IRQ);
>> 	...
>>  }
>> 
>> @ @
>> identifier DECL.METHOD;
>> identifier IRQ;
>> @@
>>  METHOD(
>> -		unsigned int IRQ
>> +		struct irq_desc *desc
>>  , ...) {
>> +	unsigned int IRQ = desc->irq;
>>  ...
>>  }
>> 
>> @ @
>> identifier DECL.METHOD;
>> identifier FUNC;
>> identifier IRQ;
>> @@
>>  FUNC(...) {
>>  <...
>> 	METHOD(
>> -		IRQ
>> +		irq_to_desc(IRQ)
>>  		, ... )
>>  ...>
>>  }
>
> I don't think FUNC(...) { <... and ...> } are needed here.  The goal is to 
> make the change everywhere the call appears.

That is a reasonable simplification.

>> @ @
>> identifier FUNC;
>> identifier DESC;
>> identifier IRQ;
>> @@
>>  FUNC(..., struct irq_desc *DESC, ...) {
>>  ...
>>  	unsigned int IRQ = DESC->irq;
>>  <...
>> -	irq_to_desc(IRQ)
>> +	DESC
>>  ...>
>>  }
>
> This rule can be extended as follows:

Nice.  I had not picked up on the or operator.

> @ @
> identifier FUNC;
> identifier DESC;
> identifier IRQ;
> identifier FLD;
> @@
>  FUNC(..., struct irq_desc *DESC, ...) {
>  ...
>         unsigned int IRQ = DESC->irq;
>  <...
> (
> -       irq_to_desc(IRQ)
> +       DESC
> |
> -       irq_desc[IRQ].FLD
> +       DESC->FLD
> )
>  ...>
>  }
>
> Doing so gets rid of more references to IRQ.

Very reasonable, especially on arches like alpha where none of the
sparse irq work has hit.


> Another case that can be treated is method calls via a pointer:

I didn't actually find any cases where that rule hit on arch/x86
so I did not include it, but it makes sense.

> @@
> expression arg;
> struct irq_desc *desc;
> struct irq_chip *ic;
> identifier fun;
> @@
>
> (
>   desc->chip->fun(
> -   arg
> +   desc
>     ,...)
> |
>   ic->fun(
> -   arg
> +   irq_to_desc(arg)
>     ,...)
> )


My paranoid sense says this rule should be:
@ @
expresion IRQ_EXPR;
struct irq_desc *DESC;
struct irq_chip *CHIP;
identifier METHOD;
@@
(
 	DESC->chip->METHOD(
-			   IRQ_EXPR
+			   irq_to_desc(IRQ_EXPR)
			   , ... )
|
	CHIP->METHOD(
-		     IRQ_EXPR
+		     irq_to_desc(IRQ_EXPR)
		     , ... )

If this is before my irq_to_desc removal rule.  We should not
see any new irq_to_desc calls popping up.

> julia
>
>> @ @
>> identifier FUNC;
>> identifier DESC;
>> identifier IRQ;
>> @@
>>  FUNC(..., struct irq_desc *DESC, ...) {
>>  ...
>> -	unsigned int IRQ = DESC->irq;
>>  ... when != IRQ
>>  }
--
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/