Subject: Re: [PATCH] ieee80211softmac: Fix errors related to the work_struct changes

From: Larry Finger <[email-masked]>
Date: Mon, 11 Dec 2006 11:34:15 -0600

Andrew Morton wrote:
> On Sun, 10 Dec 2006 19:35:36 +0100
> Ulrich Kunitz <[email-masked]> wrote:
> 
>> The problem is that you there are now different work structures:
>> struct work_struct and struct delayed_work. The quick fix seems to
>> have been to change all old work_structs as associnfo's work to
>> delayed_work. The way the structures are designed calling
>> schedule_work or schedule_delayed_work doesn't matter, but you
>> will get a gcc warning, because the pointer types are not
>> identical. This change works around the warning in the same way as
>> the other schedule_work calls for associnfo's work.
> 
> David proposed the below.  Does it fix things for you?
> 
> --- a/net/ieee80211/softmac/ieee80211softmac_assoc.c~workstruct-fix-ieee80211-softmac-compile-problem
> +++ a/net/ieee80211/softmac/ieee80211softmac_assoc.c
> @@ -438,7 +438,7 @@ ieee80211softmac_try_reassoc(struct ieee
>  
>  	spin_lock_irqsave(&mac->lock, flags);
>  	mac->associnfo.associating = 1;
> -	schedule_work(&mac->associnfo.work);
> +	schedule_delayed_work(&mac->associnfo.work, 0);
>  	spin_unlock_irqrestore(&mac->lock, flags);
>  }
>  
> _
> 
>> I'm not sure, whether the breaking of the workqueue API is really
>> worth it. What I see is that the change introduced choices and
>> choices make things more complex.
> 
> It is kinda sucky.  But it saves a bit of space in kernel data structures.

The above patch fixes a compile problem; however, the code still hangs when the network is started.
You need two additional hunks as shown below.

Larry
=========================================================================

From: Ulrich Kunitz <[email-masked]>

The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assoc_work
function has  been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).

Signed-off-by: Ulrich Kunitz <[email-masked]>
Acked-by: Michael Buesch <[email-masked]>
Signed-off-by: Larry Finger <[email-masked]>
---

diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c 
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
  ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type, void *context)
  {
  	struct ieee80211softmac_device *mac = ieee80211_priv(dev);
-	ieee80211softmac_assoc_work((void*)mac);
+	ieee80211softmac_assoc_work(&mac->associnfo.work.work);
  }

  static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc

  	switch (event_type) {
  	case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
-		ieee80211softmac_assoc_work((void*)mac);
+		ieee80211softmac_assoc_work(&mac->associnfo.work.work);
  		break;
  	case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
  	case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT: