[PATCH 1/2] compat: remove backport of irq_modify_status

[PATCH 1/2] compat: remove backport of irq_modify_status

[Hauke Mehrtens]

Only kernel >= 2.6.39 irq_to_desc or irq_desc are exporting, so that
compat is not able to access this on the kernel versions where it is
needed. irq_to_desc and irq_desc are defined in the header files so
compilation works, but the module is not loadable because of the
missing exported symbol which make compat unusable on all these kernel
versions. Remove this function, no driver seams to need it.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
 compat/compat-2.6.37.c        |   26 --------------------------
 include/linux/compat-2.6.37.h |   21 ---------------------
 2 files changed, 47 deletions(-)

diff --git a/compat/compat-2.6.37.c b/compat/compat-2.6.37.c
index d2ee109..24b267a 100644
--- a/compat/compat-2.6.37.c
+++ b/compat/compat-2.6.37.c
@@ -13,32 +13,6 @@
 #include <net/sock.h>
 #include <linux/nsproxy.h>
 #include <linux/vmalloc.h>
-#include <linux/irq.h>
-#include <linux/irqnr.h>
-#include <linux/spinlock.h>
-
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,27)
-#define irq_to_desc(irq) (irq_desc + irq)
-#endif
-
-void irq_modify_status(unsigned int irq, unsigned long clr, unsigned long set)
-{
-	struct irq_desc *desc = irq_to_desc(irq);
-	unsigned long flags;
-
-	if (!desc)
-		return;
-
-	/* Sanitize flags */
-	set &= IRQF_MODIFY_MASK;
-	clr &= IRQF_MODIFY_MASK;
-
-	spin_lock_irqsave(&desc->lock, flags);
-	desc->status &= ~clr;
-	desc->status |= set;
-	spin_unlock_irqrestore(&desc->lock, flags);
-}
-EXPORT_SYMBOL_GPL(irq_modify_status);
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,35)
 static const void *net_current_ns(void)
diff --git a/include/linux/compat-2.6.37.h b/include/linux/compat-2.6.37.h
index b87aa2f..7e14853 100644
--- a/include/linux/compat-2.6.37.h
+++ b/include/linux/compat-2.6.37.h
@@ -9,27 +9,6 @@
 #include <linux/leds.h>
 #include <linux/in.h>
 #include <linux/errno.h>
