linux-kernel - Re: [patch 19/26] x64, x2apic/intr-remap: introcude self IPI to genapic routines

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:	Fri, 11 Jul 2008 06:55:24 -0700
From:	Mike Travis <travis@....com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Suresh Siddha <suresh.b.siddha@...el.com>, mingo@...e.hu,
	hpa@...or.com, tglx@...utronix.de, akpm@...ux-foundation.org,
	arjan@...ux.intel.com, andi@...stfloor.org,
	jbarnes@...tuousgeek.org, steiner@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 19/26] x64, x2apic/intr-remap: introcude self IPI to genapic
 routines

Eric W. Biederman wrote:
> Mike Travis <travis@....com> writes:
>> On a similar subject I would really like to change the send_IPI_mask to pass a
>> pointer to the cpumask_t arg:
>>
>>         void (*send_IPI_mask)(cpumask_t mask, int vector);
>>
>>
>> This bloats the stack by 512 bytes and seemingly is called by some fairly
>> nested routines.  Any opinions?
> 
> It sounds like a pain.  Especially since we would need to dereference
> cpumask_t when we use it.  Does any remember if there was a plan for
> dealing with cpumask_t when the number of cpus got large?
> 
> If we pass in a pointer to constant data semantically we should be fine.
> 
> Mostly I am wondering if three isn't a cleaner solution hidden away somewhere.
> 
> Eric

This is similar to the set_cpus_allowed_ptr which is the alternative for
passing the cpumask as a pointer.  When I did this way back when, the general
consensus was that the extra dereference was just a bit of noise in low use
functions.  

This case is different in that there is an API (via genapic).  I could always
add a new entry for send_IPI_mask_ptr, or I could change the existing interface
to be like the current cpumask operators, passing a pointer to the cpumask args
"silently".  This has an advantage in that we could "not" pass the pointer if
say, NR_CPUS <= sizeof(LONG).  But I'd have to change references of the form
(genapic->send_IPI_mask).

And there are cases where the cpumask arg is cpumask_of_cpu() meaning there's
only one bit of interest which really wastes stack space.  And with the (real
soon now) next iteration to 16k cpus, pushing 2k on the stack, we will feel
the pain... ;-)

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