Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

[Remy Bohmer]

Hello Steven,

 Do you recognise these warnings? I do not know (yet) if these are ARM
 specific...

  CC      kernel/rtmutex.o
 kernel/rtmutex.c: In function 'rt_write_fastlock':
 kernel/rtmutex.c:1582: warning: initialization makes pointer from
 integer without a cast
 kernel/rtmutex.c: In function 'rt_write_fasttrylock':
 kernel/rtmutex.c:1622: warning: initialization makes pointer from
 integer without a cast

 If so, do you have a fix for it?

 Regards,


 Remy

Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

[Steven Rostedt]

On Tue, 20 May 2008, Remy Bohmer wrote:

> Hello Steven,
>
>  Do you recognise these warnings? I do not know (yet) if these are ARM
>  specific...
>
>   CC      kernel/rtmutex.o
>  kernel/rtmutex.c: In function 'rt_write_fastlock':
>  kernel/rtmutex.c:1582: warning: initialization makes pointer from
>  integer without a cast
>  kernel/rtmutex.c: In function 'rt_write_fasttrylock':
>  kernel/rtmutex.c:1622: warning: initialization makes pointer from
>  integer without a cast
>
>  If so, do you have a fix for it?

Ah, I guess ARM is a bit more critical of chpxchg than x86 is.

I'll add a patch for 2.6.24.7-rt9 (which I plan on releasing soon). It
will have some minor clean ups.

-- Steve

Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

[Steven Rostedt]

On Tue, 20 May 2008, Remy Bohmer wrote:

> Hello Steven,
>
>  Do you recognise these warnings? I do not know (yet) if these are ARM
>  specific...
>
>   CC      kernel/rtmutex.o
>  kernel/rtmutex.c: In function 'rt_write_fastlock':
>  kernel/rtmutex.c:1582: warning: initialization makes pointer from
>  integer without a cast
>  kernel/rtmutex.c: In function 'rt_write_fasttrylock':
>  kernel/rtmutex.c:1622: warning: initialization makes pointer from
>  integer without a cast
>
>  If so, do you have a fix for it?

Remy,

Can you see if this helps,

Signed-off-by: Steven Rostedt <srostedt@redhat.com>

---
 kernel/rtmutex.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux-2.6.24.7-rt9/kernel/rtmutex.c
===================================================================
--- linux-2.6.24.7-rt9.orig/kernel/rtmutex.c	2008-05-20 17:11:29.000000000 -0400
+++ linux-2.6.24.7-rt9/kernel/rtmutex.c	2008-05-20 17:13:18.000000000 -0400
@@ -1577,7 +1577,7 @@ rt_write_fastlock(struct rw_mutex *rwm,
 		  void fastcall (*slowfn)(struct rw_mutex *rwm, int mtx),
 		  int mtx)
 {
-	unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;
+	struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);

 	if (likely(rt_rwlock_cmpxchg(rwm, NULL, val)))
 		rt_mutex_deadlock_account_lock(&rwm->mutex, current);
@@ -1617,7 +1617,7 @@ static inline int
 rt_write_fasttrylock(struct rw_mutex *rwm,
 		     int fastcall (*slowfn)(struct rw_mutex *rwm, int mtx), int mtx)
 {
-	unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;
+	struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);

 	if (likely(rt_rwlock_cmpxchg(rwm, NULL, val))) {
 		rt_mutex_deadlock_account_lock(&rwm->mutex, current);
@@ -1902,7 +1902,7 @@ rt_write_fastunlock(struct rw_mutex *rwm
 					    int mtx),
 		    int mtx)
 {
-	unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;
+	struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);

 	WARN_ON(rt_rwlock_owner(rwm) != current);
 	if (likely(rt_rwlock_cmpxchg(rwm, (struct task_struct *)val, NULL)))

Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

[Remy Bohmer]

Hello Steven,

> Remy,
> Can you see if this helps,

Yes, this helps. Looks a little weird to add bitmasks to pointers, but
I understand why it has been done here.
BTW: I notice that you already has put it in -rt9.

And some other positive news: 2.6.24.7-rt9 compiles and boots
perfectly on ARM at91sam9261. (There are still a few other warnings,
but these are not RT related)

Now I understood your hint in some other mail, and I am going to take
a look at ftrace for ARM. Just for the fun of it...
I hope it is not too intrusive for these ARM cores (old implementation
was...), these Atmel cores are just not that fast as the common X86's.


