Warning fixes for PREEMPT_RT

These patches fix various warnings I got when building 3.2.71-rt104; some of them are applicable to other RT branches as well.

Ben.

Ben Hutchings (4):
KVM: lapic: Fix name of timer handler before 3.7
rtmutex: Fix rt_mutex_timed_fastlock() slowfn type mismatch up to 3.10
genirq: Fix pointer cast warning for randomness on 32-bit
architectures
work-simple: Add missing #include <linux/export.h>

 arch/x86/kvm/lapic.c | 4 +---
 kernel/irq/manage.c  | 3 ++-
 kernel/rtmutex.c     | 2 +-
 kernel/work-simple.c | 1 +
 4 files changed, 5 insertions(+), 5 deletions(-)

Ben Hutchings
All the simple programs have been written, and all the good names taken.

The timer handler was named kvm_timer_fn, not apic_timer_fn, before Linux 3.7.

---
 arch/x86/kvm/lapic.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

index 7198be0..c661909 100644
@@ -680,15 +680,13 @@ static void update_divide_count(struct kvm_lapic *apic)
 }
 
 
-static enum hrtimer_restart apic_timer_fn(struct hrtimer *data);
-
 static void apic_timer_expired(struct hrtimer *data)
 {
 	int ret, i = 0;
 	enum hrtimer_restart r;
 	struct kvm_timer *ktimer = container_of(data, struct kvm_timer, timer);
 
-	r = apic_timer_fn(data);
+	r = kvm_timer_fn(data);
 
 	if (r == HRTIMER_RESTART) {
 		do {

Ben Hutchings
All the simple programs have been written, and all the good names taken.

The type of the slowfn parameter is declared incorrectly in some of the backports, resulting in:

kernel/rtmutex.c: In function 'rt_mutex_timed_futex_lock':
kernel/rtmutex.c:1730:12: warning: passing argument 5 of 'rt_mutex_timed_fastlock' from incompatible pointer type [enabled by default]
kernel/rtmutex.c:1655:1: note: expected 'int (*)(struct rt_mutex *, int, struct hrtimer_sleeper *, int)' but argument is of type 'int (*)(struct rt_mutex *, int, struct hrtimer_sleeper *, enum rtmutex_chainwalk)' kernel/rtmutex.c: In function 'rt_mutex_timed_lock':
kernel/rtmutex.c:1770:12: warning: passing argument 5 of 'rt_mutex_timed_fastlock' from incompatible pointer type [enabled by default]
kernel/rtmutex.c:1655:1: note: expected 'int (*)(struct rt_mutex *, int, struct hrtimer_sleeper *, int)' but argument is of type 'int (*)(struct rt_mutex *, int, struct hrtimer_sleeper *, enum rtmutex_chainwalk)'

---
 kernel/rtmutex.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 52cab27..26550b6 100644
@@ -1657,7 +1657,7 @@ rt_mutex_timed_fastlock(struct rt_mutex *lock, int state,
 			enum rtmutex_chainwalk chwalk,
 			int (*slowfn)(struct rt_mutex *lock, int state,
 				      struct hrtimer_sleeper *timeout,
-				      int detect_deadlock))
+				      enum rtmutex_chainwalk chwalk))
 {
 	if (chwalk == RT_MUTEX_MIN_CHAINWALK &&
 	    likely(rt_mutex_cmpxchg(lock, NULL, current))) {

Ben Hutchings
All the simple programs have been written, and all the good names taken.

gcc warns about casting directly from a 32-bit pointer to u64. In the current rt patch series we cast to unsigned long to avoid the warning, but this fix hasn't been backported to all versions.

---
 kernel/irq/manage.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

index e4549b2..964cf41 100644
@@ -897,7 +897,8 @@ static int irq_thread(void *data)
 #ifdef CONFIG_PREEMPT_RT_FULL
 			migrate_disable();
 			add_interrupt_randomness(action->irq, 0,
-						 desc->random_ip ^ (u64) action);
+						 desc->random_ip ^
+						 (unsigned long) action);
 			migrate_enable();
 #endif
 		}

Ben Hutchings
All the simple programs have been written, and all the good names taken.

work-simple.c uses EXPORT_SYMBOL_GPL(), defined in <linux/export.h>.

---
 kernel/work-simple.c | 1 +
 1 file changed, 1 insertion(+)

index c996f75..e57a052 100644
@@ -10,6 +10,7 @@
 #include <linux/kthread.h>
 #include <linux/slab.h>
 #include <linux/spinlock.h>
+#include <linux/export.h>
 
 #define SWORK_EVENT_PENDING     (1 << 0)
 

Ben Hutchings
All the simple programs have been written, and all the good names taken.

Ping.

Ben.

Ben Hutchings
friends: People who know you well, but like you anyway.

Sorry, I've been behind in reading this list. I'll take a look at this.

Thanks,

-- Steve