From: Michael Buesch <mb@bu3sch.de>
To: Ulrich Kunitz <kune@deine-taler.de>
Cc: dsd@gentoo.org, Johannes Berg <johannes@sipsolutions.net>,
"John W. Linville" <linville@tuxdriver.com>,
Andrew Morton <akpm@osdl.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH] ieee80211softmac: Fix errors related to the work_struct changes
Date: Sun, 10 Dec 2006 19:40:48 +0100 [thread overview]
Message-ID: <200612101940.48996.mb@bu3sch.de> (raw)
In-Reply-To: <20061210183536.GC29871@p15091797.pureserver.info>
On Sunday 10 December 2006 19:35, Ulrich Kunitz wrote:
> On 06-12-10 18:49 Michael Buesch wrote:
>
> > On Sunday 10 December 2006 18:39, Ulrich Kunitz wrote:
> > > 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_assox_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 <kune@deine-taler.de>
> > > ---
> > > net/ieee80211/softmac/ieee80211softmac_assoc.c | 6 +++---
> > > 1 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > 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:
> > > @@ -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);
> >
> > Why do you use a zero delay here? What does that fix?
> >
>
> 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.
>
> 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.
Ah, ok. Thanks for the clarification. In this case this patch is
ACKed as well.
--
Greetings Michael.
next prev parent reply other threads:[~2006-12-10 18:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-10 17:39 [PATCH] ieee80211softmac: Fix errors related to the work_struct changes Ulrich Kunitz
2006-12-10 17:49 ` Michael Buesch
2006-12-10 18:35 ` Ulrich Kunitz
2006-12-10 18:40 ` Michael Buesch [this message]
2006-12-10 18:40 ` Andrew Morton
2006-12-11 17:34 ` Larry Finger
2006-12-11 4:24 ` Larry Finger
2006-12-11 21:49 ` John W. Linville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200612101940.48996.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=akpm@osdl.org \
--cc=dsd@gentoo.org \
--cc=johannes@sipsolutions.net \
--cc=kune@deine-taler.de \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.