[RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[Paul Gortmaker]

Normally a single patch doesn't warrant a 0/1, but Liang did some
digging on this problem and came up with important background, and
several possible solutions, so I wanted to capture what he'd learned.

The issues with creating an ad-hoc network started in 3.4.3 with the
cherry pick of 463454b5dbd ("cfg80211: fix interface combinations check")
on intel hardware (iwl-mac80211.c) that doesn't support multi-function
or virtual interfaces.  Specifically, it adds this:

+               if ((all_iftypes & used_iftypes) != used_iftypes)
+                       goto cont;

and we have the case for Intel cards that all_iftypes equal to 0b1100
but used_iftypes equal to 0b0010 hence we hit 'goto cont' to miss the
'return 0' and now get EBUSY.

Liang identified f8cdddb8d61d ("cfg80211: check iface combinations
only when iface is running") as part of the fix (now in 3.4.6)

However, things still weren't right unless he also cherry picked the
8e8b41f9d8c8e6 ("cfg80211: enforce lack of interface combinations")
to get the later mentioned "total == 1" check within, so that we
avoid the EBUSY above.  But this commit causes other regressions
(as described in the commit log of the attached patch) so we didn't
think it best to go that route for 3.4.x.

So, the options we considered (to fix 3.4.x stable) were:

1) cherry pick 8e8b41f9d, and all the driver specific changes it requires

2) make a sub-commit for stable that just takes the total==1 from #1.

3) patch iwlwifi/iwl-mac80211.c and add ".types = BIT(NL80211_IFTYPE_ADHOC)"

4) treat ADHOC as a universal feature that everyone has.

The following patch does #4, and in theory it could be used in mainline
and then cherry picked back to stable.  But we weren't 100% sure if that
was the best solution, since neither of us are really wireless people,
hence all the detail here.

Thanks,
Paul.
---

Liang Li (1):
  cfg80211: fix combination check for ADHOC

 net/wireless/util.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
1.7.11.1

[PATCH] cfg80211: fix combination check for ADHOC

[Paul Gortmaker]

From: Liang Li <liang.li@windriver.com>

As part of commit 463454b5dbd8 ("cfg80211: fix interface
combinations check"), this extra check was introduced:

       if ((all_iftypes & used_iftypes) != used_iftypes)
               goto cont;

However, most wireless NIC drivers did not advertise ADHOC in
wiphy.iface_combinations[i].limits[] hence we'll get -EBUSY when
we bring up a ADHOC wlan by commands similar to:

 # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up

In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
combinations"), the change below happens to fix the issue:

       if (total == 1)
               return 0;

But it also introduces other dependencies, at least for stable.
For example, a full cherry pick of 8e8b41f9d8c8e would introduce
additional regressions unless we also start cherry picking driver
specific fixes like the following:

9b4760e  ath5k: add possible wiphy interface combinations
1ae2fc2  mac80211_hwsim: advertise interface combinations
20c8e8d  ath9k: add possible wiphy interface combinations

It seems like we should add an exception for NL80211_IFTYPE_ADHOC, since
it is a kind of 'basic' mode, being supported by almost all wifi cards
but currently most drivers don't advertise it at all.  So making the
NL80211_IFTYPE_ADHOC a part of all_iftypes seems reasonable.

Doing so also gives stable kernels a way to fix the change introduced
by 463454b5dbd8, without having to make cherry picks specific to
various NIC drivers.

Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 net/wireless/util.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 26f8cd3..4a4749c 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1129,6 +1129,8 @@ int cfg80211_can_use_iftype_chan(struct cfg80211_registered_device *rdev,
 			}
 		}
 
