Hello,
On Tue, Aug 26, 2014 at 07:12:21PM -0500, Christoph Lameter wrote:
>
> New patch:
>
> From: Christoph Lameter
> Subject: __get_cpu_var/cpumask_var_t: Resolve ambiguities v2
>
> __get_cpu_var can paper over differences in the definitions
> of cpumask_var_t and either use the address of
Hello,
On Tue, Aug 26, 2014 at 07:12:21PM -0500, Christoph Lameter wrote:
New patch:
From: Christoph Lameter c...@linux.com
Subject: __get_cpu_var/cpumask_var_t: Resolve ambiguities v2
__get_cpu_var can paper over differences in the definitions
of cpumask_var_t and either use the
New patch:
From: Christoph Lameter
Subject: __get_cpu_var/cpumask_var_t: Resolve ambiguities v2
__get_cpu_var can paper over differences in the definitions
of cpumask_var_t and either use the address of the cpumask
variable directly or perform a fetch of the address of the
struct cpumask
On Tue, 26 Aug 2014, Tejun Heo wrote:
> Ugh include hell. :( Does putting the accessors in percpu.h make
> any difference? Given the tricky nature of cpumask_var_t, I think
> type checking can be pretty useful.
Then its going to be difficult to find. This is related to the
cpumark_var_t
Hello,
On Tue, Aug 26, 2014 at 04:33:28PM -0500, Christoph Lameter wrote:
> Ok I tried to change it to an inline function. The problem is the
> cpumask.h is included very early. this_cpu ops require functionality
> that is not available at that point. I think it cannot be more than a
> macro
On Sat, 23 Aug 2014, Christoph Lameter wrote:
> On Sat, 23 Aug 2014, Tejun Heo wrote:
>
> > Hello, Christoph.
> >
> > On Fri, Aug 22, 2014 at 12:43:25PM -0500, Christoph Lameter wrote:
> > > It wont accept the wrong type since the this_cpu_* functions will do type
> > > checking.
> >
> > It
On Sat, 23 Aug 2014, Christoph Lameter wrote:
On Sat, 23 Aug 2014, Tejun Heo wrote:
Hello, Christoph.
On Fri, Aug 22, 2014 at 12:43:25PM -0500, Christoph Lameter wrote:
It wont accept the wrong type since the this_cpu_* functions will do type
checking.
It should only accept
Hello,
On Tue, Aug 26, 2014 at 04:33:28PM -0500, Christoph Lameter wrote:
Ok I tried to change it to an inline function. The problem is the
cpumask.h is included very early. this_cpu ops require functionality
that is not available at that point. I think it cannot be more than a
macro unless
On Tue, 26 Aug 2014, Tejun Heo wrote:
Ugh include hell. :( Does putting the accessors in percpu.h make
any difference? Given the tricky nature of cpumask_var_t, I think
type checking can be pretty useful.
Then its going to be difficult to find. This is related to the
cpumark_var_t
New patch:
From: Christoph Lameter c...@linux.com
Subject: __get_cpu_var/cpumask_var_t: Resolve ambiguities v2
__get_cpu_var can paper over differences in the definitions
of cpumask_var_t and either use the address of the cpumask
variable directly or perform a fetch of the address of the
struct
On Sat, 23 Aug 2014, Tejun Heo wrote:
> Hello, Christoph.
>
> On Fri, Aug 22, 2014 at 12:43:25PM -0500, Christoph Lameter wrote:
> > It wont accept the wrong type since the this_cpu_* functions will do type
> > checking.
>
> It should only accept cpumask_var_t but the macro version accepts
>
Hello, Christoph.
On Fri, Aug 22, 2014 at 12:43:25PM -0500, Christoph Lameter wrote:
> It wont accept the wrong type since the this_cpu_* functions will do type
> checking.
It should only accept cpumask_var_t but the macro version accepts
anything that this_cpu_*() can handle.
> > > _t is there
Hello, Christoph.
On Fri, Aug 22, 2014 at 12:43:25PM -0500, Christoph Lameter wrote:
It wont accept the wrong type since the this_cpu_* functions will do type
checking.
It should only accept cpumask_var_t but the macro version accepts
anything that this_cpu_*() can handle.
_t is there
On Sat, 23 Aug 2014, Tejun Heo wrote:
Hello, Christoph.
On Fri, Aug 22, 2014 at 12:43:25PM -0500, Christoph Lameter wrote:
It wont accept the wrong type since the this_cpu_* functions will do type
checking.
It should only accept cpumask_var_t but the macro version accepts
anything that
On Fri, 22 Aug 2014, Tejun Heo wrote:
> On Thu, Aug 21, 2014 at 08:03:25PM -0500, Christoph Lameter wrote:
> > Its a pretty simple function (actually more a name substituion) so I
> > did not think it worth creating an inline function.
>
> Unless there are specific reasons like multi-type arg or
Hello, Christoph.
On Thu, Aug 21, 2014 at 08:03:25PM -0500, Christoph Lameter wrote:
> Its a pretty simple function (actually more a name substituion) so I
> did not think it worth creating an inline function.
Unless there are specific reasons like multi-type arg or breaking
hellish definition
Hello, Christoph.
On Thu, Aug 21, 2014 at 08:03:25PM -0500, Christoph Lameter wrote:
Its a pretty simple function (actually more a name substituion) so I
did not think it worth creating an inline function.
Unless there are specific reasons like multi-type arg or breaking
hellish definition
On Fri, 22 Aug 2014, Tejun Heo wrote:
On Thu, Aug 21, 2014 at 08:03:25PM -0500, Christoph Lameter wrote:
Its a pretty simple function (actually more a name substituion) so I
did not think it worth creating an inline function.
Unless there are specific reasons like multi-type arg or
On Thu, 21 Aug 2014, Tejun Heo wrote:
> >
> > +#define this_cpu_cpumask_var_t_ptr(x) this_cpu_ptr()
>
> Urgh, this is nasty but yeah I can't think of any other way around it
> either. :(
>
> Do we need the "_t" in the name tho? Maybe we can shorten the name to
> this_cpumask_var_ptr(x)? Also,
Hello, Christoph.
On Thu, Aug 07, 2014 at 10:05:45AM -0500, Christoph Lameter wrote:
> @@ -666,10 +666,19 @@
> *
> * This code makes NR_CPUS length memcopy and brings to a memory corruption.
> * cpumask_copy() provide safe copy functionality.
> + *
> + * Note that there is another evil
Hello, Christoph.
On Thu, Aug 07, 2014 at 10:05:45AM -0500, Christoph Lameter wrote:
@@ -666,10 +666,19 @@
*
* This code makes NR_CPUS length memcopy and brings to a memory corruption.
* cpumask_copy() provide safe copy functionality.
+ *
+ * Note that there is another evil here: If
On Thu, 21 Aug 2014, Tejun Heo wrote:
+#define this_cpu_cpumask_var_t_ptr(x) this_cpu_ptr(x)
Urgh, this is nasty but yeah I can't think of any other way around it
either. :(
Do we need the _t in the name tho? Maybe we can shorten the name to
this_cpumask_var_ptr(x)? Also, wouldn't it
Needs a small fixup
From: Christoph Lameter
Subject: One & too much
Remove it.
Signed-off-by: Christoph Lameter
Index: linux/include/linux/cpumask.h
===
--- linux.orig/include/linux/cpumask.h
+++ linux/include/linux/cpumask.h
@@
Needs a small fixup
From: Christoph Lameter c...@linux.com
Subject: One too much
Remove it.
Signed-off-by: Christoph Lameter c...@linux.com
Index: linux/include/linux/cpumask.h
===
--- linux.orig/include/linux/cpumask.h
+++
I think I finally found the source of the nasty failures of the
__get_cpu_var patchset:
Subject: __get_cpu_var/cpumask_var_t: Resolve ambiguities
__get_cpu_var can paper over differences in the definitions
of cpumask_var_t and either use the address of the cpumask
variable directly or perform
I think I finally found the source of the nasty failures of the
__get_cpu_var patchset:
Subject: __get_cpu_var/cpumask_var_t: Resolve ambiguities
__get_cpu_var can paper over differences in the definitions
of cpumask_var_t and either use the address of the cpumask
variable directly or perform
26 matches
Mail list logo
