linux-kernel - Re: The mysterious case of struct irqaction's mask field.

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

Message-ID: <20090210122332.GA28817@elte.hu>
Date:	Tue, 10 Feb 2009 13:23:32 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	William Lee Irwin III <wli@...omorphy.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: The mysterious case of struct irqaction's mask field.


* Rusty Russell <rusty@...tcorp.com.au> wrote:

> Hi all,
> 
>    As part of the cpumask conversion, I came across struct irqaction:
> 
> 	struct irqaction {
> 		irq_handler_t handler;
> 		unsigned long flags;
> 		cpumask_t mask;
> 		...
> 	};
> 
> Most people have been setting 'mask' to CPU_MASK_NONE, and I wondered if that
> really meant that they never want this action performed on any CPU.
> 
> But I couldn't find anyone who actually *reads* the 'mask' field.  Tracing
> back, it was converted from an unsigned long to a cpumask_t by wli around
> 2.6.7 ("as it was intended to be").  But that conversion didn't reveal anyone
> actually using the field either.
> 
> At one point, sparc64 seems to have overloaded it for some kind of irq bucket
> scheme.
> 
> Finally, I tracked it back to the creation of (then per-arch) struct irqaction
> in 1.1.82, and this hunk from linux/arch/i386/kernel/irq.c:
> 
> @@ -12,14 +12,7 @@
> 
>  /*
>   * IRQ's are in fact implemented a bit like signal handlers for the kernel.
> - * The same sigaction struct is used, and with similar semantics (ie there
> - * is a SA_INTERRUPT flag etc). Naturally it's not a 1:1 relation, but there
> - * are similarities.
> - *
> - * sa_handler(int irq_NR) is the default function called (0 if no).
> - * sa_mask is horribly ugly (I won't even mention it)
> - * sa_flags contains various info: SA_INTERRUPT etc
> - * sa_restorer is the unused
> + * Naturally it's not a 1:1 relation, but there are similarities.
>   */
> 
>  #include <linux/ptrace.h>
> 
> So, it was never a cpumask at all; just a remanent of the use of sigaction for
> interrupt handlers.  We've been happily setting it throughout the kernel since
> 1995.

Hehe, nice one :-)

> On the assumption that it has failed to coerce the spirits of our ancestors to
> land among us, I'll create a patch to remove it.

Please do.

This seems to be a classic symptom of write-mostly kernel source code :-/

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