+		all_iftypes |= BIT(NL80211_IFTYPE_ADHOC);
+
 		/*
 		 * Finally check that all iftypes that we're currently
 		 * using are actually part of this combination. If they
-- 
1.7.11.1

Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[Johannes Berg]

On Wed, 2012-08-01 at 12:14 -0400, Paul Gortmaker wrote:

[...]

> However, things still weren't right unless he also cherry picked the
> 8e8b41f9d8c8e6 ("cfg80211: enforce lack of interface combinations")
> to get the later mentioned "total == 1" check within, so that we
> avoid the EBUSY above.  But this commit causes other regressions
> (as described in the commit log of the attached patch) so we didn't
> think it best to go that route for 3.4.x.
> 
> So, the options we considered (to fix 3.4.x stable) were:
> 
> 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires
> 
> 2) make a sub-commit for stable that just takes the total==1 from #1.
> 
> 3) patch iwlwifi/iwl-mac80211.c and add ".types = BIT(NL80211_IFTYPE_ADHOC)"
> 
> 4) treat ADHOC as a universal feature that everyone has.
> 
> The following patch does #4, and in theory it could be used in mainline
> and then cherry picked back to stable.  But we weren't 100% sure if that
> was the best solution, since neither of us are really wireless people,
> hence all the detail here.

Thanks for the detailed analysis. Given 8e8b41f9d, I don't think any
mainline changes are actually needed?

I don't think #4 is right, not all drivers do in fact support IBSS.
Making them advertise it will just cause issues.

I think #2 would be the best option.

johannes

Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[Paul Gortmaker]

[Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x] On 01/08/2012 (Wed 18:31) Johannes Berg wrote:

> On Wed, 2012-08-01 at 12:14 -0400, Paul Gortmaker wrote:
> 
> [...]
> 
> > However, things still weren't right unless he also cherry picked the
> > 8e8b41f9d8c8e6 ("cfg80211: enforce lack of interface combinations")
> > to get the later mentioned "total == 1" check within, so that we
> > avoid the EBUSY above.  But this commit causes other regressions
> > (as described in the commit log of the attached patch) so we didn't
> > think it best to go that route for 3.4.x.
> > 
> > So, the options we considered (to fix 3.4.x stable) were:
> > 
> > 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires
> > 
> > 2) make a sub-commit for stable that just takes the total==1 from #1.
> > 
> > 3) patch iwlwifi/iwl-mac80211.c and add ".types = BIT(NL80211_IFTYPE_ADHOC)"
> > 
> > 4) treat ADHOC as a universal feature that everyone has.
> > 
> > The following patch does #4, and in theory it could be used in mainline
> > and then cherry picked back to stable.  But we weren't 100% sure if that
> > was the best solution, since neither of us are really wireless people,
> > hence all the detail here.
> 
> Thanks for the detailed analysis. Given 8e8b41f9d, I don't think any
> mainline changes are actually needed?

Perhaps not.  I know Liang was looking at the ath5k and ath9k changes:

  9b4760e  ath5k: add possible wiphy interface combinations
  20c8e8d  ath9k: add possible wiphy interface combinations

and thinking that the above commits plus the "total==1" change
wouldn't fix any ATH multifunction cards (if they exist) in the
ad-hoc use case - but we didn't have such hardware to test with.

And from what you say below, maybe they should not be, if there
are cards which don't support it.

> 
> I don't think #4 is right, not all drivers do in fact support IBSS.
> Making them advertise it will just cause issues.
> 
> I think #2 would be the best option.

OK, no problem.  We can do that and resend.  I'll give Liang a chance
to catch up on the reading (different time zone) and confirm I've
captured all his descriptions properly before resending.

Thanks,
Paul.

> 
> johannes
> 

Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[Johannes Berg]

On Wed, 2012-08-01 at 13:38 -0400, Paul Gortmaker wrote:

> > > 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires
> > > 
> > > 2) make a sub-commit for stable that just takes the total==1 from #1.
> > > 
> > > 3) patch iwlwifi/iwl-mac80211.c and add ".types = BIT(NL80211_IFTYPE_ADHOC)"
> > > 
> > > 4) treat ADHOC as a universal feature that everyone has.
> > > 
> > > The following patch does #4, and in theory it could be used in mainline
> > > and then cherry picked back to stable.  But we weren't 100% sure if that
> > > was the best solution, since neither of us are really wireless people,
> > > hence all the detail here.
> > 
> > Thanks for the detailed analysis. Given 8e8b41f9d, I don't think any
> > mainline changes are actually needed?
> 
> Perhaps not.  I know Liang was looking at the ath5k and ath9k changes:
> 
>   9b4760e  ath5k: add possible wiphy interface combinations
>   20c8e8d  ath9k: add possible wiphy interface combinations
> 
> and thinking that the above commits plus the "total==1" change
> wouldn't fix any ATH multifunction cards (if they exist) in the
> ad-hoc use case - but we didn't have such hardware to test with.

I'm not sure what you mean by "wouldn't fix" here -- the way the devices
advertise their multi-virtual-interface support is that they do not
support IBSS (ad-hoc) in combination with any other interface.
Therefore, pure IBSS should be covered by the total==1 case?

johannes

Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[Paul Gortmaker]

[Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x] On 01/08/2012 (Wed 19:42) Johannes Berg wrote:

> On Wed, 2012-08-01 at 13:38 -0400, Paul Gortmaker wrote:
> 
> > > > 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires
> > > > 
> > > > 2) make a sub-commit for stable that just takes the total==1 from #1.
> > > > 
> > > > 3) patch iwlwifi/iwl-mac80211.c and add ".types = BIT(NL80211_IFTYPE_ADHOC)"
> > > > 
> > > > 4) treat ADHOC as a universal feature that everyone has.
> > > > 
> > > > The following patch does #4, and in theory it could be used in mainline
> > > > and then cherry picked back to stable.  But we weren't 100% sure if that
> > > > was the best solution, since neither of us are really wireless people,
> > > > hence all the detail here.
> > > 
> > > Thanks for the detailed analysis. Given 8e8b41f9d, I don't think any
> > > mainline changes are actually needed?
> > 
> > Perhaps not.  I know Liang was looking at the ath5k and ath9k changes:
> > 
> >   9b4760e  ath5k: add possible wiphy interface combinations
> >   20c8e8d  ath9k: add possible wiphy interface combinations
> > 
> > and thinking that the above commits plus the "total==1" change
> > wouldn't fix any ATH multifunction cards (if they exist) in the
> > ad-hoc use case - but we didn't have such hardware to test with.
> 
> I'm not sure what you mean by "wouldn't fix" here -- the way the devices
> advertise their multi-virtual-interface support is that they do not
> support IBSS (ad-hoc) in combination with any other interface.
> Therefore, pure IBSS should be covered by the total==1 case?

OK, it sounds like I/we were simply just misunderstanding the code,
due to lack of wireless knowledge, and that the exclusion was
intentional.  We'll get the total==1 subpatch posted here tomorrow.

Thanks again for the input.
Paul.
--

> 
> johannes
> 

[PATCH stable] cfg80211: fix interface combinations check for ADHOC(IBSS)

[Paul Gortmaker]

From: Liang Li <liang.li@windriver.com>

partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream.

As part of commit 463454b5dbd8 ("cfg80211: fix interface
combinations check"), this extra check was introduced:

       if ((all_iftypes & used_iftypes) != used_iftypes)
               goto cont;

However, most wireless NIC drivers did not advertise ADHOC in
wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
when we bring up a ADHOC wlan with commands similar to:

 # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up

In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
combinations"), the change below fixes the issue:

       if (total == 1)
               return 0;

But it also introduces other dependencies for stable. For example,
a full cherry pick of 8e8b41f9d8c8e would introduce additional
regressions unless we also start cherry picking driver specific
fixes like the following:

  9b4760e  ath5k: add possible wiphy interface combinations
  1ae2fc2  mac80211_hwsim: advertise interface combinations
  20c8e8d  ath9k: add possible wiphy interface combinations

And the purpose of the 'if (total == 1)' is to cover the specific
use case (IBSS, adhoc) that was mentioned above. So we just pick
the specific part out from 8e8b41f9d8c8e here.

Doing so gives stable kernels a way to fix the change introduced
by 463454b5dbd8, without having to make cherry picks specific to
various NIC drivers.

Cc: stable@vger.kernel.org
Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---

3.0.35, 3.2.21 and 3.4.3 have CP of 463454b5dbd8 in them.

 net/wireless/util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index b5b6890..88bd89e 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -974,6 +974,9 @@ int cfg80211_can_change_interface(struct cfg80211_registered_device *rdev,
 	}
 	mutex_unlock(&rdev->devlist_mtx);
 
+	if (total == 1)
+		return 0;
+
 	for (i = 0; i < rdev->wiphy.n_iface_combinations; i++) {
 		const struct ieee80211_iface_combination *c;
 		struct ieee80211_iface_limit *limits;
-- 
1.7.12.rc1.1.gbce1580

Re: [PATCH stable] cfg80211: fix interface combinations check for ADHOC(IBSS)

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]

On Thu, 2012-08-02 at 18:55 -0400, Paul Gortmaker wrote:
> From: Liang Li <liang.li@windriver.com>
> 
> partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream.

Added to the queue for 3.2, thanks.

Ben.

> As part of commit 463454b5dbd8 ("cfg80211: fix interface
> combinations check"), this extra check was introduced:
> 
>        if ((all_iftypes & used_iftypes) != used_iftypes)
>                goto cont;
> 
> However, most wireless NIC drivers did not advertise ADHOC in
> wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
> when we bring up a ADHOC wlan with commands similar to:
> 
>  # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up
> 
> In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
> combinations"), the change below fixes the issue:
> 
>        if (total == 1)
>                return 0;
> 
> But it also introduces other dependencies for stable. For example,
> a full cherry pick of 8e8b41f9d8c8e would introduce additional
> regressions unless we also start cherry picking driver specific
> fixes like the following:
> 
>   9b4760e  ath5k: add possible wiphy interface combinations
>   1ae2fc2  mac80211_hwsim: advertise interface combinations
>   20c8e8d  ath9k: add possible wiphy interface combinations
> 
> And the purpose of the 'if (total == 1)' is to cover the specific
> use case (IBSS, adhoc) that was mentioned above. So we just pick
> the specific part out from 8e8b41f9d8c8e here.
> 
> Doing so gives stable kernels a way to fix the change introduced
> by 463454b5dbd8, without having to make cherry picks specific to
> various NIC drivers.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Liang Li <liang.li@windriver.com>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> 
> 3.0.35, 3.2.21 and 3.4.3 have CP of 463454b5dbd8 in them.
> 
>  net/wireless/util.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index b5b6890..88bd89e 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -974,6 +974,9 @@ int cfg80211_can_change_interface(struct cfg80211_registered_device *rdev,
>  	}
>  	mutex_unlock(&rdev->devlist_mtx);
>  
> +	if (total == 1)
> +		return 0;
> +
>  	for (i = 0; i < rdev->wiphy.n_iface_combinations; i++) {
>  		const struct ieee80211_iface_combination *c;
>  		struct ieee80211_iface_limit *limits;

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Patch "cfg80211: fix interface combinations check for ADHOC(IBSS)" has been added to the 3.4-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    cfg80211: fix interface combinations check for ADHOC(IBSS)

to the 3.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     cfg80211-fix-interface-combinations-check-for-adhoc-ibss.patch
and it can be found in the queue-3.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From paul.gortmaker@windriver.com  Mon Aug 13 11:39:55 2012
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 2 Aug 2012 18:55:41 -0400
Subject: cfg80211: fix interface combinations check for ADHOC(IBSS)
To: Johannes Berg <johannes@sipsolutions.net>
Cc: <linux-wireless@vger.kernel.org>, <linville@tuxdriver.com>, Liang Li <liang.li@windriver.com>, <stable@vger.kernel.org>, Paul Gortmaker <paul.gortmaker@windriver.com>
Message-ID: <1343948141-25005-1-git-send-email-paul.gortmaker@windriver.com>


From: Liang Li <liang.li@windriver.com>

partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream.

As part of commit 463454b5dbd8 ("cfg80211: fix interface
combinations check"), this extra check was introduced:

       if ((all_iftypes & used_iftypes) != used_iftypes)
               goto cont;

However, most wireless NIC drivers did not advertise ADHOC in
wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
when we bring up a ADHOC wlan with commands similar to:

 # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up

In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
combinations"), the change below fixes the issue:

       if (total == 1)
               return 0;

But it also introduces other dependencies for stable. For example,
a full cherry pick of 8e8b41f9d8c8e would introduce additional
regressions unless we also start cherry picking driver specific
fixes like the following:

  9b4760e  ath5k: add possible wiphy interface combinations
  1ae2fc2  mac80211_hwsim: advertise interface combinations
  20c8e8d  ath9k: add possible wiphy interface combinations

And the purpose of the 'if (total == 1)' is to cover the specific
use case (IBSS, adhoc) that was mentioned above. So we just pick
the specific part out from 8e8b41f9d8c8e here.

Doing so gives stable kernels a way to fix the change introduced
by 463454b5dbd8, without having to make cherry picks specific to
various NIC drivers.

Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/wireless/util.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -974,6 +974,9 @@ int cfg80211_can_change_interface(struct
 	}
 	mutex_unlock(&rdev->devlist_mtx);
 
+	if (total == 1)
+		return 0;
+
 	for (i = 0; i < rdev->wiphy.n_iface_combinations; i++) {
 		const struct ieee80211_iface_combination *c;
 		struct ieee80211_iface_limit *limits;


Patches currently in stable-queue which might be from paul.gortmaker@windriver.com are

queue-3.4/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch
queue-3.4/cfg80211-fix-interface-combinations-check-for-adhoc-ibss.patch

Patch "cfg80211: fix interface combinations check for ADHOC(IBSS)" has been added to the 3.0-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    cfg80211: fix interface combinations check for ADHOC(IBSS)

to the 3.0-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     cfg80211-fix-interface-combinations-check-for-adhoc-ibss.patch
and it can be found in the queue-3.0 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From paul.gortmaker@windriver.com  Mon Aug 13 11:39:55 2012
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 2 Aug 2012 18:55:41 -0400
Subject: cfg80211: fix interface combinations check for ADHOC(IBSS)
To: Johannes Berg <johannes@sipsolutions.net>
Cc: <linux-wireless@vger.kernel.org>, <linville@tuxdriver.com>, Liang Li <liang.li@windriver.com>, <stable@vger.kernel.org>, Paul Gortmaker <paul.gortmaker@windriver.com>
Message-ID: <1343948141-25005-1-git-send-email-paul.gortmaker@windriver.com>


From: Liang Li <liang.li@windriver.com>

partial of commit 8e8b41f9d8c8e63fc92f899ace8da91a490ac573 upstream.

As part of commit 463454b5dbd8 ("cfg80211: fix interface
combinations check"), this extra check was introduced:

       if ((all_iftypes & used_iftypes) != used_iftypes)
               goto cont;

However, most wireless NIC drivers did not advertise ADHOC in
wiphy.iface_combinations[i].limits[] and hence we'll get -EBUSY
when we bring up a ADHOC wlan with commands similar to:

 # iwconfig wlan0 mode ad-hoc && ifconfig wlan0 up

In commit 8e8b41f9d8c8e ("cfg80211: enforce lack of interface
combinations"), the change below fixes the issue:

       if (total == 1)
               return 0;

But it also introduces other dependencies for stable. For example,
a full cherry pick of 8e8b41f9d8c8e would introduce additional
regressions unless we also start cherry picking driver specific
fixes like the following:

  9b4760e  ath5k: add possible wiphy interface combinations
  1ae2fc2  mac80211_hwsim: advertise interface combinations
  20c8e8d  ath9k: add possible wiphy interface combinations

And the purpose of the 'if (total == 1)' is to cover the specific
use case (IBSS, adhoc) that was mentioned above. So we just pick
the specific part out from 8e8b41f9d8c8e here.

Doing so gives stable kernels a way to fix the change introduced
by 463454b5dbd8, without having to make cherry picks specific to
various NIC drivers.

Signed-off-by: Liang Li <liang.li@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/wireless/util.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -975,6 +975,9 @@ int cfg80211_can_change_interface(struct
 	}
 	mutex_unlock(&rdev->devlist_mtx);
 
+	if (total == 1)
+		return 0;
+
 	for (i = 0; i < rdev->wiphy.n_iface_combinations; i++) {
 		const struct ieee80211_iface_combination *c;
 		struct ieee80211_iface_limit *limits;


Patches currently in stable-queue which might be from paul.gortmaker@windriver.com are

queue-3.0/mm-mmu_notifier-fix-freed-page-still-mapped-in-secondary-mmu.patch
queue-3.0/cfg80211-fix-interface-combinations-check-for-adhoc-ibss.patch

Re: [RFC/PATCH 0/1] Fix inability to configure adhoc in 3.4.x

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

On Wed, 2012-08-01 at 12:14 -0400, Paul Gortmaker wrote:
> Normally a single patch doesn't warrant a 0/1, but Liang did some
> digging on this problem and came up with important background, and
> several possible solutions, so I wanted to capture what he'd learned.
> 
> The issues with creating an ad-hoc network started in 3.4.3 with the
> cherry pick of 463454b5dbd ("cfg80211: fix interface combinations check")
> on intel hardware (iwl-mac80211.c) that doesn't support multi-function
> or virtual interfaces.  Specifically, it adds this:
> 
> +               if ((all_iftypes & used_iftypes) != used_iftypes)
> +                       goto cont;
> 
> and we have the case for Intel cards that all_iftypes equal to 0b1100
> but used_iftypes equal to 0b0010 hence we hit 'goto cont' to miss the
> 'return 0' and now get EBUSY.
> 
> Liang identified f8cdddb8d61d ("cfg80211: check iface combinations
> only when iface is running") as part of the fix (now in 3.4.6)

3.2.y also has the above two changes, so presumably also has this
regression.

Ben.

> However, things still weren't right unless he also cherry picked the
> 8e8b41f9d8c8e6 ("cfg80211: enforce lack of interface combinations")
> to get the later mentioned "total == 1" check within, so that we
> avoid the EBUSY above.  But this commit causes other regressions
> (as described in the commit log of the attached patch) so we didn't
> think it best to go that route for 3.4.x.
> 
> So, the options we considered (to fix 3.4.x stable) were:
> 
> 1) cherry pick 8e8b41f9d, and all the driver specific changes it requires
> 
> 2) make a sub-commit for stable that just takes the total==1 from #1.
> 
> 3) patch iwlwifi/iwl-mac80211.c and add ".types = BIT(NL80211_IFTYPE_ADHOC)"
> 
> 4) treat ADHOC as a universal feature that everyone has.
> 
> The following patch does #4, and in theory it could be used in mainline
> and then cherry picked back to stable.  But we weren't 100% sure if that
> was the best solution, since neither of us are really wireless people,
> hence all the detail here.
> 
> Thanks,
> Paul.
> ---
> 
> Liang Li (1):
>   cfg80211: fix combination check for ADHOC
> 
>  net/wireless/util.c | 2 ++
>  1 file changed, 2 insertions(+)
> 

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
                                                         - Carolyn Scheppner

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]