From: Johannes Berg <johannes@sipsolutions.net>
To: Eliad Peller <eliad@wizery.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH 4/4] cfg80211: prevent race condition on scan request cleanup
Date: Thu, 05 Dec 2013 16:45:30 +0100 [thread overview]
Message-ID: <1386258330.4182.11.camel@jlt4.sipsolutions.net> (raw)
In-Reply-To: <CAB3XZEc4pikahyAmPCh_pCjFEiRvFgAyZgxGrbH9A6hLP2nhFw@mail.gmail.com> (sfid-20131205_163919_049659_09596AAD)
On Thu, 2013-12-05 at 17:39 +0200, Eliad Peller wrote:
> On Thu, Dec 5, 2013 at 4:43 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Thu, 2013-12-05 at 16:36 +0200, Eliad Peller wrote:
> >> On Thu, Dec 5, 2013 at 4:31 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> >> > On Thu, 2013-12-05 at 11:21 +0200, Eliad Peller wrote:
> >> >
> >> >> @@ -219,8 +221,13 @@ void ___cfg80211_scan_done(struct cfg80211_registered_device *rdev, bool leak)
> >> >> * the scan request or not ... if it accesses the dev
> >> >> * in there (it shouldn't anyway) then it may crash.
> >> >> */
> >> >> - if (!leak)
> >> >> - kfree(request);
> >> >> + if (leak) {
> >> >> + request->pending_cleanup = true;
> >> >> + return;
> >> >
> >> > This seems insufficient, if the driver never indicates completion, we'd
> >> > never clear rdev->scan_req?
> >> >
> >> right, but i think it somehow makes sense (i.e. the driver must
> >> indicate completion...)?
> >
> > But the whole thing was intended to catch buggy drivers :)
> >
> yeah, you have a point here :)
> anyway, i guess it's either leaking scan_req and hoping the driver
> really forgot about it, or keeping it and hoping the driver will
> finally indicate completion.
>
> since i don't think this is a real-world scenario, i'm ok with
> dropping this patch.
Well, it can be made to crash, so ...
Can we maybe avoid the crash in a different way? Disallow a new scan
somehow?
> > Btw, should any of this go to 3.13?
> maybe the first one. it's the only "real" issue.
Thanks.
johannes
next prev parent reply other threads:[~2013-12-05 15:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-05 9:21 [PATCH 1/4] cfg80211: stop sched scan only when needed Eliad Peller
2013-12-05 9:21 ` [PATCH 2/4] mac80211: determine completed scan type by defined ops Eliad Peller
2013-12-05 9:21 ` [PATCH 3/4] mac80211: start_next_roc only if scan was actually running Eliad Peller
2013-12-05 9:21 ` [PATCH 4/4] cfg80211: prevent race condition on scan request cleanup Eliad Peller
2013-12-05 14:31 ` Johannes Berg
2013-12-05 14:36 ` Eliad Peller
2013-12-05 14:43 ` Johannes Berg
2013-12-05 15:39 ` Eliad Peller
2013-12-05 15:45 ` Johannes Berg [this message]
2013-12-05 15:52 ` Arik Nemtsov
2013-12-05 15:53 ` Johannes Berg
2013-12-05 16:14 ` Johannes Berg
2013-12-05 16:32 ` Eliad Peller
2013-12-05 16:18 ` [PATCH 1/4] cfg80211: stop sched scan only when needed Johannes Berg
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=1386258330.4182.11.camel@jlt4.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=eliad@wizery.com \
--cc=linux-wireless@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox