* Re: [PATCH] net: use synchronize_rcu_expedited()
From: Eric Dumazet @ 2011-05-24 19:44 UTC (permalink / raw)
To: paulmck; +Cc: David Miller, netdev
In-Reply-To: <20110524192451.GH2266@linux.vnet.ibm.com>
Le mardi 24 mai 2011 à 12:24 -0700, Paul E. McKenney a écrit :
> Might make sense, though most of the gains would need to come from
> kicking the grace-period machinery hard in order to make it go faster.
>
> Interesting -- I will give this some thought.
>
I am working on a final step, using a workqueue so that the
rcu_barrier() is not done under RTNL, so it wont be anymore a blocking
point to dismantle hundred of devices per second...
Thanks
^ permalink raw reply
* Re: linux-next: Tree for May 24 (ratelimits, CONFIG_PRINTK not enabled)
From: Joe Perches @ 2011-05-24 19:49 UTC (permalink / raw)
To: David Miller; +Cc: randy.dunlap, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20110524.153222.1953796640575918161.davem@davemloft.net>
On Tue, 2011-05-24 at 15:32 -0400, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 24 May 2011 11:49:48 -0700
> > On Tue, 2011-05-24 at 11:33 -0700, Randy Dunlap wrote:
> >> Adding <linux/ratelimit.h> to <asm-generic/bug.h> causes other problems:
> > Yup, that's not a good solution.
> Please come up with a fix or I'll have to revert, thanks Joe.
I have some errands to run for awhile.
Probably a revert today and another patch set tomorrow
might be best.
This seems to work and doesn't cause any extra state to be
instantiated when !CONFIG_PRINTK. What do you think?
#ifdef CONFIG_PRINTK
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON((condition) && __ratelimit(state))
#define __WARN_RATELIMIT(condition, state, format...) \
({ \
int rtn = 0; \
if (unlikely(__ratelimit(state))) \
rtn = WARN(condition, format); \
rtn; \
})
#define WARN_RATELIMIT(condition, format...) \
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
DEFAULT_RATELIMIT_INTERVAL, \
DEFAULT_RATELIMIT_BURST); \
__WARN_RATELIMIT(condition, &_rs, format); \
})
#else
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON(condition)
#define __WARN_RATELIMIT(condition, state, format...) \
({ \
int rtn = WARN(condition, format); \
rtn; \
})
#define WARN_RATELIMIT(condition, format...) \
({ \
int rtn = WARN(condition, format); \
rtn; \
})
#endif
^ permalink raw reply
* Re: linux-next: Tree for May 24 (ratelimits, CONFIG_PRINTK not enabled)
From: David Miller @ 2011-05-24 19:53 UTC (permalink / raw)
To: joe; +Cc: randy.dunlap, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <1306266580.2298.55.camel@Joe-Laptop>
From: Joe Perches <joe@perches.com>
Date: Tue, 24 May 2011 12:49:40 -0700
> On Tue, 2011-05-24 at 15:32 -0400, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Tue, 24 May 2011 11:49:48 -0700
>> > On Tue, 2011-05-24 at 11:33 -0700, Randy Dunlap wrote:
>> >> Adding <linux/ratelimit.h> to <asm-generic/bug.h> causes other problems:
>> > Yup, that's not a good solution.
>> Please come up with a fix or I'll have to revert, thanks Joe.
>
> I have some errands to run for awhile.
>
> Probably a revert today and another patch set tomorrow
> might be best.
>
> This seems to work and doesn't cause any extra state to be
> instantiated when !CONFIG_PRINTK. What do you think?
Seems fine, here it is as a patch.
Randy please test this, thanks:
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 12b250c..9178484 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -162,6 +162,8 @@ extern void warn_slowpath_null(const char *file, const int line);
unlikely(__ret_warn_once); \
})
+#ifdef CONFIG_PRINTK
+
#define WARN_ON_RATELIMIT(condition, state) \
WARN_ON((condition) && __ratelimit(state))
@@ -181,6 +183,25 @@ extern void warn_slowpath_null(const char *file, const int line);
__WARN_RATELIMIT(condition, &_rs, format); \
})
+#else
+
+#define WARN_ON_RATELIMIT(condition, state) \
+ WARN_ON(condition)
+
+#define __WARN_RATELIMIT(condition, state, format...) \
+({ \
+ int rtn = WARN(condition, format); \
+ rtn; \
+})
+
+#define WARN_RATELIMIT(condition, format...) \
+({ \
+ int rtn = WARN(condition, format); \
+ rtn; \
+})
+
+#endif
+
/*
* WARN_ON_SMP() is for cases that the warning is either
* meaningless for !SMP or may even cause failures.
^ permalink raw reply related
* Re: [PATCH] net: use synchronize_rcu_expedited()
From: Paul E. McKenney @ 2011-05-24 19:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1306266285.3305.3.camel@edumazet-laptop>
On Tue, May 24, 2011 at 09:44:45PM +0200, Eric Dumazet wrote:
> Le mardi 24 mai 2011 à 12:24 -0700, Paul E. McKenney a écrit :
>
> > Might make sense, though most of the gains would need to come from
> > kicking the grace-period machinery hard in order to make it go faster.
> >
> > Interesting -- I will give this some thought.
>
> I am working on a final step, using a workqueue so that the
> rcu_barrier() is not done under RTNL, so it wont be anymore a blocking
> point to dismantle hundred of devices per second...
OK, I will keep rcu_barrier_expedited() on the "might be useful list",
but will keep to the current plan: finishing up rough edges on RCU
priority boosting, merging SRCU into TREE_RCU and TINY_RCU, and so forth.
But let me know if you do need it.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Andy Gospodarek @ 2011-05-24 20:00 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Jay Vosburgh, Andy Gospodarek, David S. Miller
In-Reply-To: <1306265765-8257-1-git-send-email-nhorman@tuxdriver.com>
On Tue, May 24, 2011 at 03:36:05PM -0400, Neil Horman wrote:
> This soft lockup was recently reported:
>
> [root@dell-per715-01 ~]# echo +bond5 > /sys/class/net/bonding_masters
> [root@dell-per715-01 ~]# echo +eth1 > /sys/class/net/bond5/bonding/slaves
> bonding: bond5: doing slave updates when interface is down.
> bonding bond5: master_dev is not up in bond_enslave
> [root@dell-per715-01 ~]# echo -eth1 > /sys/class/net/bond5/bonding/slaves
> bonding: bond5: doing slave updates when interface is down.
>
> BUG: soft lockup - CPU#12 stuck for 60s! [bash:6444]
> CPU 12:
> Modules linked in: bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
> be2d
> Pid: 6444, comm: bash Not tainted 2.6.18-262.el5 #1
> RIP: 0010:[<ffffffff80064bf0>] [<ffffffff80064bf0>]
> .text.lock.spinlock+0x26/00
> RSP: 0018:ffff810113167da8 EFLAGS: 00000286
> RAX: ffff810113167fd8 RBX: ffff810123a47800 RCX: 0000000000ff1025
> RDX: 0000000000000000 RSI: ffff810123a47800 RDI: ffff81021b57f6f8
> RBP: ffff81021b57f500 R08: 0000000000000000 R09: 000000000000000c
> R10: 00000000ffffffff R11: ffff81011d41c000 R12: ffff81021b57f000
> R13: 0000000000000000 R14: 0000000000000282 R15: 0000000000000282
> FS: 00002b3b41ef3f50(0000) GS:ffff810123b27940(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002b3b456dd000 CR3: 000000031fc60000 CR4: 00000000000006e0
>
> Call Trace:
> [<ffffffff80064af9>] _spin_lock_bh+0x9/0x14
> [<ffffffff886937d7>] :bonding:tlb_clear_slave+0x22/0xa1
> [<ffffffff8869423c>] :bonding:bond_alb_deinit_slave+0xba/0xf0
> [<ffffffff8868dda6>] :bonding:bond_release+0x1b4/0x450
> [<ffffffff8006457b>] __down_write_nested+0x12/0x92
> [<ffffffff88696ae4>] :bonding:bonding_store_slaves+0x25c/0x2f7
> [<ffffffff801106f7>] sysfs_write_file+0xb9/0xe8
> [<ffffffff80016b87>] vfs_write+0xce/0x174
> [<ffffffff80017450>] sys_write+0x45/0x6e
> [<ffffffff8005d28d>] tracesys+0xd5/0xe0
>
> It occurs because we are able to change the slave configuarion of a bond while
> the bond interface is down. The bonding driver initializes some data structures
> only after its ndo_open routine is called. Among them is the initalization of
> the alb tx and rx hash locks. So if we add or remove a slave without first
> opening the bond master device, we run the risk of trying to lock/unlock a
> spinlock that has garbage for data in it, which results in our above softlock.
>
> We could fix it by moving the spin lock initalization to the device creation
> path, but it seems that since we're warning people about not doing this, we
> should probably just disallow them from doing it, so fix it by adding an EINVAL
> return if we're not up yet. Tested by the reporter and confirmed to fix the
> problem.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Reported-by: jtluka@redhat.com
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> CC: "David S. Miller" <daevm@davemloft.net>
> ---
> drivers/net/bonding/bond_sysfs.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
> index 4059bfc..206c543 100644
> --- a/drivers/net/bonding/bond_sysfs.c
> +++ b/drivers/net/bonding/bond_sysfs.c
> @@ -231,6 +231,7 @@ static ssize_t bonding_store_slaves(struct device *d,
> if (!(bond->dev->flags & IFF_UP)) {
> pr_warning("%s: doing slave updates when interface is down.\n",
> bond->dev->name);
> + return -EINVAL;
> }
>
> if (!rtnl_trylock())
> --
> 1.7.5.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: small RPS cache for fragments?
From: David Miller @ 2011-05-24 20:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110517.143342.1566027350038182221.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 17 May 2011 14:33:42 -0400 (EDT)
>
> It seems to me that we can solve the UDP fragmentation problem for
> flow steering very simply by creating a (saddr/daddr/IPID) entry in a
> table that maps to the corresponding RPS flow entry.
>
> When we see the initial frag with the UDP header, we create the
> saddr/daddr/IPID mapping, and we tear it down when we hit the
> saddr/daddr/IPID mapping and the packet has the IP_MF bit clear.
>
> We only inspect the saddr/daddr/IPID cache when iph->frag_off is
> non-zero.
So I looked into implementing this now that it has been established
that we changed even Linux to emit fragments in-order.
The first problem we run into is that there is no "context" we can
use in all the places where skb_get_rxhash() gets called.
Part of the problem is that we call it from strange places, such as
egress packet schedulers. That's completely bogus.
Examples, FLOW classifier, META e-match, CHOKE, and SFB.
In fact, for the classifiers this means they aren't making use of the
precomputed TX hash values in the sockets like __skb_tx_hash() will
make use of. So this makes these packet schedulers operate
potentially more expensively than they need to.
If we could get rid of those silly cases, the stuff that remains
(macvtap and net/core/dev.c) could work with a NAPI context during
rxhash computation and use that to store the IP fragmentation
on-behind cached information.
^ permalink raw reply
* Re: linux-next: Tree for May 24 (ratelimits, CONFIG_PRINTK not enabled)
From: Randy Dunlap @ 2011-05-24 20:11 UTC (permalink / raw)
To: David Miller; +Cc: joe, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <20110524.155337.1293466135362760665.davem@davemloft.net>
On 05/24/11 12:53, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Tue, 24 May 2011 12:49:40 -0700
>
>> On Tue, 2011-05-24 at 15:32 -0400, David Miller wrote:
>>> From: Joe Perches <joe@perches.com>
>>> Date: Tue, 24 May 2011 11:49:48 -0700
>>>> On Tue, 2011-05-24 at 11:33 -0700, Randy Dunlap wrote:
>>>>> Adding <linux/ratelimit.h> to <asm-generic/bug.h> causes other problems:
>>>> Yup, that's not a good solution.
>>> Please come up with a fix or I'll have to revert, thanks Joe.
>>
>> I have some errands to run for awhile.
>>
>> Probably a revert today and another patch set tomorrow
>> might be best.
>>
>> This seems to work and doesn't cause any extra state to be
>> instantiated when !CONFIG_PRINTK. What do you think?
>
> Seems fine, here it is as a patch.
>
> Randy please test this, thanks:
Works here.
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks.
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 12b250c..9178484 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -162,6 +162,8 @@ extern void warn_slowpath_null(const char *file, const int line);
> unlikely(__ret_warn_once); \
> })
>
> +#ifdef CONFIG_PRINTK
> +
> #define WARN_ON_RATELIMIT(condition, state) \
> WARN_ON((condition) && __ratelimit(state))
>
> @@ -181,6 +183,25 @@ extern void warn_slowpath_null(const char *file, const int line);
> __WARN_RATELIMIT(condition, &_rs, format); \
> })
>
> +#else
> +
> +#define WARN_ON_RATELIMIT(condition, state) \
> + WARN_ON(condition)
> +
> +#define __WARN_RATELIMIT(condition, state, format...) \
> +({ \
> + int rtn = WARN(condition, format); \
> + rtn; \
> +})
> +
> +#define WARN_RATELIMIT(condition, format...) \
> +({ \
> + int rtn = WARN(condition, format); \
> + rtn; \
> +})
> +
> +#endif
> +
> /*
> * WARN_ON_SMP() is for cases that the warning is either
> * meaningless for !SMP or may even cause failures.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Nicolas de Pesloüan @ 2011-05-24 20:13 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Neil Horman, netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <20110524200047.GI21309@gospo.rdu.redhat.com>
Le 24/05/2011 22:00, Andy Gospodarek a écrit :
> On Tue, May 24, 2011 at 03:36:05PM -0400, Neil Horman wrote:
>> This soft lockup was recently reported:
>>
>> [root@dell-per715-01 ~]# echo +bond5> /sys/class/net/bonding_masters
>> [root@dell-per715-01 ~]# echo +eth1> /sys/class/net/bond5/bonding/slaves
>> bonding: bond5: doing slave updates when interface is down.
>> bonding bond5: master_dev is not up in bond_enslave
>> [root@dell-per715-01 ~]# echo -eth1> /sys/class/net/bond5/bonding/slaves
>> bonding: bond5: doing slave updates when interface is down.
>>
>> BUG: soft lockup - CPU#12 stuck for 60s! [bash:6444]
>> CPU 12:
>> Modules linked in: bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
>> be2d
>> Pid: 6444, comm: bash Not tainted 2.6.18-262.el5 #1
>> RIP: 0010:[<ffffffff80064bf0>] [<ffffffff80064bf0>]
>> .text.lock.spinlock+0x26/00
>> RSP: 0018:ffff810113167da8 EFLAGS: 00000286
>> RAX: ffff810113167fd8 RBX: ffff810123a47800 RCX: 0000000000ff1025
>> RDX: 0000000000000000 RSI: ffff810123a47800 RDI: ffff81021b57f6f8
>> RBP: ffff81021b57f500 R08: 0000000000000000 R09: 000000000000000c
>> R10: 00000000ffffffff R11: ffff81011d41c000 R12: ffff81021b57f000
>> R13: 0000000000000000 R14: 0000000000000282 R15: 0000000000000282
>> FS: 00002b3b41ef3f50(0000) GS:ffff810123b27940(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00002b3b456dd000 CR3: 000000031fc60000 CR4: 00000000000006e0
>>
>> Call Trace:
>> [<ffffffff80064af9>] _spin_lock_bh+0x9/0x14
>> [<ffffffff886937d7>] :bonding:tlb_clear_slave+0x22/0xa1
>> [<ffffffff8869423c>] :bonding:bond_alb_deinit_slave+0xba/0xf0
>> [<ffffffff8868dda6>] :bonding:bond_release+0x1b4/0x450
>> [<ffffffff8006457b>] __down_write_nested+0x12/0x92
>> [<ffffffff88696ae4>] :bonding:bonding_store_slaves+0x25c/0x2f7
>> [<ffffffff801106f7>] sysfs_write_file+0xb9/0xe8
>> [<ffffffff80016b87>] vfs_write+0xce/0x174
>> [<ffffffff80017450>] sys_write+0x45/0x6e
>> [<ffffffff8005d28d>] tracesys+0xd5/0xe0
>>
>> It occurs because we are able to change the slave configuarion of a bond while
>> the bond interface is down. The bonding driver initializes some data structures
>> only after its ndo_open routine is called. Among them is the initalization of
>> the alb tx and rx hash locks. So if we add or remove a slave without first
>> opening the bond master device, we run the risk of trying to lock/unlock a
>> spinlock that has garbage for data in it, which results in our above softlock.
>>
>> We could fix it by moving the spin lock initalization to the device creation
>> path, but it seems that since we're warning people about not doing this, we
>> should probably just disallow them from doing it, so fix it by adding an EINVAL
>> return if we're not up yet. Tested by the reporter and confirmed to fix the
>> problem.
>>
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>
> Signed-off-by: Andy Gospodarek<andy@greyhouse.net>
>
>> Reported-by: jtluka@redhat.com
>> CC: Jay Vosburgh<fubar@us.ibm.com>
>> CC: Andy Gospodarek<andy@greyhouse.net>
>> CC: "David S. Miller"<daevm@davemloft.net>
>> ---
>> drivers/net/bonding/bond_sysfs.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
>> index 4059bfc..206c543 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -231,6 +231,7 @@ static ssize_t bonding_store_slaves(struct device *d,
>> if (!(bond->dev->flags& IFF_UP)) {
>> pr_warning("%s: doing slave updates when interface is down.\n",
>> bond->dev->name);
>> + return -EINVAL;
This will turn a warning into an error.
This warning existed for long, but never caused the bonding setup to fail. This patch cause some
regression for user space. For example, current ifenslave-2.6 package in Debian doesn't ensure bond
is UP before enslaving, because this was never required.
NAK.
>> }
>>
>> if (!rtnl_trylock())
>> --
>> 1.7.5.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: linux-next: Tree for May 24 (ratelimits, CONFIG_PRINTK not enabled)
From: David Miller @ 2011-05-24 20:14 UTC (permalink / raw)
To: randy.dunlap; +Cc: joe, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <4DDC1107.4050004@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Tue, 24 May 2011 13:11:51 -0700
> On 05/24/11 12:53, David Miller wrote:
>> From: Joe Perches <joe@perches.com>
>> Date: Tue, 24 May 2011 12:49:40 -0700
>>
>>> On Tue, 2011-05-24 at 15:32 -0400, David Miller wrote:
>>>> From: Joe Perches <joe@perches.com>
>>>> Date: Tue, 24 May 2011 11:49:48 -0700
>>>>> On Tue, 2011-05-24 at 11:33 -0700, Randy Dunlap wrote:
>>>>>> Adding <linux/ratelimit.h> to <asm-generic/bug.h> causes other problems:
>>>>> Yup, that's not a good solution.
>>>> Please come up with a fix or I'll have to revert, thanks Joe.
>>>
>>> I have some errands to run for awhile.
>>>
>>> Probably a revert today and another patch set tomorrow
>>> might be best.
>>>
>>> This seems to work and doesn't cause any extra state to be
>>> instantiated when !CONFIG_PRINTK. What do you think?
>>
>> Seems fine, here it is as a patch.
>>
>> Randy please test this, thanks:
>
> Works here.
>
> Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
Thanks Randy, once my allmodconfig+!CONFIG_PRINTK build finishes
I'll push this out.
^ permalink raw reply
* Re: [PATCH] net: Abstract features usage.
From: Mahesh Bandewar @ 2011-05-24 20:29 UTC (permalink / raw)
To: Michał Mirosław; +Cc: David Miller, netdev, Tom Herbert
In-Reply-To: <BANLkTinTJuKFyf80As81ouePBs=vFvQahg@mail.gmail.com>
On Tue, May 24, 2011 at 12:37 PM, Michał Mirosław <mirqus@gmail.com> wrote:
>
> 2011/5/24 Mahesh Bandewar <maheshb@google.com>:
> > Define macros to set/clear/test bits for feature set usage. This will eliminate
> > the direct use of these fields and enable future ease in managing these fields.
> >
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> > ---
> > include/linux/netdev_features.h | 137 +++++++++++++++++++++++++++++++++++++++
> > include/linux/netdevice.h | 35 ++---------
> > 2 files changed, 142 insertions(+), 30 deletions(-)
> > create mode 100644 include/linux/netdev_features.h
> >
> > diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> > new file mode 100644
> > index 0000000..97bf8c4
> > --- /dev/null
> > +++ b/include/linux/netdev_features.h
> > @@ -0,0 +1,137 @@
> > +#ifndef _NETDEV_FEATURES_H
> > +#define _NETDEV_FEATURES_H
> > +
> > +/* Forward declarations */
> > +struct net_device;
> > +
> > +typedef unsigned long *nd_feature_t;
> > +
> > +/* Net device feature bits; if you change something,
> > + * also update netdev_features_strings[] in ethtool.c */
> > +enum netdev_features {
> > + SG_BIT, /* Scatter/gather IO. */
> [...]
>
> Please split this change (introducing enum + converting NETIF_F_*
> defines to use it). This part is a nice cleanup, but I think the
> bitmap idea is still not worth the trouble until u64 runs out.
>
What will we achieve by this split? May be I'm not getting your point
about split. Do you want to see the cleanup part as a separate patch?
These enums and NETIF_F_* values have to be in sync. The macros that I
have defined are expecting this bit numbers rather than the flag
value.
Whether it is u64 or bitmap, the changes should be limited to this
file. Going forward that can be achieved by
simply changing few lines in these macros / inlines.
Thanks,
--mahesh..
> Best Regards,
> Michał Mirosław
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Neil Horman @ 2011-05-24 20:37 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Andy Gospodarek, netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <4DDC116F.8020602@gmail.com>
On Tue, May 24, 2011 at 10:13:35PM +0200, Nicolas de Pesloüan wrote:
> Le 24/05/2011 22:00, Andy Gospodarek a écrit :
> >On Tue, May 24, 2011 at 03:36:05PM -0400, Neil Horman wrote:
> >>This soft lockup was recently reported:
> >>
> >>[root@dell-per715-01 ~]# echo +bond5> /sys/class/net/bonding_masters
> >>[root@dell-per715-01 ~]# echo +eth1> /sys/class/net/bond5/bonding/slaves
> >>bonding: bond5: doing slave updates when interface is down.
> >>bonding bond5: master_dev is not up in bond_enslave
> >>[root@dell-per715-01 ~]# echo -eth1> /sys/class/net/bond5/bonding/slaves
> >>bonding: bond5: doing slave updates when interface is down.
> >>
> >>BUG: soft lockup - CPU#12 stuck for 60s! [bash:6444]
> >>CPU 12:
> >>Modules linked in: bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc
> >>be2d
> >>Pid: 6444, comm: bash Not tainted 2.6.18-262.el5 #1
> >>RIP: 0010:[<ffffffff80064bf0>] [<ffffffff80064bf0>]
> >>.text.lock.spinlock+0x26/00
> >>RSP: 0018:ffff810113167da8 EFLAGS: 00000286
> >>RAX: ffff810113167fd8 RBX: ffff810123a47800 RCX: 0000000000ff1025
> >>RDX: 0000000000000000 RSI: ffff810123a47800 RDI: ffff81021b57f6f8
> >>RBP: ffff81021b57f500 R08: 0000000000000000 R09: 000000000000000c
> >>R10: 00000000ffffffff R11: ffff81011d41c000 R12: ffff81021b57f000
> >>R13: 0000000000000000 R14: 0000000000000282 R15: 0000000000000282
> >>FS: 00002b3b41ef3f50(0000) GS:ffff810123b27940(0000) knlGS:0000000000000000
> >>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> >>CR2: 00002b3b456dd000 CR3: 000000031fc60000 CR4: 00000000000006e0
> >>
> >>Call Trace:
> >> [<ffffffff80064af9>] _spin_lock_bh+0x9/0x14
> >> [<ffffffff886937d7>] :bonding:tlb_clear_slave+0x22/0xa1
> >> [<ffffffff8869423c>] :bonding:bond_alb_deinit_slave+0xba/0xf0
> >> [<ffffffff8868dda6>] :bonding:bond_release+0x1b4/0x450
> >> [<ffffffff8006457b>] __down_write_nested+0x12/0x92
> >> [<ffffffff88696ae4>] :bonding:bonding_store_slaves+0x25c/0x2f7
> >> [<ffffffff801106f7>] sysfs_write_file+0xb9/0xe8
> >> [<ffffffff80016b87>] vfs_write+0xce/0x174
> >> [<ffffffff80017450>] sys_write+0x45/0x6e
> >> [<ffffffff8005d28d>] tracesys+0xd5/0xe0
> >>
> >>It occurs because we are able to change the slave configuarion of a bond while
> >>the bond interface is down. The bonding driver initializes some data structures
> >>only after its ndo_open routine is called. Among them is the initalization of
> >>the alb tx and rx hash locks. So if we add or remove a slave without first
> >>opening the bond master device, we run the risk of trying to lock/unlock a
> >>spinlock that has garbage for data in it, which results in our above softlock.
> >>
> >>We could fix it by moving the spin lock initalization to the device creation
> >>path, but it seems that since we're warning people about not doing this, we
> >>should probably just disallow them from doing it, so fix it by adding an EINVAL
> >>return if we're not up yet. Tested by the reporter and confirmed to fix the
> >>problem.
> >>
> >>Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
> >
> >Signed-off-by: Andy Gospodarek<andy@greyhouse.net>
> >
> >>Reported-by: jtluka@redhat.com
> >>CC: Jay Vosburgh<fubar@us.ibm.com>
> >>CC: Andy Gospodarek<andy@greyhouse.net>
> >>CC: "David S. Miller"<daevm@davemloft.net>
> >>---
> >> drivers/net/bonding/bond_sysfs.c | 1 +
> >> 1 files changed, 1 insertions(+), 0 deletions(-)
> >>
> >>diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
> >>index 4059bfc..206c543 100644
> >>--- a/drivers/net/bonding/bond_sysfs.c
> >>+++ b/drivers/net/bonding/bond_sysfs.c
> >>@@ -231,6 +231,7 @@ static ssize_t bonding_store_slaves(struct device *d,
> >> if (!(bond->dev->flags& IFF_UP)) {
> >> pr_warning("%s: doing slave updates when interface is down.\n",
> >> bond->dev->name);
> >>+ return -EINVAL;
>
> This will turn a warning into an error.
>
Yes, because it should have been an error all along.
> This warning existed for long, but never caused the bonding setup to
> fail. This patch cause some regression for user space. For example,
> current ifenslave-2.6 package in Debian doesn't ensure bond is UP
> before enslaving, because this was never required.
>
Thats not a regression, thats the kernel returning an error where it should have
done so all along. Just because a utility got away with it for awhile and it
didn't always cause a lockup, doesn't grandfather that application in to a
situation where the kernel has to support its broken behavior in perpituity.
Besides, iirc, the ifsenslave utility still uses the ioctl path, which this
patch doesn't touch, so ifenslave is currently unaffected (although I should
look in the ioctl path to see if we have already added such a check, lest you be
able to deadlock your system as previously indicated using that tool).
Neil
^ permalink raw reply
* [ANNOUNCE] IPTV-Analyzer project released v0.9.1
From: Jesper Dangaard Brouer @ 2011-05-24 20:40 UTC (permalink / raw)
To: hawk
The new release 0.9.1 of the IPTV-Analyzer project is comming to you
directly from New York City RedHat office ;-)
New features include bytes and packet counters, no-signal detection,
heartbeat system per stream, and new event types.
Homepage:
http://www.iptv-analyzer.org
Git tree:
https://github.com/netoptimizer/IPTV-Analyzer
Notice, database changes in this release. Its possible to upgrade
the database schema without loosing your current data.
The IPTV-Analyzer is a continuous/real-time tool for analyzing the
contents of MPEG2 Transport Stream (TS) packets, which is commonly
used for IPTV multicast signals. The main purpose is continuous
quality measurement, with a focus on detecting MPEG2 TS/CC packet
drops.
Bugreports and feature requests please use:
https://github.com/netoptimizer/IPTV-Analyzer/issues
(Disclaimer, RedHat is not directly associated with project, I just
hangout with them during my visit to NYC).
--
Best regards,
Jesper Dangaard Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Nicolas de Pesloüan @ 2011-05-24 20:51 UTC (permalink / raw)
To: Neil Horman; +Cc: Andy Gospodarek, netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <20110524203714.GG28521@hmsreliant.think-freely.org>
Le 24/05/2011 22:37, Neil Horman a écrit :
>>>> + return -EINVAL;
>>
>> This will turn a warning into an error.
>>
> Yes, because it should have been an error all along.
>
>> This warning existed for long, but never caused the bonding setup to
>> fail. This patch cause some regression for user space. For example,
>> current ifenslave-2.6 package in Debian doesn't ensure bond is UP
>> before enslaving, because this was never required.
>>
> Thats not a regression, thats the kernel returning an error where it should have
> done so all along. Just because a utility got away with it for awhile and it
> didn't always cause a lockup, doesn't grandfather that application in to a
> situation where the kernel has to support its broken behavior in perpituity.
>
> Besides, iirc, the ifsenslave utility still uses the ioctl path, which this
> patch doesn't touch, so ifenslave is currently unaffected (although I should
> look in the ioctl path to see if we have already added such a check, lest you be
> able to deadlock your system as previously indicated using that tool).
Unfortunately, no. Recent versions of ifenslave-2.6 on Debian don't use ioctl (ifenslave binary)
anymore, but only sysfs.
Documentation/bonding.txt should be updated to reflect this change.
pr_warning should be changed to pr_ err.
Bonding version should be bumped.
Anyway, I will fix this package, but I suspect there exist many user scripts that don't ensure bond
is up before enslaving.
Nicolas.
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Nicolas de Pesloüan @ 2011-05-24 21:02 UTC (permalink / raw)
To: Neil Horman; +Cc: Andy Gospodarek, netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <4DDC1A4E.6080700@gmail.com>
Le 24/05/2011 22:51, Nicolas de Pesloüan a écrit :
> Le 24/05/2011 22:37, Neil Horman a écrit :
>
>>>>> + return -EINVAL;
>>>
>>> This will turn a warning into an error.
>>>
>> Yes, because it should have been an error all along.
>>
>>> This warning existed for long, but never caused the bonding setup to
>>> fail. This patch cause some regression for user space. For example,
>>> current ifenslave-2.6 package in Debian doesn't ensure bond is UP
>>> before enslaving, because this was never required.
>>>
>> Thats not a regression, thats the kernel returning an error where it should have
>> done so all along. Just because a utility got away with it for awhile and it
>> didn't always cause a lockup, doesn't grandfather that application in to a
>> situation where the kernel has to support its broken behavior in perpituity.
>>
>> Besides, iirc, the ifsenslave utility still uses the ioctl path, which this
>> patch doesn't touch, so ifenslave is currently unaffected (although I should
>> look in the ioctl path to see if we have already added such a check, lest you be
>> able to deadlock your system as previously indicated using that tool).
>
> Unfortunately, no. Recent versions of ifenslave-2.6 on Debian don't use ioctl (ifenslave binary)
> anymore, but only sysfs.
>
> Documentation/bonding.txt should be updated to reflect this change.
> pr_warning should be changed to pr_ err.
> Bonding version should be bumped.
>
> Anyway, I will fix this package, but I suspect there exist many user scripts that don't ensure bond
> is up before enslaving.
Well, still thinking about it...
On Ubuntu, due to the usage of upstart, the slaves are ifup before the master. On Debian, this is
also true for hotplug slaves. I wonder whether this patch may cause troubles, because the master
will have to be up before calling ifup for it.
Nicolas.
^ permalink raw reply
* pull request: wireless-next-2.6 2011-05-24
From: John W. Linville @ 2011-05-24 21:04 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is the last (belated) batch of new wireless bits intended for
2.6.40. I had intended to send this over the weekend, but there was
a dust-up over some merge confusion that had to get settled first.
In the meantime, this got a few more days to cook in -next. :-)
There isn't anything Earth-shattering here -- mostly just some
last-minute bits posted a bit before the release. Some of them are
fixes for bugs in other new code. There is also the addition of a
generic GPIO-based rfkill driver.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 557eed603159b4e007c57d97fad1333ecebd3c2e:
Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev (2011-05-20 14:31:27 -0700)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git for-davem
Alexey Dobriyan (1):
airo: correct proc entry creation interfaces
Christian Lamparter (2):
p54usb: add zoom 4410 usbid
carl9170: advertise interface combinations
Daniel Halperin (1):
iwlwifi: remove unused parameter from iwl_hcmd_queue_reclaim
Felix Fietkau (3):
ath9k: fix ad-hoc mode beacon selection
ath9k: fix ad-hoc nexttbtt calculation
ath9k: implement .tx_last_beacon()
Javier Cardona (2):
mac80211: Deactivate mesh path timers when freeing nodes
mac80211: Don't sleep when growing the mesh path
Johannes Berg (10):
iwlagn: prepare for multi-TB commands
iwlagn: clean up TXQ indirection
iwlagn: remove unused pad argument
iwlagn: support multiple TBs per command
iwlagn: remove set but unused vars
iwlagn: change default beacon interval
mac80211: verify IBSS in interface combinations
mac80211: add missing rcu_barrier
mac80211: fix and simplify mesh locking
mac80211: annotate and fix RCU in mesh code
John W. Linville (2):
Merge branch 'wireless-next-2.6' of git://git.kernel.org/.../iwlwifi/iwlwifi-2.6
Merge ssh://master.kernel.org/.../linville/wireless-next-2.6 into for-davem
Jouni Malinen (1):
cfg80211: Use consistent BSS matching between scan and sme
Larry Finger (1):
rtlwifi: rtl8192c-common: rtl8192ce: Fix for HT40 regression
Luciano Coelho (1):
nl80211: remove some stack variables in trigger_scan and start_sched_scan
Marc Yang (5):
mwifiex: reduce CPU usage by tracking tx_pkts_queued
mwifiex: reduce CPU usage by tracking highest_queued_prio
mwifiex: check mwifiex_wmm_lists_empty() before dequeue
mwifiex: CPU mips optimization with NO_PKT_PRIO_TID
mwifiex: adjust high/low water marks for tx_pending queue
Mohammed Shafi Shajakhan (2):
ath_hw: Fix bssid mask documentation
ath9k: use PS wakeup before REG_READ
Rafał Miłecki (8):
b43: rename b43_wldev's field with ssb_device to sdev
bcma: add PCI ID of the card found in Thinkpad X120e
b43: add helpers for block R/W ops
b43: make b43_wireless_init less bus specific
b43: dma: cache translation (routing bits)
b43: add helper for finding GPIO device
b43: separate ssb core reset
b43: read PHY info only when needed (for PHY-A)
Rajkumar Manoharan (2):
mac80211: abort scan_work immediately when the device goes down
ath9k: Fix power save wrappers in debug ops
Randy Dunlap (2):
wireless: fix cfg80211.h new kernel-doc warnings
wireless: fix fatal kernel-doc error + warning in mac80211.h
Rhyland Klein (1):
net: rfkill: add generic gpio rfkill driver
Sujith Manoharan (9):
ath9k_htc: Fix mode selection
ath9k_htc: Fix station flags
ath9k_htc: Recalculate the BSSID mask on interface
ath9k_htc: Fix RX filter calculation
ath9k_htc: Fix BSSID calculation
ath9k_htc: Fix max subframe handling
ath9k_htc: Change credit limit for UB94/95
ath9k_htc: Fix packet timeout
ath9k: Drag the driver to the year 2011
Wey-Yi Guy (8):
iwlagn: more ucode error log info
iwlagn: add testmode trace command
iwlagn: add eeprom command to testmode
iwlagn: add testmode set fixed rate command
iwlagn: clear STATUS_HCMD_ACTIVE bit if fail enqueue
iwlagn: alwasy send RXON with disassociate falge before associate
iwlagn: remove unused old_assoc parameter
iwlagn: dbg_fixed_rate only used when CONFIG_MAC80211_DEBUGFS enabled
drivers/bcma/host_pci.c | 1 +
drivers/net/wireless/airo.c | 33 +--
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/ani.c | 2 +-
drivers/net/wireless/ath/ath9k/ani.h | 2 +-
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9001_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_hw.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_mac.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 2 +-
.../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 16 +
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_mac.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9485_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 5 +-
drivers/net/wireless/ath/ath9k/beacon.c | 48 ++-
drivers/net/wireless/ath/ath9k/btcoex.c | 2 +-
drivers/net/wireless/ath/ath9k/btcoex.h | 2 +-
drivers/net/wireless/ath/ath9k/calib.c | 2 +-
drivers/net/wireless/ath/ath9k/calib.h | 2 +-
drivers/net/wireless/ath/ath9k/common.c | 2 +-
drivers/net/wireless/ath/ath9k/common.h | 2 +-
drivers/net/wireless/ath/ath9k/debug.c | 10 +-
drivers/net/wireless/ath/ath9k/debug.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_4k.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 2 +-
drivers/net/wireless/ath/ath9k/gpio.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.h | 4 +-
drivers/net/wireless/ath/ath9k/htc.h | 25 +-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_gpio.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 9 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 79 +++--
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 6 +-
drivers/net/wireless/ath/ath9k/htc_hst.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_hst.h | 2 +-
drivers/net/wireless/ath/ath9k/hw-ops.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/ath9k/mac.c | 2 +-
drivers/net/wireless/ath/ath9k/mac.h | 2 +-
drivers/net/wireless/ath/ath9k/main.c | 42 +++-
drivers/net/wireless/ath/ath9k/pci.c | 2 +-
drivers/net/wireless/ath/ath9k/phy.h | 2 +-
drivers/net/wireless/ath/ath9k/rc.c | 2 +-
drivers/net/wireless/ath/ath9k/rc.h | 2 +-
drivers/net/wireless/ath/ath9k/recv.c | 2 +-
drivers/net/wireless/ath/ath9k/reg.h | 2 +-
drivers/net/wireless/ath/ath9k/wmi.c | 2 +-
drivers/net/wireless/ath/ath9k/wmi.h | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
drivers/net/wireless/ath/carl9170/carl9170.h | 4 +
drivers/net/wireless/ath/carl9170/fw.c | 19 +-
drivers/net/wireless/ath/carl9170/main.c | 10 +-
drivers/net/wireless/ath/hw.c | 10 +-
drivers/net/wireless/b43/b43.h | 24 +-
drivers/net/wireless/b43/dma.c | 37 +-
drivers/net/wireless/b43/leds.c | 4 +-
drivers/net/wireless/b43/lo.c | 4 +-
drivers/net/wireless/b43/main.c | 194 ++++++-----
drivers/net/wireless/b43/phy_a.c | 16 +-
drivers/net/wireless/b43/phy_common.c | 8 +-
drivers/net/wireless/b43/phy_g.c | 48 ++--
drivers/net/wireless/b43/phy_lp.c | 22 +-
drivers/net/wireless/b43/phy_n.c | 24 +-
drivers/net/wireless/b43/pio.c | 30 +-
drivers/net/wireless/b43/rfkill.c | 6 +-
drivers/net/wireless/b43/sdio.c | 4 +-
drivers/net/wireless/b43/sysfs.c | 4 +-
drivers/net/wireless/b43/tables_lpphy.c | 4 +-
drivers/net/wireless/b43/wa.c | 4 +-
drivers/net/wireless/b43/xmit.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 4 -
drivers/net/wireless/iwlwifi/iwl-2000.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 14 +-
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 14 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 86 +++--
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-agn-ucode.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 250 +++-----------
drivers/net/wireless/iwlwifi/iwl-agn.h | 13 +-
drivers/net/wireless/iwlwifi/iwl-commands.h | 5 +-
drivers/net/wireless/iwlwifi/iwl-core.h | 10 -
drivers/net/wireless/iwlwifi/iwl-dev.h | 66 +++--
drivers/net/wireless/iwlwifi/iwl-devtrace.h | 58 +++-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 7 +-
drivers/net/wireless/iwlwifi/iwl-hcmd.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-led.c | 4 +-
drivers/net/wireless/iwlwifi/iwl-sta.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-sv-open.c | 177 ++++++++++-
drivers/net/wireless/iwlwifi/iwl-testmode.h | 34 ++
drivers/net/wireless/iwlwifi/iwl-tx.c | 364 ++++++++++++++------
drivers/net/wireless/iwmc3200wifi/rx.c | 4 +-
drivers/net/wireless/mwifiex/11n_aggr.c | 4 +
drivers/net/wireless/mwifiex/main.h | 9 +-
drivers/net/wireless/mwifiex/txrx.c | 4 +-
drivers/net/wireless/mwifiex/wmm.c | 59 +++-
drivers/net/wireless/p54/p54usb.c | 1 +
drivers/net/wireless/rndis_wlan.c | 3 +-
drivers/net/wireless/rtlwifi/ps.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192ce/phy.c | 69 ++++
drivers/net/wireless/rtlwifi/rtl8192ce/phy.h | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/sw.c | 1 +
drivers/staging/ath6kl/os/linux/cfg80211.c | 2 +-
drivers/staging/brcm80211/brcmfmac/wl_cfg80211.c | 4 +-
drivers/staging/wlan-ng/cfg80211.c | 2 +-
fs/proc/generic.c | 1 +
include/linux/rfkill-gpio.h | 43 +++
include/net/cfg80211.h | 8 +-
include/net/mac80211.h | 3 +-
net/mac80211/iface.c | 4 +-
net/mac80211/main.c | 22 +-
net/mac80211/mesh.h | 7 +-
net/mac80211/mesh_pathtbl.c | 204 +++++++----
net/mac80211/scan.c | 5 +
net/rfkill/Kconfig | 9 +
net/rfkill/Makefile | 1 +
net/rfkill/rfkill-gpio.c | 227 ++++++++++++
net/wireless/core.h | 5 +-
net/wireless/nl80211.c | 12 +-
net/wireless/sme.c | 19 +-
net/wireless/util.c | 2 +-
143 files changed, 1822 insertions(+), 977 deletions(-)
create mode 100644 include/linux/rfkill-gpio.h
create mode 100644 net/rfkill/rfkill-gpio.c
Omnibus patch available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6-2011-05-24.patch.bz2
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Jay Vosburgh @ 2011-05-24 21:12 UTC (permalink / raw)
To: =?ISO-8859-1?Q?Nicolas_de_Peslo=FCan?=
Cc: Neil Horman, Andy Gospodarek, netdev, David S. Miller
In-Reply-To: <4DDC1A4E.6080700@gmail.com>
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
>Le 24/05/2011 22:37, Neil Horman a écrit :
>
>>>>> + return -EINVAL;
>>>
>>> This will turn a warning into an error.
>>>
>> Yes, because it should have been an error all along.
>>
>>> This warning existed for long, but never caused the bonding setup to
>>> fail. This patch cause some regression for user space. For example,
>>> current ifenslave-2.6 package in Debian doesn't ensure bond is UP
>>> before enslaving, because this was never required.
>>>
>> Thats not a regression, thats the kernel returning an error where it should have
>> done so all along. Just because a utility got away with it for awhile and it
>> didn't always cause a lockup, doesn't grandfather that application in to a
>> situation where the kernel has to support its broken behavior in perpituity.
>>
>> Besides, iirc, the ifsenslave utility still uses the ioctl path, which this
>> patch doesn't touch, so ifenslave is currently unaffected (although I should
>> look in the ioctl path to see if we have already added such a check, lest you be
>> able to deadlock your system as previously indicated using that tool).
>
>Unfortunately, no. Recent versions of ifenslave-2.6 on Debian don't use
>ioctl (ifenslave binary) anymore, but only sysfs.
>
>Documentation/bonding.txt should be updated to reflect this change.
>pr_warning should be changed to pr_ err.
>Bonding version should be bumped.
>
>Anyway, I will fix this package, but I suspect there exist many user
>scripts that don't ensure bond is up before enslaving.
I looked at sysconfig (as supplied with opensuse) and it uses
sysfs, and does set the master device up first. The other potential
user that comes to mind is that OFED at one point had a script to set up
bonding for Infiniband devices. I don't know if this is still the case,
nor do I know if it set the bond device up before enslaving.
Generally speaking, though, in the long run I think it should be
permissible to change any bonding option when the bond is down (even to
values that make no sense in context, e.g., setting the primary to a
device not currently enslaved). My rationale here is that some options
are very difficult to modify when the bond is up (e.g., changing the
mode), and now some other set is precluded when the bond is down. The
init scripts already have repeat logic in them; this just makes things
more complicated.
There should be a state wherein any option can be changed (well,
maybe not max_bonds), and that should be the down state. A subset can
also be changed while up. I'd be happy to be able to change all options
while the bond is up, too, but that seems pretty hard to do.
How much harder is it to fix the locking and permit the action
in question here?
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: David Miller @ 2011-05-24 21:14 UTC (permalink / raw)
To: fubar; +Cc: nicolas.2p.debian, nhorman, andy, netdev
In-Reply-To: <12577.1306271574@death>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Tue, 24 May 2011 14:12:54 -0700
> How much harder is it to fix the locking and permit the action
> in question here?
I've reverted and am holding off on this patch until this discussion
is resolved.
^ permalink raw reply
* Setting shutdownspeed in r8169 driver
From: Bas Nedermeijer @ 2011-05-24 21:02 UTC (permalink / raw)
To: netdev
Hello,
I currently have an onboard nic, which allows me to use wake-on-lan. But link-
speed goes to 10MBit when the system is shutdown. This causes a multicast/IPTV
stream to be throttled back to 10Mbit. This is probably because the multicast
stream actually a broadcast on my local network. I think some device is
sending ethernet-pause frames (havent seem them, but not sure if they show up
in tcpdump). I tried to disable flow-control on the sending device, but that
didnt help, still the traffic is throttled when it has passed some switches. I
read somewhere the windows driver has an option to specify the shutdown-
linkspeed, so listening for WOL happens on 100mbit. I was wondering if it is
possible at all with the linux-driver (maybe as default by modifying the
driver locally as I cant seem to find a userspace program to modify the
settings).
I am using the driver "r8169"
According to 'lspci':
Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
controller (rev 02)
Best regards,
Bas Nedermeijer
^ permalink raw reply
* Re: [PATCH 0/9] strict user copy checks on x86_64
From: Stephen Boyd @ 2011-05-24 21:29 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linux-wireless, netdev, Intel Linux Wireless,
linux-scsi, x86, Ingo Molnar
In-Reply-To: <1305244212-19183-1-git-send-email-sboyd@codeaurora.org>
Hi Andrew,
(I don't know who to pick on sorry)
On 05/12/2011 04:50 PM, Stephen Boyd wrote:
> It turns out that strict user copy checks (also known as
> CONFIG_DEBUG_STRICT_USER_COPY_CHECKS) isn't actually implemented
> on x86_64 and thus we aren't catching potential security holes
> at compile time.
>
> This series adds support for strict user copy checks on x86_64
> and silences all the benign warnings in the x86_64 allyesconfig.
>
> The final patch consolidates the config option as its duplicated
> across mutliple arches. I don't know what tree this series should
> go through so I tried to send the individual driver patches to the
> respective maintainers.
>
> Stephen Boyd (9):
> iwlegacy: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> iwlwifi: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> [SCSI] lpfc: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> debugfs: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> kprobes: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> Bluetooth: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> ASoC: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
> x86: Implement strict user copy checks for x86_64
> Consolidate CONFIG_DEBUG_STRICT_USER_COPY_CHECKS
It looks like 1, 2, 4, 6, and 7 got picked up. Should I resend the left
over patches with appropriate acked-bys and tags? Would it be
appropriate to push this through your tree?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH] net: Abstract features usage.
From: Stephen Hemminger @ 2011-05-24 21:29 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: David Miller, netdev, Tom Herbert
In-Reply-To: <1306263162-2022-1-git-send-email-maheshb@google.com>
On Tue, 24 May 2011 11:52:42 -0700
Mahesh Bandewar <maheshb@google.com> wrote:
> Define macros to set/clear/test bits for feature set usage. This will eliminate
> the direct use of these fields and enable future ease in managing these fields.
>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
> include/linux/netdev_features.h | 137 +++++++++++++++++++++++++++++++++++++++
> include/linux/netdevice.h | 35 ++---------
> 2 files changed, 142 insertions(+), 30 deletions(-)
> create mode 100644 include/linux/netdev_features.h
>
> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> new file mode 100644
> index 0000000..97bf8c4
> --- /dev/null
> +++ b/include/linux/netdev_features.h
> @@ -0,0 +1,137 @@
> +#ifndef _NETDEV_FEATURES_H
> +#define _NETDEV_FEATURES_H
> +
> +/* Forward declarations */
> +struct net_device;
> +
> +typedef unsigned long *nd_feature_t
typedef'ing a pointer is strongly discouraged by kernel coding style.
You need to use another way such as open coding it.
--
^ permalink raw reply
* Re: [PATCH] bonding: prevent deadlock on slave store with alb mode
From: Nicolas de Pesloüan @ 2011-05-24 21:32 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: Neil Horman, Andy Gospodarek, netdev, David S. Miller
In-Reply-To: <12577.1306271574@death>
Le 24/05/2011 23:12, Jay Vosburgh a écrit :
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
>
>> Le 24/05/2011 22:37, Neil Horman a écrit :
>>
>>>>>> + return -EINVAL;
>>>>
>>>> This will turn a warning into an error.
>>>>
>>> Yes, because it should have been an error all along.
>>>
>>>> This warning existed for long, but never caused the bonding setup to
>>>> fail. This patch cause some regression for user space. For example,
>>>> current ifenslave-2.6 package in Debian doesn't ensure bond is UP
>>>> before enslaving, because this was never required.
>>>>
>>> Thats not a regression, thats the kernel returning an error where it should have
>>> done so all along. Just because a utility got away with it for awhile and it
>>> didn't always cause a lockup, doesn't grandfather that application in to a
>>> situation where the kernel has to support its broken behavior in perpituity.
>>>
>>> Besides, iirc, the ifsenslave utility still uses the ioctl path, which this
>>> patch doesn't touch, so ifenslave is currently unaffected (although I should
>>> look in the ioctl path to see if we have already added such a check, lest you be
>>> able to deadlock your system as previously indicated using that tool).
>>
>> Unfortunately, no. Recent versions of ifenslave-2.6 on Debian don't use
>> ioctl (ifenslave binary) anymore, but only sysfs.
>>
>> Documentation/bonding.txt should be updated to reflect this change.
>> pr_warning should be changed to pr_ err.
>> Bonding version should be bumped.
>>
>> Anyway, I will fix this package, but I suspect there exist many user
>> scripts that don't ensure bond is up before enslaving.
>
> I looked at sysconfig (as supplied with opensuse) and it uses
> sysfs, and does set the master device up first. The other potential
> user that comes to mind is that OFED at one point had a script to set up
> bonding for Infiniband devices. I don't know if this is still the case,
> nor do I know if it set the bond device up before enslaving.
>
> Generally speaking, though, in the long run I think it should be
> permissible to change any bonding option when the bond is down (even to
> values that make no sense in context, e.g., setting the primary to a
> device not currently enslaved). My rationale here is that some options
> are very difficult to modify when the bond is up (e.g., changing the
> mode), and now some other set is precluded when the bond is down. The
> init scripts already have repeat logic in them; this just makes things
> more complicated.
>
> There should be a state wherein any option can be changed (well,
> maybe not max_bonds), and that should be the down state. A subset can
> also be changed while up. I'd be happy to be able to change all options
> while the bond is up, too, but that seems pretty hard to do.
>
> How much harder is it to fix the locking and permit the action
> in question here?
To add to the comment by Jay, here is an extract from the more up to date version of the script that
setup bonding on Debian (/etc/network/if-pre-up.d/ifenslave, from ifenslave-2.6 package):
# early_setup_master is the place where we do master setup that need to be done before enslavement.
early_setup_master()
{
# Warning: the order in wich we write into the sysfs files is important.
# Double check in drivers/net/bonding/bond_sysfs.c in linux kernel source tree
# before changing anything here.
# fail_over_mac must be set before enslavement of any slaves.
sysfs fail_over_mac "$IF_BOND_FAIL_OVER_MAC"
}
setup_master()
{
# Warning: the order in wich we write into the sysfs files is important.
# Double check in drivers/net/bonding/bond_sysfs.c in linux kernel source tree
# before changing anything here.
# use_carrier can be set anytime.
sysfs use_carrier "$IF_BOND_USE_CARRIER"
# num_grat_arp can be set anytime.
sysfs num_grat_arp "$IF_BOND_NUM_GRAT_ARP"
# num_unsol_na can be set anytime.
sysfs num_unsol_na "$IF_BOND_NUM_UNSOL_NA"
# xmit_hash_policy can be set anytime.
# Changing xmit_hash_policy requires $BOND_MASTER to be down.
sysfs_change_down xmit_hash_policy "$IF_BOND_XMIT_HASH_POLICY"
# arp_ip_target must be set before arp_interval.
sysfs_add arp_ip_target "$IF_BOND_ARP_IP_TARGET"
sysfs arp_interval "$IF_BOND_ARP_INTERVAL"
# miimon must be set before updelay and downdelay.
sysfs miimon "$IF_BOND_MIIMON"
sysfs downdelay "$IF_BOND_DOWNDELAY"
sysfs updelay "$IF_BOND_UPDELAY"
# Changing ad_select requires $BOND_MASTER to be down.
sysfs_change_down ad_select "$IF_BOND_AD_SELECT"
# Changing mode requires $BOND_MASTER to be down.
# Mode should be set after miimon or arp_interval, to avoid a warning in syslog.
sysfs_change_down mode "$IF_BOND_MODE"
# arp_validate must be after mode (because mode must be active-backup).
sysfs arp_validate "$IF_BOND_ARP_VALIDATE"
# lacp_rate must be set after mode (because mode must be 802.3ad).
# Changing lacp_rate requires $BOND_MASTER to be down.
sysfs_change_down lacp_rate "$IF_BOND_LACP_RATE"
# primary must be set after mode (because only supported in some modes) and after enslavement.
# The first slave in bond-primary found in current slaves becomes the primary.
# If no slave in bond-primary is found, then primary does not change.
for slave in $IF_BOND_PRIMARY ; do
if grep -sq "\\<$slave\\>" "/sys/class/net/$BOND_MASTER/bonding/slaves" ; then
sysfs primary "$slave"
break
fi
done
# primary_reselect should be set after mode (because only supported in some modes), after
enslavement
# and after primary. This is currently (2.6.35-rc1) not enforced by the bonding driver, but
it is
# probably safer to do it in that order.
sysfs primary_reselect "$IF_BOND_PRIMARY_RESELECT"
# queue_id must be set after enslavement.
for iface_queue_id in $IF_BOND_QUEUE_ID
do
sysfs iface_queue_id $iface_queue_id
done
# active_slave must be set after mode and after enslavement.
# The slave must be up and the underlying link must be up too.
# FIXME: We should have a way to write an empty string to active_slave, to set the
active_slave to none.
if [ "$IF_BOND_ACTIVE_SLAVE" ] ; then
# Need to force interface up before. Bonding will refuse to activate a down interface.
ip link set "$IF_BOND_ACTIVE_SLAVE" up
sysfs active_slave "$IF_BOND_ACTIVE_SLAVE"
fi
# Force $BOND_MASTER to be up, if we are called from a slave stanza.
[ "$IFACE" != "$BOND_MASTER" ] && ip link set dev "$BOND_MASTER" up
}
In order to fix some of the reported problems with some previous versions of this script, I had to
conduct a detailed code review of bond_sysfs.c and eventually end up with this current version,
where I documented all the constraints I discovered.
bonding sysfs currently enforce many constraints on the exact order of the setup. As noted by Jay,
some setup need to be done while the master if down, some while the master is up, some need to be
done before the first enslavement, some must be done after the referenced slave is enslaved, some
are only allowed if mode is properly set before, and so on...
I though for long about adding this into Documentation/networking/bonding.txt, but fail to find the
time to do so.
Arguably, it would be better to spend time to remove those constraints than to document them.
Nicolas.
^ permalink raw reply
* Re: Kernel crash after using new Intel NIC (igb)
From: Arun Sharma @ 2011-05-24 21:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arun Sharma, Maximilian Engelhardt, linux-kernel, netdev,
StuStaNet Vorstand
In-Reply-To: <1305234953.2831.2.camel@edumazet-laptop>
On Thu, May 12, 2011 at 11:15:53PM +0200, Eric Dumazet wrote:
>
> Probably not.
>
> What gives slub_nomerge=1 for you ?
>
It took me a while to get a new kernel on a large enough sample
of machines to get some data.
Like you observed in the other thread, this is unlikely to be a random
memory corruption.
The panics stopped after we moved the list_empty() check under the lock.
--- a/net/ipv4/inetpeer.c
+++ b/net/ipv4/inetpeer.c
@@ -154,11 +154,11 @@ void __init inet_initpeers(void)
/* Called with or without local BH being disabled. */
static void unlink_from_unused(struct inet_peer *p)
{
+ spin_lock_bh(&unused_peers.lock);
if (!list_empty(&p->unused)) {
- spin_lock_bh(&unused_peers.lock);
list_del_init(&p->unused);
- spin_unlock_bh(&unused_peers.lock);
}
+ spin_unlock_bh(&unused_peers.lock);
}
static int addr_compare(const struct inetpeer_addr *a,
The idea being that the list gets corrupted under some kind of a race
condition. Two threads racing on list_empty() and executing
list_del_init() seems harmless.
There is probably a different race condition that is mitigated by doing
the list_empty() check under the lock.
-Arun
^ permalink raw reply
* Re: small RPS cache for fragments?
From: Rick Jones @ 2011-05-24 21:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110524.160123.2051949867829317339.davem@davemloft.net>
On Tue, 2011-05-24 at 16:01 -0400, David Miller wrote:
> So I looked into implementing this now that it has been established
> that we changed even Linux to emit fragments in-order.
>
> The first problem we run into is that there is no "context" we can
> use in all the places where skb_get_rxhash() gets called.
>
> Part of the problem is that we call it from strange places, such as
> egress packet schedulers. That's completely bogus.
>
> Examples, FLOW classifier, META e-match, CHOKE, and SFB.
>
> In fact, for the classifiers this means they aren't making use of the
> precomputed TX hash values in the sockets like __skb_tx_hash() will
> make use of. So this makes these packet schedulers operate
> potentially more expensively than they need to.
>
> If we could get rid of those silly cases, the stuff that remains
> (macvtap and net/core/dev.c) could work with a NAPI context during
> rxhash computation and use that to store the IP fragmentation
> on-behind cached information.
Isn't there still an issue (perhaps small) of traffic being sent through
a mode-rr bond, either at the origin or somewhere along the way? At the
origin point will depend on the presence of UFO and whether it is
propagated up through the bond interface, but as a quick test, I
disabled TSO, GSO and UFO on four e1000e driven interfaces, bonded them
mode-rr and ran a netperf UDP_RR test with a 1473 byte request size and
this is what they looked like at my un-bonded reciever at the other end:
14:31:01.011370 IP (tos 0x0, ttl 64, id 24960, offset 1480, flags
[none], proto UDP (17), length 21)
tardy.local > raj-8510w.local: udp
14:31:01.011420 IP (tos 0x0, ttl 64, id 24960, offset 0, flags [+],
proto UDP (17), length 1500)
tardy.local.36073 > raj-8510w.local.59951: UDP, length 1473
14:31:01.011514 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 29)
raj-8510w.local.59951 > tardy.local.36073: UDP, length 1
rick jones
^ permalink raw reply
* Re: [PATCH] net: Abstract features usage.
From: Michał Mirosław @ 2011-05-24 21:49 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: David Miller, netdev, Tom Herbert
In-Reply-To: <BANLkTi=F_=Ti=QdDf3-L_hEEwCi9DRR_1Q@mail.gmail.com>
W dniu 24 maja 2011 22:29 użytkownik Mahesh Bandewar
<maheshb@google.com> napisał:
> On Tue, May 24, 2011 at 12:37 PM, Michał Mirosław <mirqus@gmail.com> wrote:
>>
>> 2011/5/24 Mahesh Bandewar <maheshb@google.com>:
>> > Define macros to set/clear/test bits for feature set usage. This will eliminate
>> > the direct use of these fields and enable future ease in managing these fields.
>> >
>> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> > ---
>> > include/linux/netdev_features.h | 137 +++++++++++++++++++++++++++++++++++++++
>> > include/linux/netdevice.h | 35 ++---------
>> > 2 files changed, 142 insertions(+), 30 deletions(-)
>> > create mode 100644 include/linux/netdev_features.h
>> >
>> > diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>> > new file mode 100644
>> > index 0000000..97bf8c4
>> > --- /dev/null
>> > +++ b/include/linux/netdev_features.h
>> > @@ -0,0 +1,137 @@
>> > +#ifndef _NETDEV_FEATURES_H
>> > +#define _NETDEV_FEATURES_H
>> > +
>> > +/* Forward declarations */
>> > +struct net_device;
>> > +
>> > +typedef unsigned long *nd_feature_t;
>> > +
>> > +/* Net device feature bits; if you change something,
>> > + * also update netdev_features_strings[] in ethtool.c */
>> > +enum netdev_features {
>> > + SG_BIT, /* Scatter/gather IO. */
>> [...]
>>
>> Please split this change (introducing enum + converting NETIF_F_*
>> defines to use it). This part is a nice cleanup, but I think the
>> bitmap idea is still not worth the trouble until u64 runs out.
> What will we achieve by this split? May be I'm not getting your point
> about split. Do you want to see the cleanup part as a separate patch?
> These enums and NETIF_F_* values have to be in sync.
Exactly. You already did the cleanup (defining enum and NETIF_F_*
#defines), so just split it into separate patch. This is a
prerequisite to any change to the type holding features from u32 to
either u64 or bitmap. And this will separate the cleanup from your
proposed idea.
> The macros that I have defined are expecting this bit numbers rather
> than the flag value.
> Whether it is u64 or bitmap, the changes should be limited to this
> file. Going forward that can be achieved by
> simply changing few lines in these macros / inlines.
One thing I don't like in this implementation is that it leaves old
fields around - so you'll have two code templates in the kernel doing
the same thing (unless you fix all users, but then you won't need old
fields anyway).
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2011-05-24 21:52 UTC (permalink / raw)
To: Greg KH
Cc: Mike Frysinger, Linus, linux-next, linux-kernel, David S. Miller,
netdev, Andrew Morton, Mel Gorman, linux-mm, Alexander Viro,
linux-fsdevel, Paul E. McKenney, Dipankar Sarma
In-Reply-To: <20110524124833.GB31776@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 599 bytes --]
Hi Greg,
On Tue, 24 May 2011 05:48:33 -0700 Greg KH <greg@kroah.com> wrote:
>
> On Tue, May 24, 2011 at 01:59:30PM +1000, Stephen Rothwell wrote:
> >
> > The cause was a patch from Linus ...
>
> Ah, ok, that makes more sense, sorry for the noise.
And it doesn't show up in many builds because musb depends on ARM ||
(BF54x && !BF544) || (BF52x && !BF522 && !BF523). So it probably appears
in some of the overnight builds, but not the ones I do while creating
linux-next.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox