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:	Thu, 11 Sep 2008 10:23:04 -0500
From:	Dean Nelson <dcn@....com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Alan Mayer <ajm@....com>, Ingo Molnar <mingo@...e.hu>,
	jeremy@...p.org, rusty@...tcorp.com.au, suresh.b.siddha@...el.com,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Yinghai Lu <Yinghai.lu@....com>
Subject: [RFC 0/4] dynamically allocate arch specific system vectors

On Mon, Aug 11, 2008 at 12:39:22PM -0700, Eric W. Biederman wrote:
>
> Although I am not at all convinced that dynamic allocation of
> the vector number (instead of statically reserving it makes sense).

We (SGI) need somewhere around eight vectors.

There are two kernel modules, sgi-gru and sgi-xp (in drivers/misc), that
each need two vectors. And there's the broadcast assist unit (BAU) that is
involved in tlb shootdown on uv, which currently uses statically reserved
vector 0xf8 (UV_BAU_MESSAGE -- see uv_bau_init()). I know of a debugger that
also uses 0xf8 because it was previously available until UV_BAU_MESSAGE came
along. The BAU would be happy with a dynamically allocated system vector.
We have a couple of other things in the works that also need vectors.

All of these eight or so vectors are only meaningful on SGI uv systems.

We'll go with which ever way you decide on this (dynamically allocated or
statically reserved).

But we really need to get something into 2.6.28. So in order to move forward
I'm submitting the following patchset for comment. This set of four patches
represents my take on Eric's suggested approach to supporting dynamically
allocated system vectors (i.e., __grab_irq_vector()).

Eric, is this what you were thinking of? Or did I miss the mark?

Thanks,
Dean
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