* 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
* Re: [PATCH 2/4] dsmark: get rid of trivial function
From: Ilpo Järvinen @ 2008-01-21 8:39 UTC (permalink / raw)
To: Patrick McHardy, Stephen Hemminger; +Cc: David Miller, Netdev
In-Reply-To: <4793E460.5020804@trash.net>
On Mon, 21 Jan 2008, Patrick McHardy wrote:
> Stephen Hemminger wrote:
> > Replace loop in dsmark_valid_indices with equivalent bit math.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > --- a/net/sched/sch_dsmark.c 2008-01-20 13:07:58.000000000 -0800
> > +++ b/net/sched/sch_dsmark.c 2008-01-20 13:22:54.000000000 -0800
> > @@ -45,13 +45,8 @@ struct dsmark_qdisc_data {
> >
> > static inline int dsmark_valid_indices(u16 indices)
> > {
> > - while (indices != 1) {
> > - if (indices & 1)
> > - return 0;
> > - indices >>= 1;
> > - }
> > -
> > - return 1;
> > + /* Must have only one bit set */
> > + return (indices & (indices - 1)) == 0;
Isn't there some magic under include/linux to do that btw, I suppose
that if the caller side zero check is pushed down there too, the
is_power_of_2() is 100% match? :-)
> hweight seems easier to understand, it took me a bit
> to realize that the comment matches the code :)
In addition, the original seems infinite loop with zero indices given
but luckily that was checked at the caller site already...
--
i.
^ permalink raw reply
* [PATCH]: Fix IWLWIFI mis-merge.
From: David Miller @ 2008-01-21 8:44 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, jgarzik, linville
I just corrected the iwlwifi driver build in the net-2.6.25 tree.
The cause is very simple, the patches applied after Christoph
Hellwig's namespace pollution cleanup to these drivers were not even
build tested.
[IWLWIFI]: Fix up merge errors.
Christoph Hellwig did a driver-wide namespace pollution cleanup
changing iwl_* over to iwl{3945,4965}_*
But subsequent patches to these drivers were not made against that
change and thus kept using the iwl_* names, thus breaking the build.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
index 122d712..dc78fb0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945-rs.c
@@ -560,8 +560,8 @@ static void rs_tx_status(void *priv_rate,
return;
}
-static u16 iwl_get_adjacent_rate(struct iwl_rate_scale_priv *rs_priv,
- u8 index, u16 rate_mask, int phymode)
+static u16 iwl3945_get_adjacent_rate(struct iwl3945_rate_scale_priv *rs_priv,
+ u8 index, u16 rate_mask, int phymode)
{
u8 high = IWL_RATE_INVALID;
u8 low = IWL_RATE_INVALID;
@@ -658,7 +658,7 @@ static void rs_get_rate(void *priv_rate, struct net_device *dev,
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct sta_info *sta;
u16 rate_mask;
- struct iwl_priv *priv = (struct iwl_priv *)priv_rate;
+ struct iwl3945_priv *priv = (struct iwl3945_priv *)priv_rate;
DECLARE_MAC_BUF(mac);
IWL_DEBUG_RATE("enter\n");
@@ -726,7 +726,7 @@ static void rs_get_rate(void *priv_rate, struct net_device *dev,
current_tpt = window->average_tpt;
high_low = iwl3945_get_adjacent_rate(rs_priv, index, rate_mask,
- local->hw.conf.phymode);
+ local->hw.conf.phymode);
low = high_low & 0xff;
high = (high_low >> 8) & 0xff;
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965-rs.c b/drivers/net/wireless/iwlwifi/iwl-4965-rs.c
index 5d6a540..b8f2483 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965-rs.c
@@ -83,7 +83,7 @@ struct iwl4965_rate_scale_data {
/**
* struct iwl4965_scale_tbl_info -- tx params and success history for all rates
*
- * There are two of these in struct iwl_rate_scale_priv,
+ * There are two of these in struct iwl4965_rate_scale_priv,
* one for "active", and one for "search".
*/
struct iwl4965_scale_tbl_info {
@@ -99,7 +99,7 @@ struct iwl4965_scale_tbl_info {
};
/**
- * struct iwl_rate_scale_priv -- driver's rate scaling private structure
+ * struct iwl4965_rate_scale_priv -- driver's rate scaling private structure
*
* Pointer to this gets passed back and forth between driver and mac80211.
*/
@@ -2017,8 +2017,8 @@ static void rs_get_rate(void *priv_rate, struct net_device *dev,
struct ieee80211_conf *conf = &local->hw.conf;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct sta_info *sta;
- struct iwl_priv *priv = (struct iwl_priv *)priv_rate;
- struct iwl_rate_scale_priv *lq;
+ struct iwl4965_priv *priv = (struct iwl4965_priv *)priv_rate;
+ struct iwl4965_rate_scale_priv *lq;
IWL_DEBUG_RATE_LIMIT("rate scale calculate new rate for skb\n");
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 9d38af4..d702662 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -8636,7 +8636,7 @@ static void iwl3945_pci_remove(struct pci_dev *pdev)
set_bit(STATUS_EXIT_PENDING, &priv->status);
- iwl_down(priv);
+ iwl3945_down(priv);
/* Free MAC hash list for ADHOC */
for (i = 0; i < IWL_IBSS_MAC_HASH_SIZE; i++) {
@@ -8698,7 +8698,7 @@ static int iwl3945_pci_suspend(struct pci_dev *pdev, pm_message_t state)
set_bit(STATUS_IN_SUSPEND, &priv->status);
/* Take down the device; powers it off, etc. */
- iwl_down(priv);
+ iwl3945_down(priv);
if (priv->mac80211_registered)
ieee80211_stop_queues(priv->hw);
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c b/drivers/net/wireless/iwlwifi/iwl4965-base.c
index d10f487..4066515 100644
--- a/drivers/net/wireless/iwlwifi/iwl4965-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl4965-base.c
@@ -9206,7 +9206,7 @@ static void iwl4965_pci_remove(struct pci_dev *pdev)
set_bit(STATUS_EXIT_PENDING, &priv->status);
- iwl_down(priv);
+ iwl4965_down(priv);
/* Free MAC hash list for ADHOC */
for (i = 0; i < IWL_IBSS_MAC_HASH_SIZE; i++) {
@@ -9268,7 +9268,7 @@ static int iwl4965_pci_suspend(struct pci_dev *pdev, pm_message_t state)
set_bit(STATUS_IN_SUSPEND, &priv->status);
/* Take down the device; powers it off, etc. */
- iwl_down(priv);
+ iwl4965_down(priv);
if (priv->mac80211_registered)
ieee80211_stop_queues(priv->hw);
^ permalink raw reply related
* Re: [MACVLAN]: Fix thinko in macvlan_transfer_operstate()
From: David Miller @ 2008-01-21 8:47 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <47935EEC.6010402@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 20 Jan 2008 15:47:08 +0100
> [MACVLAN]: Fix thinko in macvlan_transfer_operstate()
>
> When the lower device's carrier is off, the macvlan devices's
> carrier state should be checked to decide whether it needs to
> be turned off. Currently the lower device's state is checked
> a second time.
>
> This still works, but unnecessarily tries to turn off the
> carrier when its already off.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied to net-2.6.25, thanks.
^ permalink raw reply
* Re: [NET_SCHED]: kill obsolete NET_CLS_POLICE option
From: David Miller @ 2008-01-21 8:47 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <47935F30.9080106@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Sun, 20 Jan 2008 15:48:16 +0100
> [NET_SCHED]: kill obsolete NET_CLS_POLICE option
>
> The code is already gone for about half a year, the config option
> has been kept around to select the replacement options for easier
> upgrades. This seems long enough, people upgrading from older
> kernels will have to reconfigure a lot anyway.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied to net-2.6.25
^ permalink raw reply
* Re: [PATCH] ipv6: addrconf sparse warnings
From: David Miller @ 2008-01-21 8:48 UTC (permalink / raw)
To: shemminger; +Cc: yoshfuji, netdev
In-Reply-To: <20080120100140.0f5e2fce@deepthought>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sun, 20 Jan 2008 10:01:40 -0800
> Get rid of a couple of sparse warnings in IPV6 addrconf code.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH 1/4] dsmark: get rid of wrappers
From: David Miller @ 2008-01-21 8:50 UTC (permalink / raw)
To: shemminger; +Cc: kaber, netdev
In-Reply-To: <20080120131008.2039a35d@deepthought>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Sun, 20 Jan 2008 13:10:08 -0800
> Remove extraneous macro wrappers for printk and qdisc_priv.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
APplied.
^ permalink raw reply
* [PATCH 2/2] IPV6: RFC 2011 compatibility broken
From: Wang Chen @ 2008-01-21 9:46 UTC (permalink / raw)
To: David S. Miller; +Cc: David L Stevens, netdev, Herbert Xu
In-Reply-To: <478DD57B.6020503@cn.fujitsu.com>
[IPV6]: RFC 2011 compatibility broken
The snmp6 entry name was changed, and it broke compatibility
to RFC 2011.
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
--- linux-2.6.24.rc8.org/net/ipv6/proc.c 2008-01-16 17:45:03.000000000 +0800
+++ linux-2.6.24.rc8/net/ipv6/proc.c 2008-01-21 15:48:52.000000000 +0800
@@ -88,7 +88,7 @@ static char *icmp6type2name[256] = {
[ICMPV6_PKT_TOOBIG] = "PktTooBigs",
[ICMPV6_TIME_EXCEED] = "TimeExcds",
[ICMPV6_PARAMPROB] = "ParmProblems",
- [ICMPV6_ECHO_REQUEST] = "EchoRequest",
+ [ICMPV6_ECHO_REQUEST] = "Echos",
[ICMPV6_ECHO_REPLY] = "EchoReplies",
[ICMPV6_MGM_QUERY] = "GroupMembQueries",
[ICMPV6_MGM_REPORT] = "GroupMembResponses",
@@ -98,7 +98,7 @@ static char *icmp6type2name[256] = {
[NDISC_ROUTER_SOLICITATION] = "RouterSolicits",
[NDISC_NEIGHBOUR_ADVERTISEMENT] = "NeighborAdvertisements",
[NDISC_NEIGHBOUR_SOLICITATION] = "NeighborSolicits",
- [NDISC_REDIRECT] = "NeighborRedirects",
+ [NDISC_REDIRECT] = "Redirects",
};
^ permalink raw reply
* [PATCH 1/2] IPV6: ICMP6_MIB_OUTMSGS increment duplicated
From: Wang Chen @ 2008-01-21 9:46 UTC (permalink / raw)
To: David S. Miller; +Cc: David L Stevens, netdev, Herbert Xu
In-Reply-To: <478DD57B.6020503@cn.fujitsu.com>
[IPV6]: ICMP6_MIB_OUTMSGS increment duplicated
icmpv6_send() calls ip6_push_pending_frames() indirectly.
Both ip6_push_pending_frames() and icmpv6_send() increment
counter ICMP6_MIB_OUTMSGS.
This patch remove the increment from icmpv6_send.
Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com>
--- linux-2.6.24.rc8.org/net/ipv6/icmp.c 2008-01-16 17:45:03.000000000 +0800
+++ linux-2.6.24.rc8/net/ipv6/icmp.c 2008-01-21 15:56:06.000000000 +0800
@@ -458,8 +458,6 @@ void icmpv6_send(struct sk_buff *skb, in
}
err = icmpv6_push_pending_frames(sk, &fl, &tmp_hdr, len + sizeof(struct icmp6hdr));
- ICMP6_INC_STATS_BH(idev, ICMP6_MIB_OUTMSGS);
-
out_put:
if (likely(idev != NULL))
in6_dev_put(idev);
^ 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