* Re: [PATCH 3/8] netpoll: Fix RCU usage
From: Paul E. McKenney @ 2010-06-11 23:10 UTC (permalink / raw)
To: Herbert Xu
Cc: Michael S. Tsirkin, Qianfeng Zhang, David S. Miller, netdev,
WANG Cong, Stephen Hemminger, Matt Mackall
In-Reply-To: <E1OMtjg-0006Ob-Sb@gondolin.me.apana.org.au>
On Fri, Jun 11, 2010 at 12:12:44PM +1000, Herbert Xu wrote:
> netpoll: Fix RCU usage
>
> The use of RCU in netpoll is incorrect in a number of places:
>
> 1) The initial setting is lacking a write barrier.
> 2) The synchronize_rcu is in the wrong place.
> 3) Read barriers are missing.
> 4) Some places are even missing rcu_read_lock.
> 5) npinfo is zeroed after freeing.
>
> This patch fixes those issues. As most users are in BH context,
> this also converts the RCU usage to the BH variant.
Looks good for me from an RCU viewpoint, but as usual I confess much
ignorance of the surrounding code.
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> ---
>
> include/linux/netpoll.h | 13 ++++++++-----
> net/core/netpoll.c | 20 ++++++++++++--------
> 2 files changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/include/linux/netpoll.h b/include/linux/netpoll.h
> index e9e2312..95c9f7e 100644
> --- a/include/linux/netpoll.h
> +++ b/include/linux/netpoll.h
> @@ -57,12 +57,15 @@ void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb);
> #ifdef CONFIG_NETPOLL
> static inline bool netpoll_rx(struct sk_buff *skb)
> {
> - struct netpoll_info *npinfo = skb->dev->npinfo;
> + struct netpoll_info *npinfo;
> unsigned long flags;
> bool ret = false;
>
> + rcu_read_lock_bh();
> + npinfo = rcu_dereference(skb->dev->npinfo);
> +
> if (!npinfo || (list_empty(&npinfo->rx_np) && !npinfo->rx_flags))
> - return false;
> + goto out;
>
> spin_lock_irqsave(&npinfo->rx_lock, flags);
> /* check rx_flags again with the lock held */
> @@ -70,12 +73,14 @@ static inline bool netpoll_rx(struct sk_buff *skb)
> ret = true;
> spin_unlock_irqrestore(&npinfo->rx_lock, flags);
>
> +out:
> + rcu_read_unlock_bh();
> return ret;
> }
>
> static inline int netpoll_rx_on(struct sk_buff *skb)
> {
> - struct netpoll_info *npinfo = skb->dev->npinfo;
> + struct netpoll_info *npinfo = rcu_dereference(skb->dev->npinfo);
>
> return npinfo && (!list_empty(&npinfo->rx_np) || npinfo->rx_flags);
> }
> @@ -91,7 +96,6 @@ static inline void *netpoll_poll_lock(struct napi_struct *napi)
> {
> struct net_device *dev = napi->dev;
>
> - rcu_read_lock(); /* deal with race on ->npinfo */
> if (dev && dev->npinfo) {
> spin_lock(&napi->poll_lock);
> napi->poll_owner = smp_processor_id();
> @@ -108,7 +112,6 @@ static inline void netpoll_poll_unlock(void *have)
> napi->poll_owner = -1;
> spin_unlock(&napi->poll_lock);
> }
> - rcu_read_unlock();
> }
>
> #else
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index 748c930..4b7623d 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -292,6 +292,7 @@ void netpoll_send_skb(struct netpoll *np, struct sk_buff *skb)
> unsigned long tries;
> struct net_device *dev = np->dev;
> const struct net_device_ops *ops = dev->netdev_ops;
> + /* It is up to the caller to keep npinfo alive. */
> struct netpoll_info *npinfo = np->dev->npinfo;
>
> if (!npinfo || !netif_running(dev) || !netif_device_present(dev)) {
> @@ -841,10 +842,7 @@ int netpoll_setup(struct netpoll *np)
> refill_skbs();
>
> /* last thing to do is link it to the net device structure */
> - ndev->npinfo = npinfo;
> -
> - /* avoid racing with NAPI reading npinfo */
> - synchronize_rcu();
> + rcu_assign_pointer(ndev->npinfo, npinfo);
>
> return 0;
>
> @@ -888,6 +886,16 @@ void netpoll_cleanup(struct netpoll *np)
>
> if (atomic_dec_and_test(&npinfo->refcnt)) {
> const struct net_device_ops *ops;
> +
> + ops = np->dev->netdev_ops;
> + if (ops->ndo_netpoll_cleanup)
> + ops->ndo_netpoll_cleanup(np->dev);
> +
> + rcu_assign_pointer(np->dev->npinfo, NULL);
> +
> + /* avoid racing with NAPI reading npinfo */
> + synchronize_rcu_bh();
> +
> skb_queue_purge(&npinfo->arp_tx);
> skb_queue_purge(&npinfo->txq);
> cancel_rearming_delayed_work(&npinfo->tx_work);
> @@ -895,10 +903,6 @@ void netpoll_cleanup(struct netpoll *np)
> /* clean after last, unfinished work */
> __skb_queue_purge(&npinfo->txq);
> kfree(npinfo);
> - ops = np->dev->netdev_ops;
> - if (ops->ndo_netpoll_cleanup)
> - ops->ndo_netpoll_cleanup(np->dev);
> - np->dev->npinfo = NULL;
> }
> }
>
^ permalink raw reply
* [net-2.6 PATCH] e1000: Fix message logging defect
From: Jeff Kirsher @ 2010-06-11 22:51 UTC (permalink / raw)
To: davem; +Cc: netdev, gospo, Joe Perches, Jeff Kirsher
From: Joe Perches <joe@perches.com>
commit 675ad47375c76a7c3be4ace9554d92cd55518ced
removed the capability to use ethtool.set_msglevel to
control the types of messages emitted by the driver.
That commit should probably be reverted.
If not, then this patch fixes a message logging defect
introduced by converting a printk without KERN_<level>
to e_info.
This also reduces text by about 200 bytes.
Signed-off-by: Joe Perches <joe@perches.com>
Tested-by: Emil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/e1000/e1000_main.c | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index ebdea08..68a8089 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1047,15 +1047,14 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
goto err_register;
/* print bus type/speed/width info */
- e_info("(PCI%s:%s:%s) ",
- ((hw->bus_type == e1000_bus_type_pcix) ? "-X" : ""),
- ((hw->bus_speed == e1000_bus_speed_133) ? "133MHz" :
- (hw->bus_speed == e1000_bus_speed_120) ? "120MHz" :
- (hw->bus_speed == e1000_bus_speed_100) ? "100MHz" :
- (hw->bus_speed == e1000_bus_speed_66) ? "66MHz" : "33MHz"),
- ((hw->bus_width == e1000_bus_width_64) ? "64-bit" : "32-bit"));
-
- e_info("%pM\n", netdev->dev_addr);
+ e_info("(PCI%s:%dMHz:%d-bit) %pM\n",
+ ((hw->bus_type == e1000_bus_type_pcix) ? "-X" : ""),
+ ((hw->bus_speed == e1000_bus_speed_133) ? 133 :
+ (hw->bus_speed == e1000_bus_speed_120) ? 120 :
+ (hw->bus_speed == e1000_bus_speed_100) ? 100 :
+ (hw->bus_speed == e1000_bus_speed_66) ? 66 : 33),
+ ((hw->bus_width == e1000_bus_width_64) ? 64 : 32),
+ netdev->dev_addr);
/* carrier off reporting is important to ethtool even BEFORE open */
netif_carrier_off(netdev);
^ permalink raw reply related
* [net-2.6 PATCH] ixgbe: fix automatic LRO/RSC settings for low latency
From: Jeff Kirsher @ 2010-06-11 22:47 UTC (permalink / raw)
To: davem
Cc: netdev, gospo, Andy Gospodarek, Stanislaw Gruszka, stable,
Jeff Kirsher
From: Andy Gospodarek <andy@greyhouse.net>
This patch added to 2.6.34:
commit f8d1dcaf88bddc7f282722ec1fdddbcb06a72f18
Author: Jesse Brandeburg <jesse.brandeburg@intel.com>
Date: Tue Apr 27 01:37:20 2010 +0000
ixgbe: enable extremely low latency
introduced a feature where LRO (called RSC on the hardware) was disabled
automatically when setting rx-usecs to 0 via ethtool. Some might not
like the fact that LRO was disabled automatically, but I'm fine with
that. What I don't like is that LRO/RSC is automatically enabled when
rx-usecs is set >0 via ethtool.
This would certainly be a problem if the device was used for forwarding
and it was determined that the low latency wasn't needed after the
device was already forwarding. I played around with saving the state of
LRO in the driver, but it just didn't seem worthwhile and would require
a small change to dev_disable_lro() that I did not like.
This patch simply leaves LRO disabled when setting rx-usecs >0 and
requires that the user enable it again. An extra informational message
will also now appear in the log so users can understand why LRO isn't
being enabled as they expect.
Inconsistency of LRO setting first noticed by Stanislaw Gruszka.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
CC: Stanislaw Gruszka <sgruszka@redhat.com>
CC: stable@kernel.org
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ixgbe/ixgbe_ethtool.c | 37 ++++++++-----------------------------
1 files changed, 8 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethtool.c b/drivers/net/ixgbe/ixgbe_ethtool.c
index c50a754..3a93a81 100644
--- a/drivers/net/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ixgbe/ixgbe_ethtool.c
@@ -2077,25 +2077,6 @@ static int ixgbe_get_coalesce(struct net_device *netdev,
return 0;
}
-/*
- * this function must be called before setting the new value of
- * rx_itr_setting
- */
-static bool ixgbe_reenable_rsc(struct ixgbe_adapter *adapter,
- struct ethtool_coalesce *ec)
-{
- /* check the old value and enable RSC if necessary */
- if ((adapter->rx_itr_setting == 0) &&
- (adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE)) {
- adapter->flags2 |= IXGBE_FLAG2_RSC_ENABLED;
- adapter->netdev->features |= NETIF_F_LRO;
- DPRINTK(PROBE, INFO, "rx-usecs set to %d, re-enabling RSC\n",
- ec->rx_coalesce_usecs);
- return true;
- }
- return false;
-}
-
static int ixgbe_set_coalesce(struct net_device *netdev,
struct ethtool_coalesce *ec)
{
@@ -2124,9 +2105,6 @@ static int ixgbe_set_coalesce(struct net_device *netdev,
(1000000/ec->rx_coalesce_usecs < IXGBE_MIN_INT_RATE))
return -EINVAL;
- /* check the old value and enable RSC if necessary */
- need_reset = ixgbe_reenable_rsc(adapter, ec);
-
/* store the value in ints/second */
adapter->rx_eitr_param = 1000000/ec->rx_coalesce_usecs;
@@ -2135,9 +2113,6 @@ static int ixgbe_set_coalesce(struct net_device *netdev,
/* clear the lower bit as its used for dynamic state */
adapter->rx_itr_setting &= ~1;
} else if (ec->rx_coalesce_usecs == 1) {
- /* check the old value and enable RSC if necessary */
- need_reset = ixgbe_reenable_rsc(adapter, ec);
-
/* 1 means dynamic mode */
adapter->rx_eitr_param = 20000;
adapter->rx_itr_setting = 1;
@@ -2157,10 +2132,11 @@ static int ixgbe_set_coalesce(struct net_device *netdev,
*/
if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED) {
adapter->flags2 &= ~IXGBE_FLAG2_RSC_ENABLED;
- netdev->features &= ~NETIF_F_LRO;
- DPRINTK(PROBE, INFO,
- "rx-usecs set to 0, disabling RSC\n");
-
+ if (netdev->features & NETIF_F_LRO) {
+ netdev->features &= ~NETIF_F_LRO;
+ DPRINTK(PROBE, INFO, "rx-usecs set to 0, "
+ "disabling LRO/RSC\n");
+ }
need_reset = true;
}
}
@@ -2255,6 +2231,9 @@ static int ixgbe_set_flags(struct net_device *netdev, u32 data)
}
} else if (!adapter->rx_itr_setting) {
netdev->features &= ~ETH_FLAG_LRO;
+ if (data & ETH_FLAG_LRO)
+ DPRINTK(PROBE, INFO, "rx-usecs set to 0, "
+ "LRO/RSC cannot be enabled.\n");
}
}
^ permalink raw reply related
* [PATCH] gianfar: Fix oversized packets handling
From: Anton Vorontsov @ 2010-06-11 20:51 UTC (permalink / raw)
To: David Miller; +Cc: Sandeep Gopalpet, Andy Fleming, netdev, linuxppc-dev
Issuing the following command on host:
$ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1
Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0)
oops like this:
skb_over_panic: text:c0195914 len:1537 put:1537 head:c79e4800 data:c79e4880 tail:0xc79e4e81 end:0xc79e4e80 dev:eth1
------------[ cut here ]------------
kernel BUG at net/core/skbuff.c:127!
Oops: Exception in kernel mode, sig: 5 [#1]
MPC831x RDB
last sysfs file: /sys/kernel/uevent_seqnum
Modules linked in:
NIP: c01c1840 LR: c01c1840 CTR: c016d918
[...]
NIP [c01c1840] skb_over_panic+0x48/0x5c
LR [c01c1840] skb_over_panic+0x48/0x5c
Call Trace:
[c0339d50] [c01c1840] skb_over_panic+0x48/0x5c (unreliable)
[c0339d60] [c01c3020] skb_put+0x5c/0x60
[c0339d70] [c0195914] gfar_clean_rx_ring+0x25c/0x3d0
[c0339dc0] [c01976e8] gfar_poll+0x170/0x1bc
Dumped buffer descriptors showed that eTSEC's length/truncation
logic sometimes passes oversized packets, i.e. for the above ICMP
packet the following two buffer descriptors may become ready:
status=1400 length=1536
status=1800 length=1541
So, it seems that gianfar actually receives the whole big frame,
and it tries to place the packet into two BDs. This situation
confuses the driver, and so the skb_put() sanity check fails.
This patch fixes the issue by adding an appropriate check, i.e.
the driver should not try to process frames with buffer
descriptor's length over rx_buffer_size (i.e. maxfrm and mrblr).
Note that sometimes eTSEC works correctly, i.e. in the second
(last) buffer descriptor bits 'truncated' and 'crcerr' are set,
and so there's no oops. Though I couldn't find any logic when
it works correctly and when not.
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 46c69cd..7c31f0f 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -2642,6 +2642,10 @@ int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit)
dma_unmap_single(&priv->ofdev->dev, bdp->bufPtr,
priv->rx_buffer_size, DMA_FROM_DEVICE);
+ if (unlikely(!(bdp->status & RXBD_ERR) &&
+ bdp->length > priv->rx_buffer_size))
+ bdp->status = RXBD_LARGE;
+
/* We drop the frame if we failed to allocate a new buffer */
if (unlikely(!newskb || !(bdp->status & RXBD_LAST) ||
bdp->status & RXBD_ERR)) {
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH 1/4][RFC] Introduction to sk_buff state checking
From: David VomLehn @ 2010-06-11 20:50 UTC (permalink / raw)
To: David Miller; +Cc: to, linux-kernel, akpm, netdev
In-Reply-To: <20100611.133811.52184181.davem@davemloft.net>
On Fri, Jun 11, 2010 at 01:38:11PM -0700, David Miller wrote:
>
> This is the second time you've submitted this patch set,
There are changes, based on the feedback I got.
> it is also the second time that:
>
> 1) Your email client has emitted these strange
> "linux-kernel@vger.kernel.org"@cisco.com
> addresses.
>
> I saw that you were specifically notified about this
> problem during the previous submission.
>
> What did you do to try and correct it?
>
> 2) You are not CC:'ing the networking developer mailing
> list "netdev@vger.kernel.org" Many networking developers
> do not read linux-kernel, so by not CC:'ing that list
> you are not reaching the folks most capable of reviewing
> your patches.
All true, and I apologize. I know there's enough traffic on kernel mailing
lists as it is.
> Please fix this up.
Working on it now.
--
David VL
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Joakim Tjernlund @ 2010-06-11 20:46 UTC (permalink / raw)
To: Mitchell Erblich; +Cc: netdev, Rick Jones
In-Reply-To: <2297DADB-883E-4156-998A-854BE6CAC079@earthlink.net>
Mitchell Erblich <erblichs@earthlink.net> wrote on 2010/06/11 21:50:14:
>
>
> On Jun 11, 2010, at 10:06 AM, Joakim Tjernlund wrote:
>
> > Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
> >> Joakim Tjernlund wrote:
> >>> Linux uses the weak host model which makes the IP addresses part of the system
> >>> rather than the interface. However consider this:
> >>>
> >>> System A, eth0 connected to the network
> >>> # > ifconfig eth0 192.168.1.16
> >>> # > ifconfig eth1 192.168.1.17 down
> >>>
> >>> System B
> >>> # > ping 192.168.1.17
> >>> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> >>> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> >>>
> >>> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
> >>
> >> As you said at the beginning, the weak end system model presumes the IP address
> >> is part of the system. Seems to me that means unless one removes the IP address
> >> from the system it is reasonable for the system to continue to respond to that
> >> IP address. Regardless of what happens to any individual interface.
> >
> > The weak model doesn't go into such detail, it is assumption/impl. detail
> > to assume that the ip address still is part of the system even when the interface
> > is down. One could just as well define interface down as temporarly removing
> > the IP address from the system too. This makes make much more sense to me and
> > if you always want the system to answer on a IP adress you make it an IP alias.
> >
> > Since the current behaviour is a problem to me and routers in general, can
> > we change this? What is the current usage model which needs it to stay as is?
> >
> >>
> >> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
> >> but if eth0 is indeed connected to the same broadcast domain, given the
> >> following of the weak end-system model, continuing to respond seems consistent
> >> with enthusiasticaly following the weak end-system model.
> >
> > Dosnt matter if it is in the same broadcast domain, you can use a bridge
> > interface or dummy interface too. It will still respond to 192.168.1.17
> > I can't find a way disable this behaviour, can you?
> >
> > --
>
> Guys
>
> Isn't this the diff between models of a host/end system and a
> router/intermediate system?
Not sure what you mean here, but there is no such assumtion in
the models.
>
> Can you verify that xmit capability on the intf is disabled with the
> down arg?
umm, isn't that true by definition? if an I/F is put into down state, it
cannot xmit nor receive.
>
> IMO, One possible behaviour is to allow the receipt of a magic
> packet to bring up a down system for the "energy star protocol".
isn't that something totally different? I cannot se how that relates
to the matter at hand.
Jocke
^ permalink raw reply
* Re: [PATCH 1/4][RFC] Introduction to sk_buff state checking
From: Randy Dunlap @ 2010-06-11 20:46 UTC (permalink / raw)
To: David Miller; +Cc: dvomlehn, to, linux-kernel, akpm, netdev
In-Reply-To: <20100611.133811.52184181.davem@davemloft.net>
On Fri, 11 Jun 2010 13:38:11 -0700 (PDT) David Miller wrote:
>
> This is the second time you've submitted this patch set,
> it is also the second time that:
>
> 1) Your email client has emitted these strange
> "linux-kernel@vger.kernel.org"@cisco.com
> addresses.
>
> I saw that you were specifically notified about this
> problem during the previous submission.
>
> What did you do to try and correct it?
>
> 2) You are not CC:'ing the networking developer mailing
> list "netdev@vger.kernel.org" Many networking developers
> do not read linux-kernel, so by not CC:'ing that list
> you are not reaching the folks most capable of reviewing
> your patches.
>
> Please fix this up.
> --
Ack. Also this one:
----- The following addresses had permanent fatal errors -----
<to@dvomlehn-lnx2.corp.sa.net>
(reason: 550 Host unknown)
----- Transcript of session follows -----
550 5.1.2 <to@dvomlehn-lnx2.corp.sa.net>... Host unknown (Name server: dvomlehn-lnx2.corp.sa.net: host not found)
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 1/4][RFC] Introduction to sk_buff state checking
From: David Miller @ 2010-06-11 20:38 UTC (permalink / raw)
To: dvomlehn; +Cc: to, linux-kernel, akpm, netdev
In-Reply-To: <20100611203350.GA28383@dvomlehn-lnx2.corp.sa.net>
This is the second time you've submitted this patch set,
it is also the second time that:
1) Your email client has emitted these strange
"linux-kernel@vger.kernel.org"@cisco.com
addresses.
I saw that you were specifically notified about this
problem during the previous submission.
What did you do to try and correct it?
2) You are not CC:'ing the networking developer mailing
list "netdev@vger.kernel.org" Many networking developers
do not read linux-kernel, so by not CC:'ing that list
you are not reaching the folks most capable of reviewing
your patches.
Please fix this up.
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Johannes Berg @ 2010-06-11 20:29 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Valo, GeunSik Lim, Kroah-Hartman, Jiri Slaby, Jiri Kosina,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, John W. Linville, Keng-Yu Lin,
Greg-juf53994utBLZpfksSYvnA, netdev-u79uwXL29TY76Z2rM5mHXA,
Kalle-juf53994utBLZpfksSYvnA, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <AANLkTim90VBfWjp2YPYeYN6ImjIyZzcJ_XnpT5cdgCt4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 2010-06-11 at 23:26 +0300, Dmytro Milinevskyy wrote:
> Generic LED class is not disabled so it's possible to control leds in sysfs.
But if you turn off ATH5K_LEDS??
johannes
^ permalink raw reply
* Re: [PATCH 1/7] ethoc: calculate number of buffers in ethoc_probe
From: David Miller @ 2010-06-11 20:29 UTC (permalink / raw)
To: jonas; +Cc: netdev
In-Reply-To: <1276260460-14531-1-git-send-email-jonas@southpole.se>
I've applied all 7 patches to net-next-2.6, thanks Jonas.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-11 20:26 UTC (permalink / raw)
To: Johannes Berg
Cc: Bob Copeland, ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, Kalle Valo,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, GeunSik Lim, Jiri Slaby,
Greg Kroah-Hartman, John W. Linville, Keng-Yu Lin,
netdev-u79uwXL29TY76Z2rM5mHXA, Jiri Kosina, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <1276286993.3918.0.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
Generic LED class is not disabled so it's possible to control leds in sysfs.
-- Dima
On Fri, Jun 11, 2010 at 11:09 PM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> On Wed, 2010-06-09 at 17:43 +0300, Dmytro Milinevskyy wrote:
>> Hi, Bob.
>>
>> For instance I don't use 802.11 leds layer and trigger leds from
>> userspace according to my purposes.
>
> Without the LED stuff in sysfs, how do you do that?
>
> johannes
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Johannes Berg @ 2010-06-11 20:09 UTC (permalink / raw)
To: Dmytro Milinevskyy
Cc: Valo, GeunSik Lim, Kroah-Hartman, Jiri Slaby, Jiri Kosina,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath5k-devel-xDcbHBWguxEUs3QNXV6qNA, John W. Linville, Keng-Yu Lin,
Greg-juf53994utBLZpfksSYvnA, netdev-u79uwXL29TY76Z2rM5mHXA,
Kalle-juf53994utBLZpfksSYvnA, Shahar Or,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Luca Verdesca
In-Reply-To: <AANLkTimXqdkQxv_Y1JaleTTWNsDIQHQaPn8HR7efOupb-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 2010-06-09 at 17:43 +0300, Dmytro Milinevskyy wrote:
> Hi, Bob.
>
> For instance I don't use 802.11 leds layer and trigger leds from
> userspace according to my purposes.
Without the LED stuff in sysfs, how do you do that?
johannes
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2010-06-11 20:05 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) As alluded to in the previous networking pull, for correct
operation r8169 needs a post-mdio-read delay just as it needs one
for post-mdio-write. From Timo Teräs.
2) 8139 driver's NAPI completion is racy, the sequence for completing
a NAPI poll should be:
napi_complete()
reenable_interrupts(dev);
But these driver bits had the ordering reversed. If the race is
triggered, NAPI can be left disabled forever and therefore no
more RX packets will be received until a down/up of the device.
3) When a multiqueue device is plumbed into a non-multiqueue-capable
SW layer (bonding, bridging, etc.) we print a warning about the RX
queue selection being "out of range", which is not very useful
since we are aware of this issue. All it does is spam the log and
make life difficult for the user. Only print the message in cases
where there is real trouble.
From Tim Gardner.
4) LXT973 phy support from Richard Cochran.
5) CAIF protocol has tests like:
if (!x > y)
which are clearly bogus, fixes from Dan Carpenter.
6) HW timestamping support broke RX on some gianfar chips, turn the
feature off for now until we can understand the issue better. From
Anton Vorontsov.
7) IPV6 icmp bumps wrong stat counters due to typos in a 2.6.35 change,
fix from Eric Dumazet.
8) When a hw accelerated VLAN interface is hooked up to a bond, the
packet dropping behavior for inactive bonding slaves erroneously
changes compared to what happens with all other kinds of devices.
Fix by tracking whether the packet should be dropped inside of the
SKB so layers can communicate that they've done the bonding check
already. Fix from John Fastabend.
9) Packet rate estimator lacks sufficient SMP locking. The basic
assumption was that the RTNL would be held when estimators are
created or destroyed, but that doesn't happen in some cases, in
particular the xt_RATEEST netfilter module does not do this.
Adding RTNL to those spots is non-trivial and would actually cause
more problems than it would fix. So add a new spinlock to protect
the critical insert/delete/search operations.
Fix from Eric Dumazet.
10) pktgen miscalculates inter-packet delays, basically the old calculation
was:
wait_until(next_time);
now = get_time();
state->next_time = now + state->delay;
we fix it to be:
wait_until(next_time);
state->next_time = next_time + state->delay;
From Daniel Turull.
11) Missing endianness conversion in firmware header field in wimax driver,
from Inaky Perez-Gonzalez.
Please pull, thanks a lot!
The following changes since commit 7908a9e5fc3f9a679b1777ed231a03636c068446:
Linus Torvalds (1):
Merge branch 'kvm-updates/2.6.35' of git://git.kernel.org/pub/scm/virt/kvm/kvm
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Anton Vorontsov (1):
gianfar: Revive the driver for eTSEC devices (disable timestamping)
Dan Carpenter (1):
caif: fix a couple range checks
Daniel Turull (1):
pktgen: Fix accuracy of inter-packet delay.
David S. Miller (2):
Merge branch 'num_rx_queues' of git://kernel.ubuntu.com/rtg/net-2.6
Merge branch 'wimax-2.6.35.y' of git://git.kernel.org/.../inaky/wimax
Eric Dumazet (2):
ipv6: fix ICMP6_MIB_OUTERRORS
pkt_sched: gen_estimator: add a new lock
Figo.zhang (1):
net8139: fix a race at the end of NAPI
Inaky Perez-Gonzalez (1):
wimax/i2400m: fix missing endian correction read in fw loader
John Fastabend (1):
net: deliver skbs on inactive slaves to exact matches
Richard Cochran (1):
phylib: Add support for the LXT973 phy.
Tim Gardner (1):
net: Print num_rx_queues imbalance warning only when there are allocated queues
Timo Teräs (1):
r8169: fix mdio_read and update mdio_write according to hw specs
drivers/net/8139cp.c | 2 +-
drivers/net/8139too.c | 2 +-
drivers/net/gianfar.c | 3 +-
drivers/net/phy/lxt.c | 51 ++++++++++++++++++++++++++++++++++++++++-
drivers/net/r8169.c | 12 +++++++--
drivers/net/wimax/i2400m/fw.c | 2 +-
include/linux/skbuff.h | 5 +++-
net/8021q/vlan_core.c | 4 +-
net/caif/cfrfml.c | 2 +-
net/caif/cfveil.c | 2 +-
net/core/dev.c | 25 +++++++++++++------
net/core/gen_estimator.c | 15 +++++++++--
net/core/pktgen.c | 2 +-
net/ipv6/icmp.c | 4 +-
14 files changed, 103 insertions(+), 28 deletions(-)
^ permalink raw reply
* Re: [0/8] netpoll/bridge fixes
From: Matt Mackall @ 2010-06-11 20:03 UTC (permalink / raw)
To: Herbert Xu
Cc: Stephen Hemminger, Michael S. Tsirkin, Qianfeng Zhang,
David S. Miller, netdev, WANG Cong
In-Reply-To: <20100611021142.GA24490@gondor.apana.org.au>
On Fri, 2010-06-11 at 12:11 +1000, Herbert Xu wrote:
> On Fri, Jun 11, 2010 at 08:48:39AM +1000, Herbert Xu wrote:
> > On Thu, Jun 10, 2010 at 02:59:15PM -0700, Stephen Hemminger wrote:
> > >
> > > Okay, then add a comment where in_irq is used?
> >
> > Actually let me put it into a wrapper. I'll respin the patches.
>
> OK here is a repost. And this time it really is 8 patches :)
> I've tested it lightly.
These all look very nice to me, thanks for digging into this.
Acked-by: Matt Mackall <mpm@selenic.com>
Hopefully we'll also get an ack from Wang Cong on them and another test
result.
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: [ath5k-devel] [PATCH] [ath5k][leds] Ability to disable leds support. If leds support enabled do not force mac802.11 leds layer selection.
From: Dmytro Milinevskyy @ 2010-06-11 19:52 UTC (permalink / raw)
To: Bob Copeland
Cc: Kalle Valo, GeunSik Lim, Greg Kroah-Hartman, Jiri Slaby, netdev,
ath5k-devel, linux-wireless, John W. Linville, Keng-Yu Lin,
Jiri Kosina, Shahar Or, linux-kernel, Luca Verdesca
In-Reply-To: <AANLkTimUW58T19GOkRk3oCC9huLDQLgLj4W3RjiQ9n53@mail.gmail.com>
I didn't know. Thank you for noting that.
However I think it's better to give a chance to disable 802.11 leds.
-- Dima
On Fri, Jun 11, 2010 at 8:07 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Wed, Jun 9, 2010 at 10:43 AM, Dmytro Milinevskyy
> <milinevskyy@gmail.com> wrote:
>> Hi, Bob.
>>
>> For instance I don't use 802.11 leds layer and trigger leds from
>> userspace according to my purposes.
>
> FWIW you can disable mac80211 triggers from userspace as well.
> But, I guess hooking up null triggers will work too.
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Mitchell Erblich @ 2010-06-11 19:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Rick Jones, netdev
In-Reply-To: <OFE6F71D1A.A94BE06C-ONC125773F.005C80CF-C125773F.005DF884@transmode.se>
On Jun 11, 2010, at 10:06 AM, Joakim Tjernlund wrote:
> Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
>> Joakim Tjernlund wrote:
>>> Linux uses the weak host model which makes the IP addresses part of the system
>>> rather than the interface. However consider this:
>>>
>>> System A, eth0 connected to the network
>>> # > ifconfig eth0 192.168.1.16
>>> # > ifconfig eth1 192.168.1.17 down
>>>
>>> System B
>>> # > ping 192.168.1.17
>>> PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
>>> 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
>>>
>>> Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
>>
>> As you said at the beginning, the weak end system model presumes the IP address
>> is part of the system. Seems to me that means unless one removes the IP address
>> from the system it is reasonable for the system to continue to respond to that
>> IP address. Regardless of what happens to any individual interface.
>
> The weak model doesn't go into such detail, it is assumption/impl. detail
> to assume that the ip address still is part of the system even when the interface
> is down. One could just as well define interface down as temporarly removing
> the IP address from the system too. This makes make much more sense to me and
> if you always want the system to answer on a IP adress you make it an IP alias.
>
> Since the current behaviour is a problem to me and routers in general, can
> we change this? What is the current usage model which needs it to stay as is?
>
>>
>> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
>> but if eth0 is indeed connected to the same broadcast domain, given the
>> following of the weak end-system model, continuing to respond seems consistent
>> with enthusiasticaly following the weak end-system model.
>
> Dosnt matter if it is in the same broadcast domain, you can use a bridge
> interface or dummy interface too. It will still respond to 192.168.1.17
> I can't find a way disable this behaviour, can you?
>
> --
Guys
Isn't this the diff between models of a host/end system and a
router/intermediate system?
Can you verify that xmit capability on the intf is disabled with the
down arg?
IMO, One possible behaviour is to allow the receipt of a magic
packet to bring up a down system for the "energy star protocol".
Mitchell Erblich
> 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] drivers/net/e1000/e1000_main.c: Fix message logging defect
From: Jeff Kirsher @ 2010-06-11 19:46 UTC (permalink / raw)
To: Joe Perches; +Cc: Emil Tantilov, netdev, e1000-devel, LKML
In-Reply-To: <1276237773.1556.507.camel@Joe-Laptop.home>
On Thu, Jun 10, 2010 at 23:29, Joe Perches <joe@perches.com> wrote:
> commit 675ad47375c76a7c3be4ace9554d92cd55518ced
> removed the capability to use ethtool.set_msglevel to
> control the types of messages emitted by the driver.
>
> That commit should probably be reverted.
>
> If not, then this patch fixes a message logging defect
> introduced by converting a printk without KERN_<level>
> to e_info.
>
> This also reduces text by about 200 bytes.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
Thanks Joe. I have added the patch to my queue.
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Joakim Tjernlund @ 2010-06-11 19:41 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4C126EC6.9000506@hp.com>
Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 19:13:42:
>
> > The weak model doesn't go into such detail, it is assumption/impl. detail
> > to assume that the ip address still is part of the system even when the interface
> > is down. One could just as well define interface down as temporarly removing
> > the IP address from the system too. This makes make much more sense to me and
> > if you always want the system to answer on a IP adress you make it an IP alias.
> >
> > Since the current behaviour is a problem to me and routers in general, can
> > we change this? What is the current usage model which needs it to stay as is?
>
> Router != end-system so I wouldn't think the weak or strong end-system model
> would apply to a router. I think Stephen already posted a patch to allow that
> for when one's box was a router rather than an end-system.
Not really an anwser to what I was asking but I choose to read that as
you agree with me. The rest is an impl. detail. :)
Stephen's patch is good but I would not mind making I/F down removing the
IP address from the system unconditionally.
Jocke
^ permalink raw reply
* Re: [patch 2.6.35] WiMAX pull request
From: David Miller @ 2010-06-11 19:39 UTC (permalink / raw)
To: inaky; +Cc: netdev, wimax, inaky.perez-gonzalez
In-Reply-To: <cover.1276282933.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Fri, 11 Jun 2010 12:03:05 -0700
> From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
>
> The following changes since commit 3a24934f065d23145f1c9c70da9f630c7a37795f:
> Inaky Perez-Gonzalez (1):
> wimax/i2400m: fix bad race condition check in RX path
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
Pulled, thanks a lot.
^ permalink raw reply
* [patch 2.6.35] WiMAX pull request
From: Inaky Perez-Gonzalez @ 2010-06-11 19:03 UTC (permalink / raw)
To: netdev, wimax; +Cc: Inaky Perez-Gonzalez
From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
The following changes since commit 3a24934f065d23145f1c9c70da9f630c7a37795f:
Inaky Perez-Gonzalez (1):
wimax/i2400m: fix bad race condition check in RX path
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax.git wimax-2.6.35.y
Patches follow for reviewing convenience.
Inaky Perez-Gonzalez (1):
wimax/i2400m: fix missing endian correction read in fw loader
drivers/net/wimax/i2400m/fw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
^ permalink raw reply
* [patch 2.6.35] wimax/i2400m: fix missing endian correction read in fw loader
From: Inaky Perez-Gonzalez @ 2010-06-11 19:03 UTC (permalink / raw)
To: netdev, wimax
In-Reply-To: <cover.1276282933.git.inaky.perez-gonzalez@intel.com>
From: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
i2400m_fw_hdr_check() was accessing hardware field
bcf_hdr->module_type (little endian 32) without converting to host
byte sex.
Reported-by: Данилин Михаил <mdanilin@nsg.net.ru>
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
---
drivers/net/wimax/i2400m/fw.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index 3f283bf..1149135 100644
--- a/drivers/net/wimax/i2400m/fw.c
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -1192,7 +1192,7 @@ int i2400m_fw_hdr_check(struct i2400m *i2400m,
unsigned module_type, header_len, major_version, minor_version,
module_id, module_vendor, date, size;
- module_type = bcf_hdr->module_type;
+ module_type = le32_to_cpu(bcf_hdr->module_type);
header_len = sizeof(u32) * le32_to_cpu(bcf_hdr->header_len);
major_version = (le32_to_cpu(bcf_hdr->header_version) & 0xffff0000)
>> 16;
--
1.6.6.1
_______________________________________________
wimax mailing list
wimax@linuxwimax.org
http://lists.linuxwimax.org/listinfo/wimax
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2010-06-09
From: David Miller @ 2010-06-11 18:34 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100609211251.GC2452-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 9 Jun 2010 17:12:51 -0400
> Dave,
>
> Here is the usual, frightening, monstrous post-window pull request...
> Along with the usual batch of driver updates, there are also some DMA
> state API conversions from FUJITA Tomonori, some cleanups from Julia
> Lawall and Joe Perches, some SSB changes from Larry Finger and Rafał
> Miłecki, and a number of mac80211 changes from Johannes Berg. All of it
> has had at least one cycle through linux-next and most of it has been
> there for several days. This also includes the same wireless-2.6 pull I
> sent you previously so as to resolve some merge conflicts.
>
> Please let me know if there are problems!
Pulled, thanks JOhn.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Fw: [Bug 16183] New: sch_teql no longer works post 2.6.30
From: Eric Dumazet @ 2010-06-11 17:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20100611090835.31b8436c@nehalam>
Le vendredi 11 juin 2010 à 09:08 -0700, Stephen Hemminger a écrit :
>
> Begin forwarded message:
>
> Date: Fri, 11 Jun 2010 15:56:44 GMT
> From: bugzilla-daemon@bugzilla.kernel.org
> To: shemminger@linux-foundation.org
> Subject: [Bug 16183] New: sch_teql no longer works post 2.6.30
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16183
>
> Summary: sch_teql no longer works post 2.6.30
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.31 through 2.6.34
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: tom@compton.nu
> Regression: Yes
>
>
> Created an attachment (id=26729)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=26729)
> Patch to fix sch_teql
>
> The sch_teql module, which can be used to load balance over a set of underlying
> interfaces, stopped working after 2.6.30 and has been broken in all kernels
> since then.
>
> The problem is that the transmit routine relies on being able to access the
> destination address in the skb in order to do ARP resolution once it has
> decided which underlying interface it is going to transmit through.
>
> In 2.6.31 the IFF_XMIT_DST_RELEASE flag was introduced, and set by default for
> all interfaces, which causes the destination address to be release before the
> transmit routine for the interface is called.
>
> The solution (implemented in the attached patch) is to clear that flag for teql
> interfaces.
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
>
>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Please note my old email address no longer works ;)
Thanks
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Rick Jones @ 2010-06-11 17:13 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OFE6F71D1A.A94BE06C-ONC125773F.005C80CF-C125773F.005DF884@transmode.se>
> The weak model doesn't go into such detail, it is assumption/impl. detail
> to assume that the ip address still is part of the system even when the interface
> is down. One could just as well define interface down as temporarly removing
> the IP address from the system too. This makes make much more sense to me and
> if you always want the system to answer on a IP adress you make it an IP alias.
>
> Since the current behaviour is a problem to me and routers in general, can
> we change this? What is the current usage model which needs it to stay as is?
Router != end-system so I wouldn't think the weak or strong end-system model
would apply to a router. I think Stephen already posted a patch to allow that
for when one's box was a router rather than an end-system.
rick jones
It's a router!
No, it's an end-system!
...
http://snltranscripts.jt.org/75/75ishimmer.phtml
^ permalink raw reply
* Re: Weak host model vs .interface down
From: Joakim Tjernlund @ 2010-06-11 17:06 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4C126514.30905@hp.com>
Rick Jones <rick.jones2@hp.com> wrote on 2010/06/11 18:32:20:
> Joakim Tjernlund wrote:
> > Linux uses the weak host model which makes the IP addresses part of the system
> > rather than the interface. However consider this:
> >
> > System A, eth0 connected to the network
> > # > ifconfig eth0 192.168.1.16
> > # > ifconfig eth1 192.168.1.17 down
> >
> > System B
> > # > ping 192.168.1.17
> > PING 192.168.1.17 (192.168.1.17) 56(84) bytes of data.
> > 64 bytes from 192.168.1.17: icmp_seq=1 ttl=64 time=0.618 ms
> >
> > Isn't it a bit much to respond on 192.168.1.17 when its interface is down?
>
> As you said at the beginning, the weak end system model presumes the IP address
> is part of the system. Seems to me that means unless one removes the IP address
> from the system it is reasonable for the system to continue to respond to that
> IP address. Regardless of what happens to any individual interface.
The weak model doesn't go into such detail, it is assumption/impl. detail
to assume that the ip address still is part of the system even when the interface
is down. One could just as well define interface down as temporarly removing
the IP address from the system too. This makes make much more sense to me and
if you always want the system to answer on a IP adress you make it an IP alias.
Since the current behaviour is a problem to me and routers in general, can
we change this? What is the current usage model which needs it to stay as is?
>
> Now, I wouldn't expect it to continue to respond to 192.168.1.17 through eth1,
> but if eth0 is indeed connected to the same broadcast domain, given the
> following of the weak end-system model, continuing to respond seems consistent
> with enthusiasticaly following the weak end-system model.
Dosnt matter if it is in the same broadcast domain, you can use a bridge
interface or dummy interface too. It will still respond to 192.168.1.17
I can't find a way disable this behaviour, can you?
^ 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