* Re: [PATCH 0/7] bonding: 7 fixes for 2.6.24
From: David Miller @ 2008-01-21 1:15 UTC (permalink / raw)
To: fubar; +Cc: netdev, jgarzik, andy, akpm
In-Reply-To: <12006159033257-git-send-email-fubar@us.ibm.com>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Thu, 17 Jan 2008 16:24:56 -0800
> Following are seven patches to fix locking problems,
> silence locking-related warnings and resolve one recent regression
> in the current 2.6.24-rc.
Jeff, are you going to merge this stuff in?
I'll drop that rtnl_lock() one-liner if so...
^ permalink raw reply
* Re: [PATCH 1/3] sfq: timer is deferrable
From: David Miller @ 2008-01-21 1:18 UTC (permalink / raw)
To: paulmck; +Cc: shemminger, stephen.hemminger, netdev
In-Reply-To: <20080119055700.GC24840@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Fri, 18 Jan 2008 21:57:00 -0800
> On Fri, Jan 18, 2008 at 08:36:55PM -0800, Stephen Hemminger wrote:
> > On Fri, 18 Jan 2008 20:34:46 -0800
> > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > > On Fri, Jan 18, 2008 at 02:49:00PM -0800, Stephen Hemminger wrote:
> > > > The perturbation timer used for re-keying can be deferred, it doesn't
> > > > need to be deterministic.
> > >
> > > The only concern that I can come up with is that the sfq_perturbation
> > > timer might be on one CPU, and all the operations using the corresponding
> > > SFQ on another. This could in theory allow a nearly omniscient attacker
> > > to exploit an SFQ imbalance while preventing perturbation of the hash
> > > function.
> > >
> > > This does not seem to be a valid concern at this point, since there are
> > > very few uses of init_timer_deferrable(). And if it should become a
> > > problem, one approach would be to have some sort of per-timer limit to
> > > the deferral. Of course, at that point one would need to figure out
> > > what this limit should be!
> > >
> > > Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > But the only threat is getting more bandwidth for a longer interval.
> > It is all kind of moot anyway because the bandwidth hogs all open
> > multiple connections anyway, so SFQ is of no use.
>
> Good point, and an additional reason for my Acked-by above. ;-)
I've applied this patch, thanks :-)
^ permalink raw reply
* Re: [PATCH 2/2] SFQ: use net_random
From: David Miller @ 2008-01-21 1:19 UTC (permalink / raw)
To: paulmck; +Cc: stephen.hemminger, netdev
In-Reply-To: <20080119041820.GA24840@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Date: Fri, 18 Jan 2008 20:18:20 -0800
> On Fri, Jan 18, 2008 at 02:47:30PM -0800, Stephen Hemminger wrote:
> > SFQ doesn't need true random numbers, it is only using them to salt
> > a hash. Therefore it is better to use net_random() and avoid any possible
> > problems with depleting the entropy pool.
>
> The random-number algorithm used by net_random() certainly does appear
> to be considerably stronger than the one I used to generate the results
> in the 1990 paper. ;-)
>
> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Also applied, thanks.
^ permalink raw reply
* Re: [PATCH 3/3] sfq: whitespace cleanup
From: David Miller @ 2008-01-21 1:21 UTC (permalink / raw)
To: stephen.hemminger; +Cc: paulmck, netdev
In-Reply-To: <20080118144837.0a3593c5@deepthought>
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Fri, 18 Jan 2008 14:48:37 -0800
> Add whitespace around operators, and add a few blank lines
> to improve readability.
>
> Signed-off-by: Stephen Hemminger <stephen.hemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [2.6 patch] atm/idt77105.c: fix section mismatch
From: David Miller @ 2008-01-21 1:22 UTC (permalink / raw)
To: sam; +Cc: bunk, chas, jgarzik, netdev, linux-kernel
In-Reply-To: <20080119132852.GB26615@uranus.ravnborg.org>
From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 19 Jan 2008 14:28:52 +0100
> On Sat, Jan 19, 2008 at 03:18:49PM +0200, Adrian Bunk wrote:
> > EXPORT_SYMBOL'ed code mustn't be __*init.
> >
> > Signed-off-by: Adrian Bunk <bunk@kernel.org>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
Applied.
^ permalink raw reply
* Re: [2.6 patch] atm/suni.c: fix section mismatch
From: David Miller @ 2008-01-21 1:23 UTC (permalink / raw)
To: sam; +Cc: bunk, chas, jgarzik, netdev, linux-kernel
In-Reply-To: <20080119132904.GC26615@uranus.ravnborg.org>
From: Sam Ravnborg <sam@ravnborg.org>
Date: Sat, 19 Jan 2008 14:29:04 +0100
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
Applied.
^ permalink raw reply
* Re: [AF_KEY]: Fix skb leak on pfkey_send_migrate() error
From: David Miller @ 2008-01-21 1:24 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <479364DC.40604@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 20 Jan 2008 16:12:28 +0100
> commit 4dd3440faa345731c27337ee041c0e9abf2b70dc
> Author: Patrick McHardy <kaber@trash.net>
> Date: Sun Jan 20 16:10:04 2008 +0100
>
> [AF_KEY]: Fix skb leak on pfkey_send_migrate() error
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied, thanks Patrick.
^ permalink raw reply
* Re: [NET]: rtnl_link: fix use-after-free
From: David Miller @ 2008-01-21 1:25 UTC (permalink / raw)
To: kaber; +Cc: xemul, netdev
In-Reply-To: <47938317.1070906@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 20 Jan 2008 18:21:27 +0100
> commit 6e470bd53fb50632fe1878bb74bb8531a21b6731
> Author: Patrick McHardy <kaber@trash.net>
> Date: Sun Jan 20 18:19:15 2008 +0100
>
> [NET]: rtnl_link: fix use-after-free
>
> When unregistering the rtnl_link_ops, all existing devices using
> the ops are destroyed. With nested devices this may lead to a
> use-after-free despite the use of for_each_netdev_safe() in case
> the upper device is next in the device list and is destroyed
> by the NETDEV_UNREGISTER notifier.
>
> The easy fix is to restart scanning the device list after removing
> a device. Alternatively we could add new devices to the front of
> the list to avoid having dependant devices follow the device they
> depend on. A third option would be to only restart scanning if
> dev->iflink of the next device matches dev->ifindex of the current
> one. For now this seems like the safest solution.
>
> With this patch, the veth rtnl_link_ops unregistration can use
> rtnl_link_unregister() directly since it now also handles destruction
> of multiple devices at once.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/7] bonding: 7 fixes for 2.6.24
From: Andrew Morton @ 2008-01-21 1:36 UTC (permalink / raw)
To: David Miller; +Cc: fubar, netdev, jgarzik, andy
In-Reply-To: <20080120.171538.12566715.davem@davemloft.net>
On Sun, 20 Jan 2008 17:15:38 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: Jay Vosburgh <fubar@us.ibm.com>
> Date: Thu, 17 Jan 2008 16:24:56 -0800
>
> > Following are seven patches to fix locking problems,
> > silence locking-related warnings and resolve one recent regression
> > in the current 2.6.24-rc.
>
> Jeff, are you going to merge this stuff in?
>
> I'll drop that rtnl_lock() one-liner if so...
It's all in mainline. The one-liner should be unneeded.
^ permalink raw reply
* Re: [PATCH 0/7] bonding: 7 fixes for 2.6.24
From: Jeff Garzik @ 2008-01-21 1:57 UTC (permalink / raw)
To: David Miller; +Cc: fubar, netdev, andy, akpm
In-Reply-To: <20080120.171538.12566715.davem@davemloft.net>
David Miller wrote:
> From: Jay Vosburgh <fubar@us.ibm.com>
> Date: Thu, 17 Jan 2008 16:24:56 -0800
>
>> Following are seven patches to fix locking problems,
>> silence locking-related warnings and resolve one recent regression
>> in the current 2.6.24-rc.
>
> Jeff, are you going to merge this stuff in?
>
> I'll drop that rtnl_lock() one-liner if so...
Linus has this series in linux-2.6.git, even...
Jeff
^ permalink raw reply
* Re: [PATCH 0/7] bonding: 7 fixes for 2.6.24
From: David Miller @ 2008-01-21 3:58 UTC (permalink / raw)
To: akpm; +Cc: fubar, netdev, jgarzik, andy
In-Reply-To: <20080120173644.4586483e.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Sun, 20 Jan 2008 17:36:44 -0800
> On Sun, 20 Jan 2008 17:15:38 -0800 (PST) David Miller <davem@davemloft.net> wrote:
>
> > From: Jay Vosburgh <fubar@us.ibm.com>
> > Date: Thu, 17 Jan 2008 16:24:56 -0800
> >
> > > Following are seven patches to fix locking problems,
> > > silence locking-related warnings and resolve one recent regression
> > > in the current 2.6.24-rc.
> >
> > Jeff, are you going to merge this stuff in?
> >
> > I'll drop that rtnl_lock() one-liner if so...
>
> It's all in mainline. The one-liner should be unneeded.
Excellent.
^ permalink raw reply
* Re: [PATCH 3/4] bonding: Fix work rearming
From: Makito SHIOKAWA @ 2008-01-21 4:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev, Makito SHIOKAWA
In-Reply-To: <47912B83.5010407@gmail.com>
> (But new_value = 0 seems needed - just like from module_param()?)
Do you mean to initialize new_value before sscanf()? (There is a check 'if (sscanf(buf, "%d", &new_value) != 1)', so is it necesarry?)
> - maybe to test if the value has changed at all,
Tested.
For now, patch will be like below. Any slight comment for this will be helpful, regards.
Signed-off-by: Makito SHIOKAWA <mshiokawa@miraclelinux.com>
---
drivers/net/bonding/bond_main.c | 11 ++++-------
drivers/net/bonding/bond_sysfs.c | 19 +++++++++++++++++--
2 files changed, 21 insertions(+), 9 deletions(-)
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2699,7 +2699,7 @@ void bond_loadbalance_arp_mon(struct wor
read_lock(&bond->lock);
- delta_in_ticks = (bond->params.arp_interval * HZ) / 1000;
+ delta_in_ticks = ((bond->params.arp_interval * HZ) / 1000) ? : 1;
if (bond->kill_timers) {
goto out;
@@ -2801,8 +2801,7 @@ void bond_loadbalance_arp_mon(struct wor
}
re_arm:
- if (bond->params.arp_interval)
- queue_delayed_work(bond->wq, &bond->lb_arp_work, delta_in_ticks);
+ queue_delayed_work(bond->wq, &bond->lb_arp_work, delta_in_ticks);
out:
read_unlock(&bond->lock);
}
@@ -2832,7 +2831,7 @@ void bond_activebackup_arp_mon(struct wo
read_lock(&bond->lock);
- delta_in_ticks = (bond->params.arp_interval * HZ) / 1000;
+ delta_in_ticks = ((bond->params.arp_interval * HZ) / 1000) ? : 1;
if (bond->kill_timers) {
goto out;
@@ -3058,9 +3057,7 @@ void bond_activebackup_arp_mon(struct wo
}
re_arm:
- if (bond->params.arp_interval) {
- queue_delayed_work(bond->wq, &bond->ab_arp_work, delta_in_ticks);
- }
+ queue_delayed_work(bond->wq, &bond->ab_arp_work, delta_in_ticks);
out:
read_unlock(&bond->lock);
}
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -644,6 +644,15 @@ static ssize_t bonding_store_arp_interva
": %s: Setting ARP monitoring interval to %d.\n",
bond->dev->name, new_value);
bond->params.arp_interval = new_value;
+ if (bond->params.arp_interval == 0 && (bond->dev->flags & IFF_UP)) {
+ printk(KERN_INFO DRV_NAME
+ ": %s: Disabling ARP monitoring.\n",
+ bond->dev->name);
+ if (bond->params.mode == BOND_MODE_ACTIVEBACKUP)
+ cancel_delayed_work_sync(&bond->ab_arp_work);
+ else
+ cancel_delayed_work_sync(&bond->lb_arp_work);
+ }
if (bond->params.miimon) {
printk(KERN_INFO DRV_NAME
": %s: ARP monitoring cannot be used with MII monitoring. "
@@ -658,7 +667,7 @@ static ssize_t bonding_store_arp_interva
"but no ARP targets have been specified.\n",
bond->dev->name);
}
- if (bond->dev->flags & IFF_UP) {
+ if (bond->params.arp_interval && (bond->dev->flags & IFF_UP)) {
/* If the interface is up, we may need to fire off
* the ARP timer. If the interface is down, the
* timer will get fired off when the open function
@@ -997,6 +1006,12 @@ static ssize_t bonding_store_miimon(stru
": %s: Setting MII monitoring interval to %d.\n",
bond->dev->name, new_value);
bond->params.miimon = new_value;
+ if (bond->params.miimon == 0 && (bond->dev->flags & IFF_UP)) {
+ printk(KERN_INFO DRV_NAME
+ ": %s: Disabling MII monitoring...\n",
+ bond->dev->name);
+ cancel_delayed_work_sync(&bond->mii_work);
+ }
if(bond->params.updelay)
printk(KERN_INFO DRV_NAME
": %s: Note: Updating updelay (to %d) "
@@ -1026,7 +1041,7 @@ static ssize_t bonding_store_miimon(stru
cancel_delayed_work_sync(&bond->lb_arp_work);
}
- if (bond->dev->flags & IFF_UP) {
+ if (bond->params.miimon && (bond->dev->flags & IFF_UP)) {
/* If the interface is up, we may need to fire off
* the MII timer. If the interface is down, the
* timer will get fired off when the open function
--
Makito SHIOKAWA
MIRACLE LINUX CORPORATION
^ permalink raw reply
* [PATCH] bluetooth : move children of connection device to NULL before connection down
From: Dave Young @ 2008-01-21 4:49 UTC (permalink / raw)
To: marcel; +Cc: netdev, bluez-devel, davem, linux-kernel
The rfcomm tty device will possibly retain even when conn is down,
and sysfs doesn't support zombie device moving, so this patch
move the tty device before conn device is destroyed.
For the bug refered please see :
http://lkml.org/lkml/2007/12/28/87
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
---
net/bluetooth/hci_sysfs.c | 17 +++++++++++++++++
net/bluetooth/rfcomm/tty.c | 3 ++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2008-01-21 11:29:34.000000000 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2008-01-21 11:33:46.000000000 +0800
@@ -316,9 +316,26 @@ void hci_conn_add_sysfs(struct hci_conn
schedule_work(&conn->work);
}
+static int __match_tty(struct device *dev, void *data)
+{
+ /* The rfcomm tty device will possibly retain even when conn
+ * is down, and sysfs doesn't support move zombie device,
+ * so we should move the device before conn device is destroyed.
+ * Due to the only child device of hci_conn dev is rfcomm
+ * tty_dev, here just return 1
+ */
+ return 1;
+}
+
static void del_conn(struct work_struct *work)
{
+ struct device *dev;
struct hci_conn *conn = container_of(work, struct hci_conn, work);
+
+ while (dev = device_find_child(&conn->dev, NULL, __match_tty)) {
+ device_move(dev, NULL);
+ put_device(dev);
+ }
device_del(&conn->dev);
put_device(&conn->dev);
}
diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
--- linux/net/bluetooth/rfcomm/tty.c 2008-01-21 11:30:44.000000000 +0800
+++ linux.new/net/bluetooth/rfcomm/tty.c 2008-01-21 11:32:23.000000000 +0800
@@ -696,7 +696,8 @@ static void rfcomm_tty_close(struct tty_
BT_DBG("tty %p dev %p dlc %p opened %d", tty, dev, dev->dlc, dev->opened);
if (--dev->opened == 0) {
- device_move(dev->tty_dev, NULL);
+ if (dev->tty_dev->parent)
+ device_move(dev->tty_dev, NULL);
/* Close DLC and dettach TTY */
rfcomm_dlc_close(dev->dlc, 0);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH] bluetooth : move children of connection device to NULL before connection down
From: Dave Young @ 2008-01-21 4:54 UTC (permalink / raw)
To: marcel
Cc: davem, netdev, linux-kernel, bluez-devel, cornelia.huck, gombasg,
htejun, viro, kay.sievers, greg
In-Reply-To: <20080121044913.GA4162@darkstar.te-china.tietoenator.com>
On Mon, Jan 21, 2008 at 12:49:13PM +0800, Dave Young wrote:
> The rfcomm tty device will possibly retain even when conn is down,
> and sysfs doesn't support zombie device moving, so this patch
> move the tty device before conn device is destroyed.
>
> For the bug refered please see :
> http://lkml.org/lkml/2007/12/28/87
>
> Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
>
> ---
> net/bluetooth/hci_sysfs.c | 17 +++++++++++++++++
> net/bluetooth/rfcomm/tty.c | 3 ++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
> --- linux/net/bluetooth/hci_sysfs.c 2008-01-21 11:29:34.000000000 +0800
> +++ linux.new/net/bluetooth/hci_sysfs.c 2008-01-21 11:33:46.000000000 +0800
> @@ -316,9 +316,26 @@ void hci_conn_add_sysfs(struct hci_conn
> schedule_work(&conn->work);
> }
>
> +static int __match_tty(struct device *dev, void *data)
> +{
> + /* The rfcomm tty device will possibly retain even when conn
> + * is down, and sysfs doesn't support move zombie device,
> + * so we should move the device before conn device is destroyed.
> + * Due to the only child device of hci_conn dev is rfcomm
> + * tty_dev, here just return 1
> + */
> + return 1;
> +}
> +
> static void del_conn(struct work_struct *work)
> {
> + struct device *dev;
> struct hci_conn *conn = container_of(work, struct hci_conn, work);
> +
> + while (dev = device_find_child(&conn->dev, NULL, __match_tty)) {
> + device_move(dev, NULL);
> + put_device(dev);
> + }
> device_del(&conn->dev);
> put_device(&conn->dev);
> }
> diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
> --- linux/net/bluetooth/rfcomm/tty.c 2008-01-21 11:30:44.000000000 +0800
> +++ linux.new/net/bluetooth/rfcomm/tty.c 2008-01-21 11:32:23.000000000 +0800
> @@ -696,7 +696,8 @@ static void rfcomm_tty_close(struct tty_
> BT_DBG("tty %p dev %p dlc %p opened %d", tty, dev, dev->dlc, dev->opened);
>
> if (--dev->opened == 0) {
> - device_move(dev->tty_dev, NULL);
> + if (dev->tty_dev->parent)
> + device_move(dev->tty_dev, NULL);
>
> /* Close DLC and dettach TTY */
> rfcomm_dlc_close(dev->dlc, 0);
Add people missed in cc-list.
^ permalink raw reply
* Re: [PATCH] net: add sparse annotation to ptype_seq_start/stop
From: Paul E. McKenney @ 2008-01-21 5:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, josh
In-Reply-To: <20080120152146.70bc0b12@deepthought>
On Sun, Jan 20, 2008 at 03:21:46PM -0800, Stephen Hemminger wrote:
> Get rid of some more sparse warnings.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Adding Josh to CC -- is __acquires() case-insensitive? If not, this
needs to be __acquires(RCU) and __releases(RCU).
Thanx, Paul
> --- a/net/core/dev.c 2008-01-20 14:25:00.000000000 -0800
> +++ b/net/core/dev.c 2008-01-20 14:25:48.000000000 -0800
> @@ -2543,6 +2543,7 @@ static void *ptype_get_idx(loff_t pos)
> }
>
> static void *ptype_seq_start(struct seq_file *seq, loff_t *pos)
> + __acquires(rcu)
> {
> rcu_read_lock();
> return *pos ? ptype_get_idx(*pos - 1) : SEQ_START_TOKEN;
> @@ -2578,6 +2579,7 @@ found:
> }
>
> static void ptype_seq_stop(struct seq_file *seq, void *v)
> + __releases(rcu)
> {
> rcu_read_unlock();
> }
> --
> 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: [PATCH] net: add sparse annotation to ptype_seq_start/stop
From: Al Viro @ 2008-01-21 5:28 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: Stephen Hemminger, David Miller, netdev, josh
In-Reply-To: <20080121050355.GD7541@linux.vnet.ibm.com>
On Sun, Jan 20, 2008 at 09:03:55PM -0800, Paul E. McKenney wrote:
> On Sun, Jan 20, 2008 at 03:21:46PM -0800, Stephen Hemminger wrote:
> > Get rid of some more sparse warnings.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Adding Josh to CC -- is __acquires() case-insensitive? If not, this
> needs to be __acquires(RCU) and __releases(RCU).
__acquires(whatever_the_helk_you_put_as_its_argument) is all the same.
^ permalink raw reply
* Re: [PATCH] net: add sparse annotation to ptype_seq_start/stop
From: Paul E. McKenney @ 2008-01-21 6:01 UTC (permalink / raw)
To: Al Viro; +Cc: Stephen Hemminger, David Miller, netdev, josh
In-Reply-To: <20080121052831.GF27894@ZenIV.linux.org.uk>
On Mon, Jan 21, 2008 at 05:28:31AM +0000, Al Viro wrote:
> On Sun, Jan 20, 2008 at 09:03:55PM -0800, Paul E. McKenney wrote:
> > On Sun, Jan 20, 2008 at 03:21:46PM -0800, Stephen Hemminger wrote:
> > > Get rid of some more sparse warnings.
> > >
> > > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > Adding Josh to CC -- is __acquires() case-insensitive? If not, this
> > needs to be __acquires(RCU) and __releases(RCU).
>
> __acquires(whatever_the_helk_you_put_as_its_argument) is all the same.
The existing calls are __acquires(RCU) and __releases(RCU). I suppose
that one -could- use __acquires(RCU) in some places and __acquires(rcu)
in others, but that sounds like it would eventually bite us...
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 2/3][NET] gen_estimator: list_empty() check in est_timer() fixed
From: Jarek Poplawski @ 2008-01-21 6:34 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Badalian Vyacheslav, Patrick McHardy, jamal, David Miller, netdev
In-Reply-To: <20080120155544.0a071675@deepthought>
On Sun, Jan 20, 2008 at 03:55:44PM -0800, Stephen Hemminger wrote:
> On Mon, 21 Jan 2008 00:49:59 +0100
> Jarek Poplawski <jarkao2@gmail.com> wrote:
>
> > This patch changes the method of checking for empty list in est_timer():
> > list_empty() is not recommended for RCU protected lists. Now, it's simply
> > a variable used for this.
> >
> > Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
> >
> > ---
> >
> > diff -Nurp 2.6.24-rc8-mm1-p1-/net/core/gen_estimator.c 2.6.24-rc8-mm1-p1+/net/core/gen_estimator.c
> > --- 2.6.24-rc8-mm1-p1-/net/core/gen_estimator.c 2008-01-20 20:58:35.000000000 +0100
> > +++ 2.6.24-rc8-mm1-p1+/net/core/gen_estimator.c 2008-01-20 21:07:42.000000000 +0100
> > @@ -106,6 +106,7 @@ static void est_timer(unsigned long arg)
> > {
> > int idx = (int)arg;
> > struct gen_estimator *e;
> > + int list_not_empty = 0;
>
> Using a negative name for what is a boolean value leads
> to code that reads like a double negative sentence. Better to choose
> a variable name that is direct, can't use list_empty because that
> is a macro, so how about "estimator_found".
>
Hmm, seems right, but since just after sending this patch I started
to doubt this 2/3 patch could really matter here, I'll maybe wait with
this name change for some confirmation yet.
So, since it certainly doesn't matter for 1/3 and 3/3 I withdraw this
2/3 patch for now.
BTW, I've forgotten to mention with patch 1/3 that this checking with
warning on gen_new_estimator() double call should be only temporary,
and after more testing gen_estimator structure could be probably
decreased after removing bstats and rate_est fields.
Thanks,
Jarek P.
^ permalink raw reply
* Re: [PATCH 2/3][NET] gen_estimator: list_empty() check in est_timer() fixed
From: Jarek Poplawski @ 2008-01-21 6:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Badalian Vyacheslav, Patrick McHardy, jamal, David Miller, netdev
In-Reply-To: <20080121063455.GA981@ff.dom.local>
On Mon, Jan 21, 2008 at 07:34:55AM +0100, Jarek Poplawski wrote:
...
> BTW, I've forgotten to mention with patch 1/3 that this checking with
> warning on gen_new_estimator() double call should be only temporary,
> and after more testing gen_estimator structure could be probably
> decreased after removing bstats and rate_est fields.
Hmm, let's forget about this again: it's too early in the morning...
Jarek P.
^ permalink raw reply
* Re: [REGRESSION] 2.6.24-rc7: e1000: Detected Tx Unit Hang
From: Badalian Vyacheslav @ 2008-01-21 6:54 UTC (permalink / raw)
To: David Miller; +Cc: elendil, netdev, linux-kernel
In-Reply-To: <20080116.042817.143947133.davem@davemloft.net>
Hello. Its work, thanks for resend it!
Sorry, i understand that patch 53e52c729cc169db82a6105fac7a166e10c2ec36
("[NET]: Make ->poll() breakout consistent in Intel ethernet drivers.")
have regression and rollback it, i not see your patch.
Sorry again.
Thanks!
> From: Badalian Vyacheslav <slavon@bigtelecom.ru>
> Date: Wed, 16 Jan 2008 12:02:28 +0300
>
>
>> Also have regression after apply patch.
>>
>
> BTW, if you are using the e1000e driver then this initial
> patch will not work.
>
> My more recent patch posting for this problem, will.
>
> I include it again below for you:
>
> [NET]: Fix TX timeout regression in Intel drivers.
>
> This fixes a regression added by changeset
> 53e52c729cc169db82a6105fac7a166e10c2ec36 ("[NET]: Make ->poll()
> breakout consistent in Intel ethernet drivers.")
>
> As pointed out by Jesse Brandeburg, for three of the drivers edited
> above there is breakout logic in the *_clean_tx_irq() code to prevent
> running TX reclaim forever. If this occurs, we have to elide NAPI
> poll completion or else those TX events will never be serviced.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index 13d57b0..0c9a6f7 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -3919,7 +3919,7 @@ e1000_clean(struct napi_struct *napi, int budget)
> {
> struct e1000_adapter *adapter = container_of(napi, struct e1000_adapter, napi);
> struct net_device *poll_dev = adapter->netdev;
> - int work_done = 0;
> + int tx_cleaned = 0, work_done = 0;
>
> /* Must NOT use netdev_priv macro here. */
> adapter = poll_dev->priv;
> @@ -3929,14 +3929,17 @@ e1000_clean(struct napi_struct *napi, int budget)
> * simultaneously. A failure obtaining the lock means
> * tx_ring[0] is currently being cleaned anyway. */
> if (spin_trylock(&adapter->tx_queue_lock)) {
> - e1000_clean_tx_irq(adapter,
> - &adapter->tx_ring[0]);
> + tx_cleaned = e1000_clean_tx_irq(adapter,
> + &adapter->tx_ring[0]);
> spin_unlock(&adapter->tx_queue_lock);
> }
>
> adapter->clean_rx(adapter, &adapter->rx_ring[0],
> &work_done, budget);
>
> + if (tx_cleaned)
> + work_done = budget;
> +
> /* If budget not fully consumed, exit the polling mode */
> if (work_done < budget) {
> if (likely(adapter->itr_setting & 3))
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 4a6fc74..2ab3bfb 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -1384,7 +1384,7 @@ static int e1000_clean(struct napi_struct *napi, int budget)
> {
> struct e1000_adapter *adapter = container_of(napi, struct e1000_adapter, napi);
> struct net_device *poll_dev = adapter->netdev;
> - int work_done = 0;
> + int tx_cleaned = 0, work_done = 0;
>
> /* Must NOT use netdev_priv macro here. */
> adapter = poll_dev->priv;
> @@ -1394,12 +1394,15 @@ static int e1000_clean(struct napi_struct *napi, int budget)
> * simultaneously. A failure obtaining the lock means
> * tx_ring is currently being cleaned anyway. */
> if (spin_trylock(&adapter->tx_queue_lock)) {
> - e1000_clean_tx_irq(adapter);
> + tx_cleaned = e1000_clean_tx_irq(adapter);
> spin_unlock(&adapter->tx_queue_lock);
> }
>
> adapter->clean_rx(adapter, &work_done, budget);
>
> + if (tx_cleaned)
> + work_done = budget;
> +
> /* If budget not fully consumed, exit the polling mode */
> if (work_done < budget) {
> if (adapter->itr_setting & 3)
> diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
> index a564916..de3f45e 100644
> --- a/drivers/net/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ixgbe/ixgbe_main.c
> @@ -1468,13 +1468,16 @@ static int ixgbe_clean(struct napi_struct *napi, int budget)
> struct ixgbe_adapter *adapter = container_of(napi,
> struct ixgbe_adapter, napi);
> struct net_device *netdev = adapter->netdev;
> - int work_done = 0;
> + int tx_cleaned = 0, work_done = 0;
>
> /* In non-MSIX case, there is no multi-Tx/Rx queue */
> - ixgbe_clean_tx_irq(adapter, adapter->tx_ring);
> + tx_cleaned = ixgbe_clean_tx_irq(adapter, adapter->tx_ring);
> ixgbe_clean_rx_irq(adapter, &adapter->rx_ring[0], &work_done,
> budget);
>
> + if (tx_cleaned)
> + work_done = budget;
> +
> /* If budget not fully consumed, exit the polling mode */
> if (work_done < budget) {
> netif_rx_complete(netdev, napi);
>
>
^ permalink raw reply
* [PATCH] [IPV4] route: fix locking in rt_run_flush()
From: Joonwoo Park @ 2008-01-21 15:08 UTC (permalink / raw)
To: David Miller; +Cc: Joonwoo Park, linux-netdev
The rt_run_flush() can be stucked if it was called while netdev is on the
high load.
It's possible when pushing rtable to rt_hash is faster than pulling
from it.
The commands 'ifconfig up or ifconfig mtu' and netif_carrier_on() can
introduce soft lockup like this:
[ 363.528001] BUG: soft lockup - CPU#0 stuck for 11s! [events/0:9]
[ 363.531492]
[ 363.535027] Pid: 9, comm: events/0 Not tainted (2.6.24-rc8 #14)
[ 363.538837] EIP: 0060:[<c4086a39>] EFLAGS: 00000286 CPU: 0
[ 363.542762] EIP is at kfree+0xa9/0xf0
...
[ 363.660815] [<c42fb0fd>] skb_release_data+0x5d/0x90
[ 363.666989] [<c42fb7dc>] skb_release_all+0x5c/0xd0
[ 363.673207] [<c42faf8b>] __kfree_skb+0xb/0x90
[ 363.679474] [<c42fb029>] kfree_skb+0x19/0x40
[ 363.685811] [<c4322d87>] ip_rcv+0x27/0x290
[ 363.692223] [<c4300ae5>] netif_receive_skb+0x255/0x320
[ 363.698759] [<f88465aa>] e1000_clean_rx_irq+0x14a/0x4f0 [e1000]
[ 363.705456] [<f88437c2>] e1000_clean+0x62/0x270 [e1000]
[ 363.712217] [<c43031ee>] net_rx_action+0x16e/0x220
[ 363.719065] [<c40346d7>] __do_softirq+0x87/0x100
[ 363.726001] [<c40347a7>] do_softirq+0x57/0x60
[ 363.732979] [<c4034b4e>] local_bh_enable_ip+0xae/0x100
[ 363.740094] [<c43e73f5>] _spin_unlock_bh+0x25/0x30
[ 363.747283] [<c431ec88>] rt_run_flush+0xc8/0xe0
[ 363.754566] [<c4320c76>] rt_cache_flush+0xd6/0xe0
[ 363.761917] [<c4350269>] fib_netdev_event+0x89/0xa0
[ 363.769361] [<c4047d67>] notifier_call_chain+0x37/0x80
...
This patch makes rt_run_flush() to run with softirq is disabled.
Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
---
net/ipv4/route.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 28484f3..454e71c 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -620,18 +620,20 @@ static void rt_run_flush(unsigned long dummy)
get_random_bytes(&rt_hash_rnd, 4);
+ local_bh_disable();
for (i = rt_hash_mask; i >= 0; i--) {
- spin_lock_bh(rt_hash_lock_addr(i));
+ spin_lock(rt_hash_lock_addr(i));
rth = rt_hash_table[i].chain;
if (rth)
rt_hash_table[i].chain = NULL;
- spin_unlock_bh(rt_hash_lock_addr(i));
+ spin_unlock(rt_hash_lock_addr(i));
for (; rth; rth = next) {
next = rth->u.dst.rt_next;
rt_free(rth);
}
}
+ local_bh_enable();
}
static DEFINE_SPINLOCK(rt_flush_lock);
--
1.5.3.rc5
^ permalink raw reply related
* Re: [PATCH] net: add sparse annotation to ptype_seq_start/stop
From: Josh Triplett @ 2008-01-21 7:29 UTC (permalink / raw)
To: paulmck; +Cc: Stephen Hemminger, David Miller, netdev
In-Reply-To: <20080121050355.GD7541@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
Paul E. McKenney wrote:
> On Sun, Jan 20, 2008 at 03:21:46PM -0800, Stephen Hemminger wrote:
>> Get rid of some more sparse warnings.
>>
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Adding Josh to CC -- is __acquires() case-insensitive? If not, this
> needs to be __acquires(RCU) and __releases(RCU).
[...]
>> --- a/net/core/dev.c 2008-01-20 14:25:00.000000000 -0800
>> +++ b/net/core/dev.c 2008-01-20 14:25:48.000000000 -0800
>> @@ -2543,6 +2543,7 @@ static void *ptype_get_idx(loff_t pos)
>> }
>>
>> static void *ptype_seq_start(struct seq_file *seq, loff_t *pos)
>> + __acquires(rcu)
>> {
>> rcu_read_lock();
>> return *pos ? ptype_get_idx(*pos - 1) : SEQ_START_TOKEN;
>> @@ -2578,6 +2579,7 @@ found:
>> }
>>
>> static void ptype_seq_stop(struct seq_file *seq, void *v)
>> + __releases(rcu)
>> {
>> rcu_read_unlock();
>> }
At the moment, Sparse doesn't actually use the context expression. In
the ideal case when it does, all references to the same lock should
use a context expression which resolves to that lock (whatever that
may mean; hence why Sparse doesn't handle it yet). For mechanisms
like RCU without a lock variable, this will likely entail some sort of
fake lock expression, which again needs to match between all users of
the same mechanism. Like any expression in C, case matters; thus,
please match the existing references to "RCU" rather than "rcu".
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* 2.6.24-rc8-mm1 : net tcp_input.c warnings
From: Dave Young @ 2008-01-21 7:55 UTC (permalink / raw)
To: linux-kernel; +Cc: davem, netdev, akpm
Please see the kernel messages following,(trigged while using some qemu session)
BTW, seems there's some e100 error message as well.
PCI: Setting latency timer of device 0000:00:1b.0 to 64
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
ACPI: PCI Interrupt 0000:03:08.0[A] -> GSI 20 (level, low) -> IRQ 20
modprobe:2331 conflicting cache attribute efaff000-efb00000 uncached<->default
e100: 0000:03:08.0: e100_probe: Cannot map device registers, aborting.
ACPI: PCI interrupt for device 0000:03:08.0 disabled
e100: probe of 0000:03:08.0 failed with error -12
eth0: setting full-duplex.
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2169 tcp_mark_head_lost+0x121/0x150()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c03e8df8>] ? ip_finish_output+0x128/0x2e0
[<c03e9527>] ? ip_output+0xe7/0x100
[<c03e8a88>] ? ip_local_out+0x18/0x20
[<c03e991c>] ? ip_queue_xmit+0x3dc/0x470
[<c043641e>] ? _spin_unlock_irqrestore+0x5e/0x70
[<c0186be1>] ? check_pad_bytes+0x61/0x80
[<c03f6031>] tcp_mark_head_lost+0x121/0x150
[<c03f60ac>] tcp_update_scoreboard+0x4c/0x170
[<c03f6e0a>] tcp_fastretrans_alert+0x48a/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0151d2c>] ? tick_nohz_stop_sched_tick+0x25c/0x350
[<c01059ca>] common_interrupt+0x2e/0x34
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2528 tcp_fastretrans_alert+0x675/0x6b0()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c0156b87>] ? __lock_release+0x47/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c043641e>] ? _spin_unlock_irqrestore+0x5e/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c03f6ff5>] tcp_fastretrans_alert+0x675/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0151d2c>] ? tick_nohz_stop_sched_tick+0x25c/0x350
[<c01059ca>] common_interrupt+0x2e/0x34
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2169 tcp_mark_head_lost+0x121/0x150()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c0153241>] ? put_lock_stats+0x21/0x30
[<c01532b0>] ? lock_release_holdtime+0x60/0x80
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c0156b87>] ? __lock_release+0x47/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c043641e>] ? _spin_unlock_irqrestore+0x5e/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c03f6031>] tcp_mark_head_lost+0x121/0x150
[<c03f60ac>] tcp_update_scoreboard+0x4c/0x170
[<c03f6e0a>] tcp_fastretrans_alert+0x48a/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0151d2c>] ? tick_nohz_stop_sched_tick+0x25c/0x350
[<c01059ca>] common_interrupt+0x2e/0x34
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2528 tcp_fastretrans_alert+0x675/0x6b0()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c0156b87>] ? __lock_release+0x47/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c0186ae4>] ? check_bytes_and_report+0x24/0xc0
[<c043641e>] ? _spin_unlock_irqrestore+0x5e/0x70
[<c0186be1>] ? check_pad_bytes+0x61/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c03f6ff5>] tcp_fastretrans_alert+0x675/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0151d2c>] ? tick_nohz_stop_sched_tick+0x25c/0x350
[<c01059ca>] common_interrupt+0x2e/0x34
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2169 tcp_mark_head_lost+0x121/0x150()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c010af95>] ? native_sched_clock+0x85/0xe0
[<c0153241>] ? put_lock_stats+0x21/0x30
[<c01532b0>] ? lock_release_holdtime+0x60/0x80
[<c0187918>] ? add_partial+0x48/0x90
[<c03f6031>] tcp_mark_head_lost+0x121/0x150
[<c03f60ac>] tcp_update_scoreboard+0x4c/0x170
[<c03f6e0a>] tcp_fastretrans_alert+0x48a/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0151d2c>] ? tick_nohz_stop_sched_tick+0x25c/0x350
[<c01059ca>] common_interrupt+0x2e/0x34
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2528 tcp_fastretrans_alert+0x675/0x6b0()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c0186ae4>] ? check_bytes_and_report+0x24/0xc0
[<c0186be1>] ? check_pad_bytes+0x61/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c03f6ff5>] tcp_fastretrans_alert+0x675/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0151d2c>] ? tick_nohz_stop_sched_tick+0x25c/0x350
[<c01059ca>] common_interrupt+0x2e/0x34
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:2169 tcp_mark_head_lost+0x121/0x150()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 2754, comm: X Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c015322d>] ? put_lock_stats+0xd/0x30
[<c01532b0>] ? lock_release_holdtime+0x60/0x80
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c0156b87>] ? __lock_release+0x47/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c04363f9>] ? _spin_unlock_irqrestore+0x39/0x70
[<c013dbb4>] ? group_send_sig_info+0x74/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c03f6031>] tcp_mark_head_lost+0x121/0x150
[<c03f60ac>] tcp_update_scoreboard+0x4c/0x170
[<c03f5ed1>] ? tcp_time_to_recover+0xe1/0xf0
[<c03f6e0a>] tcp_fastretrans_alert+0x48a/0x6b0
[<c03f7d93>] tcp_ack+0x1b3/0x3a0
[<c03fa14b>] tcp_rcv_established+0x3eb/0x710
[<c04015c5>] tcp_v4_do_rcv+0xe5/0x100
[<c0401bbb>] tcp_v4_rcv+0x5db/0x660
[<c0401967>] ? tcp_v4_rcv+0x387/0x660
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c03e5f44>] ip_local_deliver_finish+0x84/0x1d0
[<c03e5eed>] ? ip_local_deliver_finish+0x2d/0x1d0
[<c0156b87>] ? __lock_release+0x47/0x70
[<c03e6147>] ip_local_deliver+0xb7/0xc0
[<c03e6202>] ip_rcv_finish+0xb2/0x3c0
[<c03c01c8>] ? sock_def_readable+0x48/0xa0
[<c03be051>] ? sock_queue_rcv_skb+0xb1/0x1a0
[<c03be097>] ? sock_queue_rcv_skb+0xf7/0x1a0
[<c03e669f>] ip_rcv+0x18f/0x290
[<c042f4d0>] ? packet_rcv_spkt+0xd0/0x130
[<c03c8d96>] netif_receive_skb+0x2b6/0x330
[<c03c8c07>] ? netif_receive_skb+0x127/0x330
[<c03c8e93>] ? process_backlog+0x83/0x100
[<c03c8e9e>] process_backlog+0x8e/0x100
[<c03c90ac>] net_rx_action+0x13c/0x230
[<c03c8fc9>] ? net_rx_action+0x59/0x230
[<c0136f2e>] ? __do_softirq+0x6e/0x120
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c01078b1>] do_IRQ+0x41/0x80
[<c0155649>] ? trace_hardirqs_on+0xb9/0x130
[<c01059ca>] common_interrupt+0x2e/0x34
=======================
---[ end trace 97302d8bf57718dd ]---
------------[ cut here ]------------
WARNING: at net/ipv4/tcp_input.c:1767 tcp_enter_frto+0x27c/0x2a0()
Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss eeprom e100 psmouse snd_hda_intel snd_pcm snd_timer btusb rtc_cmos thermal bluetooth rtc_core serio_raw intel_agp button processor sg snd rtc_lib i2c_i801 evdev agpgart soundcore dcdbas 3c59x pcspkr snd_page_alloc
Pid: 0, comm: swapper Not tainted 2.6.24-rc8-mm1 #4
[<c0132100>] ? printk+0x0/0x20
[<c0131834>] warn_on_slowpath+0x54/0x80
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0154972>] ? validate_chain+0x1d2/0x320
[<c0156234>] ? __lock_acquire+0x1e4/0x730
[<c010af95>] ? native_sched_clock+0x85/0xe0
[<c03f58ac>] tcp_enter_frto+0x27c/0x2a0
[<c03ff3c2>] tcp_retransmit_timer+0x102/0x400
[<c043611b>] ? _spin_lock+0x4b/0x80
[<c03ff6d4>] ? tcp_write_timer+0x14/0x110
[<c03ff7b3>] tcp_write_timer+0xf3/0x110
[<c013b94b>] run_timer_softirq+0xbb/0x190
[<c03ff6c0>] ? tcp_write_timer+0x0/0x110
[<c0136f53>] __do_softirq+0x93/0x120
[<c013705a>] do_softirq+0x7a/0x80
[<c0137125>] irq_exit+0x65/0x90
[<c011a91d>] smp_apic_timer_interrupt+0x2d/0x40
[<c0105aab>] apic_timer_interrupt+0x33/0x38
[<c0103390>] ? mwait_idle_with_hints+0x40/0x50
[<c01033a0>] ? mwait_idle+0x0/0x20
[<c01033b2>] mwait_idle+0x12/0x20
[<c0103141>] cpu_idle+0x61/0x110
[<c04333bd>] rest_init+0x5d/0x60
[<c05a47fa>] start_kernel+0x1fa/0x260
[<c05a4190>] ? unknown_bootoption+0x0/0x130
=======================
---[ end trace 97302d8bf57718dd ]---
^ permalink raw reply
* Re: [NET_SCHED 00/09]: sch_ingress cleanups
From: David Miller @ 2008-01-21 8:14 UTC (permalink / raw)
To: hadi; +Cc: kaber, netdev
In-Reply-To: <1200843096.4433.145.camel@localhost>
From: jamal <hadi@cyberus.ca>
Date: Sun, 20 Jan 2008 10:31:36 -0500
> For all patches:
> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca>
All 9 patches applied, thanks.
^ permalink raw reply
* Re: [VLAN 00/18]: Vlan update
From: David Miller @ 2008-01-21 8:34 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <20080120171117.7980.67072.sendpatchset@localhost.localdomain>
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 20 Jan 2008 18:11:17 +0100 (MET)
> the following patches contain a VLAN update for 2.6.25, consisting mainly
> of minor cleanups removing duplicate code, avoiding forward declarations,
> makeing functions static etc. Next I'll look into the skb->cb issues
> with VLAN.
>
> Please apply, thanks.
All applied, thanks.
I wasn't thrilled to see MAC_FMT return, but then again I could
not recommend a better alternative :-)
^ 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