-#include <linux/irq.h>
-
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28))
-#define IRQ_MOVE_PCNTXT         0x01000000      /* IRQ migration from process context */
-#endif
-
-#define IRQF_MODIFY_MASK       \
-	(IRQ_TYPE_SENSE_MASK | IRQ_NOPROBE | IRQ_NOREQUEST | \
-	IRQ_NOAUTOEN | IRQ_MOVE_PCNTXT | IRQ_LEVEL)
-
-void irq_modify_status(unsigned int irq, unsigned long clr, unsigned long set);
-
-static inline void irq_set_status_flags(unsigned int irq, unsigned long set)
-{
-	irq_modify_status(irq, 0, set);
-}
-
-static inline void irq_clear_status_flags(unsigned int irq, unsigned long clr)
-{
-	irq_modify_status(irq, clr, 0);
-}
 
 static inline int proto_ports_offset(int proto)
 {
-- 
1.7.9.5

[PATCH 2/2] compat: fix endless recursion in flush_scheduled_work

[Hauke Mehrtens]

The hader file defines flush_scheduled_work(a)
compat_flush_scheduled_work(a), which causes flush_scheduled_work() and
compat_flush_scheduled_work() to be the same function.

With this patch it calls the actual function in the kernel.

This fixes problems when unloading mac80211 from compat-wireless.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
 compat/compat-2.6.36.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/compat/compat-2.6.36.c b/compat/compat-2.6.36.c
index 8f25be0..05b41c2 100644
--- a/compat/compat-2.6.36.c
+++ b/compat/compat-2.6.36.c
@@ -133,6 +133,7 @@ int compat_schedule_delayed_work_on(int cpu,
 }
 EXPORT_SYMBOL_GPL(compat_schedule_delayed_work_on);
 
+#undef flush_scheduled_work(a)
 void compat_flush_scheduled_work(void)
 {
 	/*
-- 
1.7.9.5

Re: [PATCH 1/2] compat: remove backport of irq_modify_status

[Luis R. Rodriguez]

On Thu, Aug 2, 2012 at 9:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> Only kernel >= 2.6.39 irq_to_desc or irq_desc are exporting, so that
> compat is not able to access this on the kernel versions where it is
> needed. irq_to_desc and irq_desc are defined in the header files so
> compilation works, but the module is not loadable because of the
> missing exported symbol which make compat unusable on all these kernel
> versions. Remove this function, no driver seams to need it.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

Thanks, if you look at my patch 3e3c23e042 on compat.git it says that
I added this stuff due to the patch that is now merged on linux.git
ee9c8a04 -- wl1251: fix oops on early interrupt. That patch was a
stable fix merged down to v3.4.6. The implications of your tests are
that wl1251 must be disabled on older kernel or another equivalent
stable fix must be backported for that driver into
compat-wireless.git.

I frankly have too much patch catching up to so I cannot take care of
this right now so what I will do is disable wl1251 on the updated
stable releases for kernels older than v2.6.38 which require all this
backport work. I welcome patches to properly backpor this though.

I should point out too that this patch was a linux-next.git patch that
got marked as stable and once merged onto v3.4.6 it required a *new*
backport change that was not required on a release based on v3.4.5.
This means that *any* stable fix on older kernels could potentially
regress stable compat releases. The only way to not regress stable
compat releases then is if there is no delta from the pulled upstream
code as there is no gaurantee a stable fix did not implement usage of
a feature implemented or available only on certain newer kernels.

Luca, for what kernels do you guys really need wl1251 enabled for?

  Luis

Re: [PATCH 1/2] compat: remove backport of irq_modify_status

[Hauke Mehrtens]

On 08/06/2012 08:33 PM, Luis R. Rodriguez wrote:
> On Thu, Aug 2, 2012 at 9:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>> Only kernel >= 2.6.39 irq_to_desc or irq_desc are exporting, so that
>> compat is not able to access this on the kernel versions where it is
>> needed. irq_to_desc and irq_desc are defined in the header files so
>> compilation works, but the module is not loadable because of the
>> missing exported symbol which make compat unusable on all these kernel
>> versions. Remove this function, no driver seams to need it.
>>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> 
> Thanks, if you look at my patch 3e3c23e042 on compat.git it says that
> I added this stuff due to the patch that is now merged on linux.git
> ee9c8a04 -- wl1251: fix oops on early interrupt. That patch was a
> stable fix merged down to v3.4.6. The implications of your tests are
> that wl1251 must be disabled on older kernel or another equivalent
> stable fix must be backported for that driver into
> compat-wireless.git.
> 
> I frankly have too much patch catching up to so I cannot take care of
> this right now so what I will do is disable wl1251 on the updated
> stable releases for kernels older than v2.6.38 which require all this
> backport work. I welcome patches to properly backpor this though.
> 
> I should point out too that this patch was a linux-next.git patch that
> got marked as stable and once merged onto v3.4.6 it required a *new*
> backport change that was not required on a release based on v3.4.5.
> This means that *any* stable fix on older kernels could potentially
> regress stable compat releases. The only way to not regress stable
> compat releases then is if there is no delta from the pulled upstream
> code as there is no gaurantee a stable fix did not implement usage of
> a feature implemented or available only on certain newer kernels.
> 
> Luca, for what kernels do you guys really need wl1251 enabled for?
> 
>   Luis
> 
Hi Luis,

I later tried to deactivate wl1251, but is was already deactivated for
such old kernel versions so there is nothing to do any more after this
patch is applied. Somehow compat contained a not so god backport and
compat-wireless contained this patch:

commit 0a374b9445c78a8e90495bd7d4be00a4f67f2b9b
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date:   Wed May 30 00:39:37 2012 +0200

    compat-wireless: deactivate wl1251 for kernel < 2.6.37

    wl1251_sdio and wl1251_spi are depending on irq_set_status_flags() since

It looks like you tried to backport irq_modify_status() and I
deactivated the users of this function. ;-)

Hauke

Re: [PATCH 2/2] compat: fix endless recursion in flush_scheduled_work

[Luis R. Rodriguez]

On Thu, Aug 2, 2012 at 9:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> The hader file defines flush_scheduled_work(a)
> compat_flush_scheduled_work(a), which causes flush_scheduled_work() and
> compat_flush_scheduled_work() to be the same function.
>
> With this patch it calls the actual function in the kernel.
>
> This fixes problems when unloading mac80211 from compat-wireless.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
>  compat/compat-2.6.36.c |    1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/compat/compat-2.6.36.c b/compat/compat-2.6.36.c
> index 8f25be0..05b41c2 100644
> --- a/compat/compat-2.6.36.c
> +++ b/compat/compat-2.6.36.c
> @@ -133,6 +133,7 @@ int compat_schedule_delayed_work_on(int cpu,
>  }
>  EXPORT_SYMBOL_GPL(compat_schedule_delayed_work_on);
>
> +#undef flush_scheduled_work(a)
>  void compat_flush_scheduled_work(void)

Hah! Nice. I'll add this and push... Zefir can you see if after
getting today's compat.git and then by reverting your patch
3da0495cf863288b on compat.git if the unloading issues still happens.
Likely this was the *real* cause, although it is odd to me you ended
up removing the flush_workqueue() and not the flush_scheduled_work().

  Luis

Re: [PATCH 1/2] compat: remove backport of irq_modify_status

[Luis R. Rodriguez]

On Mon, Aug 6, 2012 at 11:50 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> On 08/06/2012 08:33 PM, Luis R. Rodriguez wrote:
>> On Thu, Aug 2, 2012 at 9:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>> Only kernel >= 2.6.39 irq_to_desc or irq_desc are exporting, so that
>>> compat is not able to access this on the kernel versions where it is
>>> needed. irq_to_desc and irq_desc are defined in the header files so
>>> compilation works, but the module is not loadable because of the
>>> missing exported symbol which make compat unusable on all these kernel
>>> versions. Remove this function, no driver seams to need it.
>>>
>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>
>> Thanks, if you look at my patch 3e3c23e042 on compat.git it says that
>> I added this stuff due to the patch that is now merged on linux.git
>> ee9c8a04 -- wl1251: fix oops on early interrupt. That patch was a
>> stable fix merged down to v3.4.6. The implications of your tests are
>> that wl1251 must be disabled on older kernel or another equivalent
>> stable fix must be backported for that driver into
>> compat-wireless.git.
>>
>> I frankly have too much patch catching up to so I cannot take care of
>> this right now so what I will do is disable wl1251 on the updated
>> stable releases for kernels older than v2.6.38 which require all this
>> backport work. I welcome patches to properly backpor this though.
>>
>> I should point out too that this patch was a linux-next.git patch that
>> got marked as stable and once merged onto v3.4.6 it required a *new*
>> backport change that was not required on a release based on v3.4.5.
>> This means that *any* stable fix on older kernels could potentially
>> regress stable compat releases. The only way to not regress stable
>> compat releases then is if there is no delta from the pulled upstream
>> code as there is no gaurantee a stable fix did not implement usage of
>> a feature implemented or available only on certain newer kernels.
>>
>> Luca, for what kernels do you guys really need wl1251 enabled for?
>>
>>   Luis
>>
> Hi Luis,
>
> I later tried to deactivate wl1251, but is was already deactivated for
> such old kernel versions so there is nothing to do any more after this
> patch is applied. Somehow compat contained a not so god backport and
> compat-wireless contained this patch:
>
> commit 0a374b9445c78a8e90495bd7d4be00a4f67f2b9b
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date:   Wed May 30 00:39:37 2012 +0200
>
>     compat-wireless: deactivate wl1251 for kernel < 2.6.37
>
>     wl1251_sdio and wl1251_spi are depending on irq_set_status_flags() since
>
> It looks like you tried to backport irq_modify_status() and I
> deactivated the users of this function. ;-)

Heh thanks, in that case closed for this change. Thanks!

  Luis

Re: [PATCH 2/2] compat: fix endless recursion in flush_scheduled_work

[Zefir Kurtisi]

On 08/06/2012 08:52 PM, Luis R. Rodriguez wrote:
> On Thu, Aug 2, 2012 at 9:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>> The hader file defines flush_scheduled_work(a)
>> compat_flush_scheduled_work(a), which causes flush_scheduled_work() and
>> compat_flush_scheduled_work() to be the same function.
>>
>> With this patch it calls the actual function in the kernel.
>>
>> This fixes problems when unloading mac80211 from compat-wireless.
>>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>> ---
>>  compat/compat-2.6.36.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/compat/compat-2.6.36.c b/compat/compat-2.6.36.c
>> index 8f25be0..05b41c2 100644
>> --- a/compat/compat-2.6.36.c
>> +++ b/compat/compat-2.6.36.c
>> @@ -133,6 +133,7 @@ int compat_schedule_delayed_work_on(int cpu,
>>  }
>>  EXPORT_SYMBOL_GPL(compat_schedule_delayed_work_on);
>>
>> +#undef flush_scheduled_work(a)
>>  void compat_flush_scheduled_work(void)
> 
> Hah! Nice. I'll add this and push... Zefir can you see if after
> getting today's compat.git and then by reverting your patch
> 3da0495cf863288b on compat.git if the unloading issues still happens.
> Likely this was the *real* cause, although it is odd to me you ended
> up removing the flush_workqueue() and not the flush_scheduled_work().
> 
>   Luis
> 
Yep, works. Thanks Hauke for the proper fix.

As for why I removed the wrong line, I got the macro mapping wrong,
assuming it ended in calling flush_workqueue() - and chose to remove the
wrong one.

Still curious why it is not crashing with my quick hack, that remained
recursion intact...


Thanks

Re: [PATCH 2/2] compat: fix endless recursion in flush_scheduled_work

[Luis R. Rodriguez]

On Thu, Aug 9, 2012 at 2:22 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> On 08/06/2012 08:52 PM, Luis R. Rodriguez wrote:
>> On Thu, Aug 2, 2012 at 9:28 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>> The hader file defines flush_scheduled_work(a)
>>> compat_flush_scheduled_work(a), which causes flush_scheduled_work() and
>>> compat_flush_scheduled_work() to be the same function.
>>>
>>> With this patch it calls the actual function in the kernel.
>>>
>>> This fixes problems when unloading mac80211 from compat-wireless.
>>>
>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>> ---
>>>  compat/compat-2.6.36.c |    1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/compat/compat-2.6.36.c b/compat/compat-2.6.36.c
>>> index 8f25be0..05b41c2 100644
>>> --- a/compat/compat-2.6.36.c
>>> +++ b/compat/compat-2.6.36.c
>>> @@ -133,6 +133,7 @@ int compat_schedule_delayed_work_on(int cpu,
>>>  }
>>>  EXPORT_SYMBOL_GPL(compat_schedule_delayed_work_on);
>>>
>>> +#undef flush_scheduled_work(a)
>>>  void compat_flush_scheduled_work(void)
>>
>> Hah! Nice. I'll add this and push... Zefir can you see if after
>> getting today's compat.git and then by reverting your patch
>> 3da0495cf863288b on compat.git if the unloading issues still happens.
>> Likely this was the *real* cause, although it is odd to me you ended
>> up removing the flush_workqueue() and not the flush_scheduled_work().
>>
>>   Luis
>>
> Yep, works. Thanks Hauke for the proper fix.
>
> As for why I removed the wrong line, I got the macro mapping wrong,
> assuming it ended in calling flush_workqueue() - and chose to remove the
> wrong one.
>
> Still curious why it is not crashing with my quick hack, that remained
> recursion intact...

You tell me! Vodooo!

  Luis