Kind Regards,

Remy


2008/5/20 Steven Rostedt <rostedt@goodmis.org>:
>
>
> On Tue, 20 May 2008, Remy Bohmer wrote:
>
>> Hello Steven,
>>
>>  Do you recognise these warnings? I do not know (yet) if these are ARM
>>  specific...
>>
>>   CC      kernel/rtmutex.o
>>  kernel/rtmutex.c: In function 'rt_write_fastlock':
>>  kernel/rtmutex.c:1582: warning: initialization makes pointer from
>>  integer without a cast
>>  kernel/rtmutex.c: In function 'rt_write_fasttrylock':
>>  kernel/rtmutex.c:1622: warning: initialization makes pointer from
>>  integer without a cast
>>
>>  If so, do you have a fix for it?
>
> Remy,
>
> Can you see if this helps,
>
> Signed-off-by: Steven Rostedt <srostedt@redhat.com>
>
> ---
>  kernel/rtmutex.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> Index: linux-2.6.24.7-rt9/kernel/rtmutex.c
> ===================================================================
> --- linux-2.6.24.7-rt9.orig/kernel/rtmutex.c    2008-05-20 17:11:29.000000000 -0400
> +++ linux-2.6.24.7-rt9/kernel/rtmutex.c 2008-05-20 17:13:18.000000000 -0400
> @@ -1577,7 +1577,7 @@ rt_write_fastlock(struct rw_mutex *rwm,
>                  void fastcall (*slowfn)(struct rw_mutex *rwm, int mtx),
>                  int mtx)
>  {
> -       unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;
> +       struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);
>
>        if (likely(rt_rwlock_cmpxchg(rwm, NULL, val)))
>                rt_mutex_deadlock_account_lock(&rwm->mutex, current);
> @@ -1617,7 +1617,7 @@ static inline int
>  rt_write_fasttrylock(struct rw_mutex *rwm,
>                     int fastcall (*slowfn)(struct rw_mutex *rwm, int mtx), int mtx)
>  {
> -       unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;
> +       struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);
>
>        if (likely(rt_rwlock_cmpxchg(rwm, NULL, val))) {
>                rt_mutex_deadlock_account_lock(&rwm->mutex, current);
> @@ -1902,7 +1902,7 @@ rt_write_fastunlock(struct rw_mutex *rwm
>                                            int mtx),
>                    int mtx)
>  {
> -       unsigned long val = (unsigned long)current | RT_RWLOCK_WRITER;
> +       struct task_struct *val = (void *)((unsigned long)current | RT_RWLOCK_WRITER);
>
>        WARN_ON(rt_rwlock_owner(rwm) != current);
>        if (likely(rt_rwlock_cmpxchg(rwm, (struct task_struct *)val, NULL)))
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Compile warning rtmutex code on 2.6.24.7-rt8 (CC:LKML added)

[Steven Rostedt]

On Wed, 21 May 2008, Remy Bohmer wrote:

> Now I understood your hint in some other mail, and I am going to take
> a look at ftrace for ARM. Just for the fun of it...
> I hope it is not too intrusive for these ARM cores (old implementation
> was...), these Atmel cores are just not that fast as the common X86's.

If you feel brave, take a crack at the DYNAMIC_FTRACE. It's been done for
x86 (both 32 and 64 bit), PPC (also both 32 and 64 bit) as well as
Sparc64.

The dynamic ftrace is self modifying code, that will start off having
mcount simply call a nop. Then later it will change that to call a
"record_ip" function. A daemon is kicked off to change all the IPs that
are called into NOPs. When tracing is enabled, all the NOPs are converted
into calls to the trace function.

Dynamic ftrace also adds a "set_filter_function" in the /debugfs/tracing
directory that lets you echo in function names, and only those functions
will enable have tracing enabled.

All this helps tremendously in tracing performance and normal bootup. One
thing that you need to understand though. That daemon needs to call
kstop_machine to do the modifications. The daemon wakes up once a second,
checks to see if there is any new functions that have been recorded. If
not, then it simply goes back to sleep. But if there are new functions,
then it calls kstopmachine. This daemon stops when tracing is enabled, but
can cause unsuspecting latencies when tracing is disabled.

I'll probably add a something to disable the daemon just before firing off
init if PREEMPT_RT is enabled.

Any questions on porting ftrace, feel free to ask.

Cheers,

-- Steve