linux-kernel - Re: [PATCH] x86_64: Dynamically allocate arch specific system vectors

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: <m18wvgv4bj.fsf@frodo.ebiederm.org>
Date:	Fri, 01 Aug 2008 14:00:16 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Cliff Wickman <cpw@....com>
Cc:	Alan Mayer <ajm@....com>, jeremy@...p.org, rusty@...tcorp.com.au,
	suresh.b.siddha@...el.com, mingo@...e.hu,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Dean Nelson <dcn@....com>
Subject: Re: [PATCH] x86_64:  Dynamically allocate arch specific system vectors

Cliff Wickman <cpw@....com> writes:
>
> I assume you mean create_irq() and destroy_irq().
> They are close to what we need.

Actually that isn't quite what I was thinking.

> However for any given system use:
> - we need to request a high priority vector for some irq's, rather than
>   one randomly allocated as per __assign_irq_vector().

Well I was actually thinking mostly about reusing assign_irq_vector.

The high priority vector seems to be the place where we would need
to reexamine the vector allocator.

> - we want the irq/vector to be targeted to all cpu's (as specified in a
>   mask,
>   and can include currently offline cpu's) rather than a single cpu. 

__assign_irq_vector should be able to handle that case.

> I suppose those abilities could be added to create_irq(), but we didn't
> want to intrude into that interface.

Right.  That part gets custom and there is no intersection.

> A smaller consideration is simplicity of use.  We want any such user to
> use
> the generic do_IRQ() flow (not alloc_intr_gate()).

My primary concern is that you are generalizing an interface that is
designed for alloc_intr_gate consumers.  In particular for people
who wish to allocate vectors that can be triggered by software to
do this.

If this is normal irq handling I would really prefer to use the
normal data structures that we use for allocating vectors to irqs,
because that is what you are doing.

> But make it easy to set
> up the irq/vector, irq_chip and irq_desc without getting intimate with
> the details.
> I suppose some other wrapper for an enhanced create_irq() could be done.
>
> We are going to need such irq/vector pairs for a couple of UV drivers
> (drivers/misc/sgi-gru/ and sgi-xp/).  And would prefer it for the UV TLB
> shootdown (x86/kernel/tlb.uv.c) rather than using alloc_intr_gate().

I also want to ask why do you need an irq that fires on every cpu?

That concept seems to be responsible for one of the nastiest data
structures in the kernel.  Where we track how many times any irq has
occurred on any cpu.  Look at the percpu variable kernel_stat.  It
seems to be one of the nastiest variables I know of.  Of size:
NR_CPUS*NR_CPUS*32  Assuming you have a machine with a reasonable
number of irqs per cpu.

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/