Re: [PATCH v2.6.22-rc5] cxgb2: handle possible NULL pointer dereferencing, take 2
pradeep singh wrote:
Hi,
This is second submission for a possible NULL dereference handling in
the Chelsio's 10G driver.
Thanks to Jens Axboe for pointing out my mistake of ignoring
subsequent dereferences in init_one routine.
Thanks
Signed-off-by: Pradeep Singh [EMAIL PROTECTED]
---
drivers/net/chelsio/cxgb2.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/chelsio/cxgb2.c b/drivers/net/chelsio/cxgb2.c
index 231ce43..006c634 100644
--- a/drivers/net/chelsio/cxgb2.c
+++ b/drivers/net/chelsio/cxgb2.c
@@ -1022,6 +1022,11 @@ static int __devinit init_one(struct pci_dev *pdev,
mmio_start = pci_resource_start(pdev, 0);
mmio_len = pci_resource_len(pdev, 0);
bi = t1_get_board_info(ent-driver_data);
+
+if (!bi) {
+CH_ERR(%s: Board info array index out of
range\n,pci_name(pdev));
+goto out_disable_pdev;
+}
NAK. It's impossible to hit this condition.
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] au1000_eth: Fix warnings.
Ralf Baechle wrote: Fixed by including linux/dma-mapping.h: CC drivers/net/au1000_eth.o drivers/net/au1000_eth.c: In function 'au1000_probe': drivers/net/au1000_eth.c:661: warning: implicit declaration of function 'dma_alloc_noncoherent' drivers/net/au1000_eth.c:802: warning: implicit declaration of function 'dma_free_noncoherent' Signed-off-by: Ralf Baechle [EMAIL PROTECTED] applied to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22] cxgb3 - fix register to stop bc/mc traffic
Divy Le Ray wrote: From: Divy Le Ray [EMAIL PROTECTED] Use the right register to stop broadcast/multicast traffic. Signed-off-by: Divy Le Ray [EMAIL PROTECTED] applied to #upstream-fixes - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.22: ERROR: __ucmpdi2 [drivers/net/s2io.ko] undefined!
Olaf Hering wrote:
On Tue, Jun 19, Stephen Hemminger wrote:
On Tue, 19 Jun 2007 21:02:53 +0200
Olaf Hering [EMAIL PROTECTED] wrote:
What happend to __ucmpdi2 from David Woodhouse?
google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
ERROR: __ucmpdi2 [drivers/net/s2io.ko] undefined!
using the drivers/net/s2io* files from 2.6.21 with 2.6.22-rc5 fixes the
compile.
25805dcf9d83098cf5492117ad2669cd14cc9b24 adds two u64 = 48 followed by
a switch statement (line 2889 and 6816).
Probably the switch(err) { needs a cast to a smaller type (like u8).
This change removes the calls to __ucmpdi2.
---
drivers/net/s2io.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
applied to #upstream-fixes
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dm9601: HW header size shouldn't be included in packet length
The dm9601 driver was including the 2 byte hardware header in the
packet length, causing the HW to send 2 extra bytes of garbage on tx.
Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
drivers/net/usb/dm9601.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.22-rc6/drivers/net/usb/dm9601.c
===
--- linux-2.6.22-rc6.orig/drivers/net/usb/dm9601.c
+++ linux-2.6.22-rc6/drivers/net/usb/dm9601.c
@@ -489,6 +489,8 @@
b3..n: packet data
*/
+ len = skb-len;
+
if (skb_headroom(skb) DM_TX_OVERHEAD) {
struct sk_buff *skb2;
@@ -501,10 +503,9 @@
__skb_push(skb, DM_TX_OVERHEAD);
- len = skb-len;
/* usbnet adds padding if length is a multiple of packet size
if so, adjust length value in header */
- if ((len % dev-maxpacket) == 0)
+ if ((skb-len % dev-maxpacket) == 0)
len++;
skb-data[0] = len;
--
Bye, Peter Korsgaard
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usbnet: Zero padding byte if there is tail room in skb
Usbnet adds a padding byte if a 0 byte USB packet would be sent. Zero
padding byte if there is tail room in skb.
Signed-of-by: Peter Korsgaard [EMAIL PROTECTED]
Acked-by: David Brownell [EMAIL PROTECTED]
---
drivers/net/usb/usbnet.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: linux-2.6.22-rc6/drivers/net/usb/usbnet.c
===
--- linux-2.6.22-rc6.orig/drivers/net/usb/usbnet.c
+++ linux-2.6.22-rc6/drivers/net/usb/usbnet.c
@@ -953,11 +953,14 @@
/* don't assume the hardware handles USB_ZERO_PACKET
* NOTE: strictly conforming cdc-ether devices should expect
* the ZLP here, but ignore the one-byte packet.
-*
-* FIXME zero that byte, if it doesn't require a new skb.
*/
- if ((length % dev-maxpacket) == 0)
+ if ((length % dev-maxpacket) == 0) {
urb-transfer_buffer_length++;
+ if (skb_tailroom(skb)) {
+ skb-data[skb-len] = 0;
+ __skb_put(skb, 1);
+ }
+ }
spin_lock_irqsave (dev-txq.lock, flags);
--
Bye, Peter Korsgaard
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.21.1] ipconfig: add support for multiple user devs
From: Sean Kormilo [EMAIL PROTECTED] Date: Thu, 17 May 2007 15:16:12 -0400 Update ipconfig to enable users to specify multiple devices on the kernel commandline ip= option. This allows for up-to 4 devices to be specified, with devices separated by a '/' character. For example, to limit autoconfig requests to eth0 and eth2: ip=:eth0/eth2:DHCP This is required in cases where one might want to allow DHCP requests from multiple devices, but not necessarily want to broadcast on all ethernet devices that are present in the system. Hi Sean. I have no objections to your patch, except that the 4 device limit seems arbitrary. I would suggest to dynamically kmalloc() up a string buffer after parsing the option string counting the / characters present. That way there is no limit to the number of devices which can be specified. Please make this change and resubmit your patch so that I can include it, thanks! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [IPV6] MIP6: Kill unnecessary ifdefs.
From: [EMAIL PROTECTED] Date: Wed, 23 May 2007 16:50:18 +0900 From: Masahide NAKAMURA [EMAIL PROTECTED] Kill unnecessary CONFIG_IPV6_MIP6. o It is redundant for RAW socket to keep MH out with the config then it can handle any protocol. o Clean-up at AH. Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED] Patch applied to net-2.6.23, thank you! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6] MIP6: Loadable module support for MIPv6.
From: [EMAIL PROTECTED] Date: Wed, 23 May 2007 16:50:19 +0900 From: Masahide NAKAMURA [EMAIL PROTECTED] This patch makes MIPv6 loadable module named mip6. Here is a modprobe.conf(5) example to load it automatically when user application uses XFRM state for MIPv6: alias xfrm-type-10-43 mip6 alias xfrm-type-10-60 mip6 Some MIPv6 feature is not included by this modular, however, it should not be affected to other features like either IPsec or IPv6 with and without the patch. We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt separately for future work. Loadable features: * MH receiving check (to send ICMP error back) * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS) * XFRM policy/state database handling for RO These are NOT covered as loadable: * Home Address flags and its rule on source address selection * XFRM sub policy (depends on its own kernel option) * XFRM functions to receive RO as IPv6 extension header * MH sending/receiving through raw socket if user application opens it (since raw socket allows to do so) * RH2 sending as ancillary data * RH2 operation with setsockopt(2) Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED] Patch applied, thank you! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [XFRM]: Add module alias for transformation type.
From: [EMAIL PROTECTED] Date: Fri, 25 May 2007 13:23:23 +0900 Hi Ingo and all, This is the third one of MIPv6 module patch. It can be applied after two patches which are already sent to the list. Could you review it? It is clean-up for XFRM type modules and adds aliases with its protocol: ESP, AH, IPCOMP, IPIP and IPv6 for IPsec ROUTING and DSTOPTS for MIPv6 It is almost the same thing as XFRM mode alias, but it is added new defines XFRM_PROTO_XXX for preprocessing since some protocols are defined as enum. Signed-off-by: Masahide NAKAMURA [EMAIL PROTECTED] I have also applied this patch, thank you! - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: resend [PATCH 1/5 2.6.21] UDP: Introduce UDP encapsulation type for L2TP
From: James Chapman [EMAIL PROTECTED] Date: Sat, 26 May 2007 18:47:24 +0100 This patch adds a new UDP_ENCAP_L2TPINUDP encapsulation type for UDP sockets. When a UDP socket's encap_type is UDP_ENCAP_L2TPINUDP, the skb is delivered to a function pointed to by udp_encap_l2tp_rcv. If the skb isn't wanted by L2TP, it returns 0, which causes it to be passed through to UDP. A funcptr is used for udp_encap_l2tp_rcv to allow L2TP to be implemented as a kernel module. Previously, the only user of UDP encap sockets was ESP, so when CONFIG_XFRM was not defined, some of the encap code was compiled out. This patch changes that. As a result, udp_encap_rcv() will now do a little more work when CONFIG_XFRM is not defined. Signed-off-by: James Chapman [EMAIL PROTECTED] --- There are some magic numbers returned by udp_encap_rcv() that should perhaps now be made #defines. I chose not to do so in this patch. I have no problem with the magic numbers in an initial version of this stuff, but I do not like the function pointer. It's error prone, invites mis-use, and will be difficult to safely register/deregister properly. Perhaps one good idea would be to store the encap handler in the UDP socket info directly. In this manner, the code which sets up-encap_type can set the callback in the socket and do appropriate locking and reference counting. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] IPV6 checksum offloading in network devices
From: Stephen Hemminger [EMAIL PROTECTED] Date: Wed, 30 May 2007 14:00:34 -0700 This is better. There is still a possiblity when a device allows IPV6 and not IPV4 checksumming, that the checksum will be done in the fixup code in dev_queue_xmit. The existing model for checksum offload does not correctly handle devices that can offload IPV4 and IPV6 only. The NETIF_F_HW_CSUM flag implies device can do any arbitrary protocol. This patch: * adds NETIF_F_IPV6_CSUM for those devices * fixes bnx2 and tg3 devices that need it * add NETIF_F_IPV6_CSUM to ipv6 output (incl GSO) * fixes assumptions about NETIF_F_ALL_CSUM in nat * adjusts bridge union of checksumming computation I've applied this to net-2.6.23, we can back it out or rework it if there are problems. Several of these checksum feature tests are getting out of hand :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/2] dmaengine: preparation for raid acceleration
From: Dan Williams [EMAIL PROTECTED] Date: Fri, 01 Jun 2007 17:17:49 -0700 Hello David, The following two patches are part of the raid acceleration series I would like to push for 2.6.23 consideration. I am sending these two separately for your review for the following reasons: the 'dmaengine' core initially came in through netdev, patch #2 makes changes to net/dev/core.c, and lastly I have an ack on the raid changes but no ack from the community on the i/oat and dmaengine changes. dmaengine: add base support for the async_tx api dmaengine: move channel management to the client Dan, you can merge this through Andrew's -mm tree and this will actually make things easier for me. The net changes are minimal and I have no problem with them. Acked-by: David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: resend [PATCH 2/5 2.6.21] L2TP: Changes to existing ppp and socket kernel headers for L2TP
From: David Miller [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 00:18:24 -0700 (PDT) From: James Chapman [EMAIL PROTECTED] Date: Sat, 26 May 2007 18:47:24 +0100 Add struct sockaddr_pppol2tp to carry L2TP-specific address information for the PPPoX (PPPoL2TP) socket. Unfortunately we can't use the union inside struct sockaddr_pppox because the L2TP-specific data is larger than the current size of the union and we must preserve the size of struct sockaddr_pppox for binary compatibility. Also add a PPPIOCGL2TPSTATS ioctl to allow userspace to obtain L2TP counters and state from the kernel. Signed-off-by: James Chapman [EMAIL PROTECTED] This looks OK, patch applied to net-2.6.23, thanks. Actually, I had to back this out because it depended upon header files added by subsequent patches and thus broke the build. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Update MAINTAINERS for USB network devices
Questions regarding the USB network drivers should now go to netdev. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- MAINTAINERS | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) Index: linux-2.6.22-rc6/MAINTAINERS === --- linux-2.6.22-rc6.orig/MAINTAINERS +++ linux-2.6.22-rc6/MAINTAINERS @@ -3610,15 +3610,14 @@ USB CDC ETHERNET DRIVER P: Greg Kroah-Hartman M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org S: Maintained W: http://www.kroah.com/linux-usb/ USB DAVICOM DM9601 DRIVER P: Peter Korsgaard M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained @@ -3702,8 +3701,7 @@ USB PEGASUS DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3717,8 +3715,7 @@ USB RTL8150 DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3829,7 +3826,7 @@ USB USBNET DRIVER FRAMEWORK P: David Brownell M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Update MAINTAINERS for USB network devices
Peter Korsgaard wrote: Questions regarding the USB network drivers should now go to netdev. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- MAINTAINERS | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) Index: linux-2.6.22-rc6/MAINTAINERS === --- linux-2.6.22-rc6.orig/MAINTAINERS +++ linux-2.6.22-rc6/MAINTAINERS @@ -3610,15 +3610,14 @@ USB CDC ETHERNET DRIVER P: Greg Kroah-Hartman M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org S: Maintained W: http://www.kroah.com/linux-usb/ USB DAVICOM DM9601 DRIVER P: Peter Korsgaard M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained @@ -3702,8 +3701,7 @@ USB PEGASUS DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3717,8 +3715,7 @@ USB RTL8150 DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3829,7 +3826,7 @@ USB USBNET DRIVER FRAMEWORK P: David Brownell M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained Quite true, but for courtesy's sake you should keep the relevant maintainers in the loop, and get their ACKs, when you start changing their MAINTAINERS entries. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET 01/05]: dev_mcast: unexport dev_mc_upload
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 14:24:07 +0200 (MEST) [NET]: dev_mcast: unexport dev_mc_upload dev_mc_add/dev_mc_delete take care of uploading the list when necessary and thats the only interface other code should use. Also remove two incorrect calls in DECnet. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied to net-2.6.23, thanks Patrick. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET 02/05]: dev: introduce generic net_device address lists
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 14:24:09 +0200 (MEST) [NET]: dev: introduce generic net_device address lists Introduce struct dev_addr_list and list maintenance functions based on dev_mc_list and the related functions. This will be used by follow-up patches for both multicast and secondary unicast addresses. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied to net-2.6.23 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET 03/05]: dev_mcast: switch to generic net_device address lists
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 14:24:10 +0200 (MEST) [NET]: dev_mcast: switch to generic net_device address lists Use generic net_device address lists for multicast list handling. Some defines are used to keep drivers working. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Applied, thanks Patrick. Hopefully we can convert the drivers over time and eventually at some future point kill the macros. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET 04/05]: dev: secondary unicast address support
From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 14:24:12 +0200 (MEST) [NET]: dev: secondary unicast address support Add support for configuring secondary unicast addresses on network devices. To support this devices capable of filtering multiple unicast addresses need to change their set_multicast_list function to configure unicast filters as well and assign it to dev-set_rx_mode instead of dev-set_multicast_list. Other devices are put into promiscous mode when secondary unicast addresses are present. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Also applied, thanks for doing this work Patrick. I'll let the driver maintainers approve and merge individual device support. Thanks again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET 04/05]: dev: secondary unicast address support
David Miller wrote: From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 14:24:12 +0200 (MEST) [NET]: dev: secondary unicast address support Add support for configuring secondary unicast addresses on network devices. To support this devices capable of filtering multiple unicast addresses need to change their set_multicast_list function to configure unicast filters as well and assign it to dev-set_rx_mode instead of dev-set_multicast_list. Other devices are put into promiscous mode when secondary unicast addresses are present. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Also applied, thanks for doing this work Patrick. Thanks. Please hold off on the MACVLAN patch, I want to convert it to use this stuff before adding it. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] 8139cp dev-tx_timeout
Hello All,
We have been experimenting a couple of interface hangs with the 8139cp
driver. It appears that the tx buffer stops transmitting and never starts
up again in some yet unknown conditions. To be able to circumvent this we
implemented the missing dev-tx_timeout function which should reset the
interface and allow it work again.
The problem reoccurs quite seldom and we have yet to be able to confirm
that the attached patch helps the situation. We though that we should
submit the patch anyway for reviewing.
The patch is made against 2.6.21.5 kernel.
(please cc me in your answer)
diff -ru linux-2.6.21.5/drivers/net/8139cp.c
linux-2.6.21.5_8139cp-tx_timeout/drivers/net/8139cp.c
--- linux-2.6.21.5/drivers/net/8139cp.c 2007-06-11 21:37:06.0 +0300
+++ linux-2.6.21.5_8139cp-tx_timeout/drivers/net/8139cp.c 2007-06-26
15:48:23.0 +0300
@@ -26,7 +26,6 @@
TODO:
* Test Tx checksumming thoroughly
- * Implement dev-tx_timeout
Low priority TODO:
* Complete reset on PciErr
@@ -1233,6 +1232,30 @@
return 0;
}
+static void cp_tx_timeout(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ int rc;
+ unsigned long flags;
+
+printk (KERN_WARNING %s: Transmit timeout, status %2x %4x %4x %4x\n,
+dev-name, cpr8(Cmd), cpr16(CpCmd),
+cpr16(IntrStatus), cpr16(IntrMask));
+
+ spin_lock_irqsave(cp-lock, flags);
+
+ cp_stop_hw(cp);
+ cp_clean_rings(cp);
+ rc = cp_init_rings(cp);
+ cp_start_hw(cp);
+
+ netif_wake_queue(dev);
+
+ spin_unlock_irqrestore(cp-lock, flags);
+
+ return;
+}
+
#ifdef BROKEN
static int cp_change_mtu(struct net_device *dev, int new_mtu)
{
@@ -1938,10 +1961,8 @@
dev-change_mtu = cp_change_mtu;
#endif
dev-ethtool_ops = cp_ethtool_ops;
-#if 0
dev-tx_timeout = cp_tx_timeout;
dev-watchdog_timeo = TX_TIMEOUT;
-#endif
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
Best regards,
Mr. Mika Länsirinne
Sofware Specialist
Stonesoft Corporation
Itälahdenkatu 22 A, FIN-00210 Helsinki, Finland
Mobile. +358-40-749 2068
[EMAIL PROTECTED]
http://www.stonesoft.com
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 8139cp dev-tx_timeout
[EMAIL PROTECTED] wrote: Hello All, We have been experimenting a couple of interface hangs with the 8139cp driver. It appears that the tx buffer stops transmitting and never starts up again in some yet unknown conditions. To be able to circumvent this we implemented the missing dev-tx_timeout function which should reset the interface and allow it work again. The problem reoccurs quite seldom and we have yet to be able to confirm that the attached patch helps the situation. We though that we should submit the patch anyway for reviewing. The patch is made against 2.6.21.5 kernel. Seems OK, but I'm definitely interested in hearing test feedback. Also, all patches need a Signed-off-by line per Documentation/SubmittingPatches or http://linux.yyz.us/patch-format.html Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Update MAINTAINERS for USB network devices
On 6/27/07, Jeff Garzik [EMAIL PROTECTED] wrote: Quite true, but for courtesy's sake you should keep the relevant maintainers in the loop, and get their ACKs, when you start changing their MAINTAINERS entries. Sorry, I forgot the CCs. David already agreed with the change: http://thread.gmane.org/gmane.linux.usb.devel/55377/focus=55382 -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET 04/05]: dev: secondary unicast address support
From: Patrick McHardy [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 10:30:09 +0200 David Miller wrote: From: Patrick McHardy [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 14:24:12 +0200 (MEST) [NET]: dev: secondary unicast address support Add support for configuring secondary unicast addresses on network devices. To support this devices capable of filtering multiple unicast addresses need to change their set_multicast_list function to configure unicast filters as well and assign it to dev-set_rx_mode instead of dev-set_multicast_list. Other devices are put into promiscous mode when secondary unicast addresses are present. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] Also applied, thanks for doing this work Patrick. Thanks. Please hold off on the MACVLAN patch, I want to convert it to use this stuff before adding it. Ok. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21.5] 8139cp: dev-tx_timeout
This patch implements the missing dev-tx_timeout for 8139cp driver
Signed-off-by: Mika Lansirinne [EMAIL PROTECTED]
---
diff -ru linux-2.6.21.5/drivers/net/8139cp.c
linux-2.6.21.5_8139cp-tx_timeout/drivers/net/8139cp.c
--- linux-2.6.21.5/drivers/net/8139cp.c 2007-06-11 21:37:06.0 +0300
+++ linux-2.6.21.5_8139cp-tx_timeout/drivers/net/8139cp.c 2007-06-26
15:48:23.0 +0300
@@ -26,7 +26,6 @@
TODO:
* Test Tx checksumming thoroughly
- * Implement dev-tx_timeout
Low priority TODO:
* Complete reset on PciErr
@@ -1233,6 +1232,30 @@
return 0;
}
+static void cp_tx_timeout(struct net_device *dev)
+{
+ struct cp_private *cp = netdev_priv(dev);
+ int rc;
+ unsigned long flags;
+
+printk (KERN_WARNING %s: Transmit timeout, status %2x %4x %4x %4x\n,
+dev-name, cpr8(Cmd), cpr16(CpCmd),
+cpr16(IntrStatus), cpr16(IntrMask));
+
+ spin_lock_irqsave(cp-lock, flags);
+
+ cp_stop_hw(cp);
+ cp_clean_rings(cp);
+ rc = cp_init_rings(cp);
+ cp_start_hw(cp);
+
+ netif_wake_queue(dev);
+
+ spin_unlock_irqrestore(cp-lock, flags);
+
+ return;
+}
+
#ifdef BROKEN
static int cp_change_mtu(struct net_device *dev, int new_mtu)
{
@@ -1938,10 +1961,8 @@
dev-change_mtu = cp_change_mtu;
#endif
dev-ethtool_ops = cp_ethtool_ops;
-#if 0
dev-tx_timeout = cp_tx_timeout;
dev-watchdog_timeo = TX_TIMEOUT;
-#endif
#if CP_VLAN_TAG_USED
dev-features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Jean-Baptiste Vignaud [EMAIL PROTECTED], marcin.slusarz [EMAIL PROTECTED], shemminger [EMAIL PROTECTED] Subject: Re: [PATCH] 8139cp dev-tx_timeout References: [EMAIL PROTECTED] [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] On 27-06-2007 10:36, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: Hello All, We have been experimenting a couple of interface hangs with the 8139cp driver. It appears that the tx buffer stops transmitting and never starts up again in some yet unknown conditions. To be able to circumvent this we implemented the missing dev-tx_timeout function which should reset the interface and allow it work again. The problem reoccurs quite seldom and we have yet to be able to confirm that the attached patch helps the situation. We though that we should submit the patch anyway for reviewing. The patch is made against 2.6.21.5 kernel. Seems OK, but I'm definitely interested in hearing test feedback. Hi! I think maybe there are too many similar problems under 2.6.21 to be individual, and there could be something common to fix? So, I link here a few probably interested souls to cc: Subject: Re: 2.6.20-2.6.21 - networking dies after random time ... On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote: Hello, i have a very similar problem with 2.6.21 also; 2 3com NICs and they are failling randomly. The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7) I found a bug report and added details here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960 I'm not subcribed on this list, so please cc me if there is any questions. JB On Tue, Jun 26, 2007 at 08:10:17AM +0200, Marcin Ślusarz wrote: ... I reproduced it on minimal config: ... We know your hardware should be OK - since it was fine with 2.6.20. ... It looks like there is something common in the air... Marcin: ne2k_pci with 8390, Jean: 3com, and now I see similar problem with 8139cp too (plus some ideas): http://marc.info/?l=linux-netdevm=118293314109648w=2 So, you probably should wait a little look for new patches here. Cheers, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] 8139cp dev-tx_timeout
(second try! sorry) On 27-06-2007 10:36, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: Hello All, We have been experimenting a couple of interface hangs with the 8139cp driver. It appears that the tx buffer stops transmitting and never starts up again in some yet unknown conditions. To be able to circumvent this we implemented the missing dev-tx_timeout function which should reset the interface and allow it work again. The problem reoccurs quite seldom and we have yet to be able to confirm that the attached patch helps the situation. We though that we should submit the patch anyway for reviewing. The patch is made against 2.6.21.5 kernel. Seems OK, but I'm definitely interested in hearing test feedback. Hi! I think maybe there are too many similar problems under 2.6.21 to be individual, and there could be something common to fix? So, I link here a few probably interested souls to cc: Subject: Re: 2.6.20-2.6.21 - networking dies after random time ... On Tue, Jun 26, 2007 at 04:24:07PM +0200, Jean-Baptiste Vignaud wrote: Hello, i have a very similar problem with 2.6.21 also; 2 3com NICs and they are failling randomly. The kernel is a basic fedora 7 kernel (2.6.21-1.3228.fc7) I found a bug report and added details here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243960 I'm not subcribed on this list, so please cc me if there is any questions. JB On Tue, Jun 26, 2007 at 08:10:17AM +0200, Marcin Ślusarz wrote: ... I reproduced it on minimal config: ... We know your hardware should be OK - since it was fine with 2.6.20. ... It looks like there is something common in the air... Marcin: ne2k_pci with 8390, Jean: 3com, and now I see similar problem with 8139cp too (plus some ideas): http://marc.info/?l=linux-netdevm=118293314109648w=2 So, you probably should wait a little look for new patches here. Cheers, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Update MAINTAINERS for USB network devices
On Wed, 27 Jun 2007, Jeff Garzik wrote: Peter Korsgaard wrote: Questions regarding the USB network drivers should now go to netdev. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- MAINTAINERS | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) Index: linux-2.6.22-rc6/MAINTAINERS === --- linux-2.6.22-rc6.orig/MAINTAINERS +++ linux-2.6.22-rc6/MAINTAINERS @@ -3610,15 +3610,14 @@ USB CDC ETHERNET DRIVER P: Greg Kroah-Hartman M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org S: Maintained W: http://www.kroah.com/linux-usb/ USB DAVICOM DM9601 DRIVER P: Peter Korsgaard M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained @@ -3702,8 +3701,7 @@ USB PEGASUS DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3717,8 +3715,7 @@ USB RTL8150 DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3829,7 +3826,7 @@ USB USBNET DRIVER FRAMEWORK P: David Brownell M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained Quite true, but for courtesy's sake you should keep the relevant maintainers in the loop, and get their ACKs, when you start changing their MAINTAINERS entries. Jeff Well, with these drivers there are as many USB related issues as there are network ones. I'd rather have both lists in the file. Linux-usb-users should probably go away, but i guess Greg has the final word. Petko - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8668] New: HTB Deadlock
On 25-06-2007 11:28, Patrick McHardy wrote: ... It is. This patch I had originally planned for 2.6.23 switches HTB to the generic estimator, which shouldn't suffer from this. BTW, maybe I look at this too short, but is this del_timer() in gen_kill_estimator() enough? I cannot see nothing against a timer just running and doing mod_timer() again... Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8668] New: HTB Deadlock
Jarek Poplawski wrote: On 25-06-2007 11:28, Patrick McHardy wrote: ... It is. This patch I had originally planned for 2.6.23 switches HTB to the generic estimator, which shouldn't suffer from this. BTW, maybe I look at this too short, but is this del_timer() in gen_kill_estimator() enough? I cannot see nothing against a timer just running and doing mod_timer() again... Yes, but nothing bad can happen, the timer will find an empty list and do nothing. It would make more sense to check for an empty list before restarting the timer though. Could you send a patch for that? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8668] New: HTB Deadlock
On Wed, Jun 27, 2007 at 01:44:08PM +0200, Patrick McHardy wrote: Jarek Poplawski wrote: On 25-06-2007 11:28, Patrick McHardy wrote: ... It is. This patch I had originally planned for 2.6.23 switches HTB to the generic estimator, which shouldn't suffer from this. BTW, maybe I look at this too short, but is this del_timer() in gen_kill_estimator() enough? I cannot see nothing against a timer just running and doing mod_timer() again... Yes, but nothing bad can happen, the timer will find an empty list and do nothing. It would make more sense to check for an empty list before restarting the timer though. Could you send a patch for that? Probably I could, but it's your idea! I look at this just now, and maybe it's enough for asking, but definitely not enough for patch. I'll try to check this more in the evening, so I could send something tomorrow. So if it's not only about kindness, feel free to do it sooner and I've no doubts - better. Thanks for so instant reply! Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8668] New: HTB Deadlock
On Wed, Jun 27, 2007 at 02:10:13PM +0200, Jarek Poplawski wrote: ... - So if it's not only about kindness, feel free to do it + So if it's only about kindness, feel free to do it Sorry! Jarek P. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled
On 06/27, Satyam Sharma wrote: Thanks for your comments, I'm still not convinced, however. An perhaps you are right. I don't have a very strong opinion on that. Still I can't understand why it is better if kthread_stop() sends a signal as well. Contrary, I believe we should avoid signals when it comes to kernel threads. One can always use force_sig() or allow_signal() + send_sig() when it is really needed, like cifs does. On 6/26/07, Oleg Nesterov [EMAIL PROTECTED] wrote: Personally, I don't think we should do this. kthread_stop() doesn't always mean kill this thread asap. Suppose that CPU_DOWN does kthread_stop(workqueue-thread) but doesn't flush the queue before that (we did so before 2.6.22 and perhaps we will do again). Now work_struct-func() doing tcp_recvmsg() or wait_event_interruptible() fails, but this is probably not that we want. Anyway, I think _all_ usages of kthread_stop() in the kernel *do* want the thread to stop *right then*. After all, kthread_stop() doesn't even return (gets blocked on wait_for_completion()) till it knows the target kthread *has* exited completely. Yes, kthread_stop(k) means that k should exit eventually, but I don't think that kthread_stop() should try to force the exit. And if a workqueue is blocked on tcp_recvmsg() or skb_recv_datagram() or some such, I don't see how that flush_workqueue (if that is what you meant) would succeed anyway (unless you do send the signal too), timeout, but this was just a silly example. I am talking about the case when wait_event_interruptible() should not fail (unless something bad happens) inside the while (!kthread_should_stop()) loop. Note also that kthread could use TASK_INTERRUPTIBLE sleep because it doesn't want to contribute to loadavg, and because it knows that all signals are ignored. Note that the exact scenario you're talking about wouldn't mean the kthread getting killed before it's supposed to be stopped anyway. Yes sure, we can't kill the kernel thread via signal. I meant we can have some unexpected failure. (offtopic) cifs_mount: send_sig(SIGKILL,srvTcp-tsk,1); tsk = srvTcp-tsk; if(tsk) kthread_stop(tsk); This if(tsk) looks wrong to me. I think it's bogus myself. [ Added [EMAIL PROTECTED] to Cc: ] Can srvTcp-tsk be NULL? If yes, send_sig() is not safe. Can srvTcp-tsk become NULL after send_sig() ? If yes, this check is racy, and kthread_stop() is not safe. That's again something the atomicity I proposed above could avoid? I think this if(tsk) is just bogus, and should be killed. Oleg. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [RFD] L2 Network namespace infrastructure
Patrick McHardy wrote: Eric W. Biederman wrote: -- The basic design There will be a network namespace structure that holds the global variables for a network namespace, making those global variables per network namespace. One of those per network namespace global variables will be the loopback device. Which means the network namespace a packet resides in can be found simply by examining the network device or the socket the packet is traversing. Either a pointer to this global structure will be passed into the functions that need to reference per network namespace variables or a structure that is already passed in (such as the network device) will be modified to contain a pointer to the network namespace structure. I believe OpenVZ stores the current namespace somewhere global, which avoids passing the namespace around. Couldn't you do this as well? yes, we store a global namespace context on current (can be stored in per-cpu as well). do you prefer this way? Thanks, Kirill - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8668] New: HTB Deadlock
Jarek Poplawski wrote: On Wed, Jun 27, 2007 at 01:44:08PM +0200, Patrick McHardy wrote: BTW, maybe I look at this too short, but is this del_timer() in gen_kill_estimator() enough? I cannot see nothing against a timer just running and doing mod_timer() again... Yes, but nothing bad can happen, the timer will find an empty list and do nothing. It would make more sense to check for an empty list before restarting the timer though. Could you send a patch for that? Probably I could, but it's your idea! I look at this just now, and maybe it's enough for asking, but definitely not enough for patch. I'll try to check this more in the evening, so I could send something tomorrow. So if it's not only about kindness, feel free to do it sooner and I've no doubts - better. I can take care of it, no problem. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Devel] Re: [RFD] L2 Network namespace infrastructure
Kirill Korotaev wrote: Patrick McHardy wrote: I believe OpenVZ stores the current namespace somewhere global, which avoids passing the namespace around. Couldn't you do this as well? yes, we store a global namespace context on current (can be stored in per-cpu as well). do you prefer this way? For what it's worth, I don't prefer this way as I can see wanting to have one application use several namespaces at once Thanks, Ben Thanks, Kirill - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Greear [EMAIL PROTECTED] Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Update MAINTAINERS for USB network devices
On Wed, Jun 27, 2007 at 01:54:15AM -0700, David Brownell wrote: On Wednesday 27 June 2007, Jeff Garzik wrote: Peter Korsgaard wrote: Questions regarding the USB network drivers should now go to netdev. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] --- MAINTAINERS | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) Index: linux-2.6.22-rc6/MAINTAINERS === --- linux-2.6.22-rc6.orig/MAINTAINERS +++ linux-2.6.22-rc6/MAINTAINERS @@ -3610,15 +3610,14 @@ USB CDC ETHERNET DRIVER P: Greg Kroah-Hartman I think that may refer to the old cdc ethernet driver though ... Greg? The new one, in the usbnet framework, is a very different beast... Yeah, this is the cdc_acm driver that is still in the USB drivers/ directory tree as it is a USB class driver that shows up as a tty device to userspace. It should not be moved to the networking list unless no one minds that I never see any queries about it :) thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: gen_estimator: fix locking and timer related bugs [Re: [Bugme-new] [Bug 8668] New: HTB Deadlock]
Patrick McHardy wrote:
Jarek Poplawski wrote:
I look at this just now, and maybe it's enough for asking,
but definitely not enough for patch. I'll try to check this
more in the evening, so I could send something tomorrow.
So if it's not only about kindness, feel free to do it
sooner and I've no doubts - better.
I can take care of it, no problem.
OK, this patch should fix the Jarek noticed (and a few more).
It does not fix the original HTB problem though.
[NET]: gen_estimator: fix locking and timer related bugs
As noticed by Jarek Poplawski [EMAIL PROTECTED], the timer removal in
gen_kill_estimator races with the timer function rearming the timer.
Additionally there are a few more related problems that seem to be
relicts from the time when the estimator was qdisc specific and
could rely on the rtnl or dev-qdisc_lock:
- the check whether the list is empty and a timer needs to be started
when adding a new estimator doesn't take the lock, so it races
against concurrent additions, which can result in the timer getting
added twice or getting reinitialized after getting added.
- the new estimator's next pointer is also set without holding the
lock, again racing against concurrent additions with possible
list corruption as a result.
- the timer deletion when killing an estimator is also not under
the lock and races against timer arming when adding a new estimator.
Fix by holding the lock around the entire list addition and initial
timer arming. Timer removal is not done explicitly anymore, instead
the timer function only rearms the timer when there are still
estimators present.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit 59b5997f78c3cf3366886969ac8e6b38100b30e9
tree 9b43ce1af21ad1c8817f1f2bc8291c0f60457a4e
parent 48d8d7ee5dd17c64833e0343ab4ae8ef01cc2648
author Patrick McHardy [EMAIL PROTECTED] Wed, 27 Jun 2007 17:06:02 +0200
committer Patrick McHardy [EMAIL PROTECTED] Wed, 27 Jun 2007 17:06:02 +0200
net/core/gen_estimator.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 17daf4c..49a0bd3 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -127,8 +127,8 @@ static void est_timer(unsigned long arg)
e-rate_est-pps = (e-avpps+0x1FF)10;
spin_unlock(e-stats_lock);
}
-
- mod_timer(elist[idx].timer, jiffies + ((HZidx)/4));
+ if (elist[idx].list != NULL)
+ mod_timer(elist[idx].timer, jiffies + ((HZidx)/4));
read_unlock(est_lock);
}
@@ -173,6 +173,7 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
est-last_packets = bstats-packets;
est-avpps = rate_est-pps10;
+ write_lock_bh(est_lock);
est-next = elist[est-interval].list;
if (est-next == NULL) {
init_timer(elist[est-interval].timer);
@@ -181,7 +182,6 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
elist[est-interval].timer.function = est_timer;
add_timer(elist[est-interval].timer);
}
- write_lock_bh(est_lock);
elist[est-interval].list = est;
write_unlock_bh(est_lock);
return 0;
@@ -202,7 +202,6 @@ void gen_kill_estimator(struct gnet_stats_basic *bstats,
struct gen_estimator *est, **pest;
for (idx=0; idx = EST_MAX_INTERVAL; idx++) {
- int killed = 0;
pest = elist[idx].list;
while ((est=*pest) != NULL) {
if (est-rate_est != rate_est || est-bstats != bstats)
{
@@ -215,10 +214,7 @@ void gen_kill_estimator(struct gnet_stats_basic *bstats,
write_unlock_bh(est_lock);
kfree(est);
- killed++;
}
- if (killed elist[idx].list == NULL)
- del_timer(elist[idx].timer);
}
}
Re: [PATCH] Update MAINTAINERS for USB network devices
@@ -3610,15 +3610,14 @@ USB CDC ETHERNET DRIVER P: Greg Kroah-Hartman I think that may refer to the old cdc ethernet driver though ... Greg? The new one, in the usbnet framework, is a very different beast... Yeah, this is the cdc_acm driver that is still in the USB drivers/ directory tree as it is a USB class driver that shows up as a tty device to userspace. It should not be moved to the networking list unless no one minds that I never see any queries about it :) Then it should say CDC ACM not CDC ETHERNET ... ;) - Dave - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET]: gen_estimator: fix locking and timer related bugs [Re: [Bugme-new] [Bug 8668] New: HTB Deadlock]
Patrick McHardy wrote:
[NET]: gen_estimator: fix locking and timer related bugs
That one still left a race, we could be reinitalizing the timer
while it is still running. This patch additionally makes sure
each timer is only initialized once.
[NET]: gen_estimator: fix locking and timer related bugs
As noticed by Jarek Poplawski [EMAIL PROTECTED], the timer removal in
gen_kill_estimator races with the timer function rearming the timer.
Additionally there are a few more related problems that seem to be
relicts from the timer when the estimator was qdisc specific and
could rely on the rtnl or dev-qdisc_lock:
- the check whether the list is empty and a timer needs to be started
when adding a new estimator doesn't take the lock, so it races
against concurrent additions, which can result in the timer beeing
added twice or getting reinitialized after being added.
- the new estimator's next pointer is also set without holding the
lock, again racing against concurrent additions with possible
list corruption as a result.
- the timer deletion when killing an estimator is also not under
the lock and races against timer arming when adding a new estimator.
Fix by holding the lock around the entire list addition and initial
timer arming. Removal is not done explicitly anymore, instead the
timer function only rearms the timer when there are still estimators
present.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit b6a0c468c258d96c6f132fc71ca74225235bc223
tree 6f61004cf4810a4826aa5c7477e4d455ae3a5698
parent 48d8d7ee5dd17c64833e0343ab4ae8ef01cc2648
author Patrick McHardy [EMAIL PROTECTED] Wed, 27 Jun 2007 17:06:02 +0200
committer Patrick McHardy [EMAIL PROTECTED] Wed, 27 Jun 2007 17:24:13 +0200
net/core/gen_estimator.c | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/net/core/gen_estimator.c b/net/core/gen_estimator.c
index 17daf4c..88a7805 100644
--- a/net/core/gen_estimator.c
+++ b/net/core/gen_estimator.c
@@ -127,8 +127,8 @@ static void est_timer(unsigned long arg)
e-rate_est-pps = (e-avpps+0x1FF)10;
spin_unlock(e-stats_lock);
}
-
- mod_timer(elist[idx].timer, jiffies + ((HZidx)/4));
+ if (elist[idx].list != NULL)
+ mod_timer(elist[idx].timer, jiffies + ((HZidx)/4));
read_unlock(est_lock);
}
@@ -152,6 +152,7 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
{
struct gen_estimator *est;
struct gnet_estimator *parm = RTA_DATA(opt);
+ int idx;
if (RTA_PAYLOAD(opt) sizeof(*parm))
return -EINVAL;
@@ -163,7 +164,7 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
if (est == NULL)
return -ENOBUFS;
- est-interval = parm-interval + 2;
+ est-interval = idx = parm-interval + 2;
est-bstats = bstats;
est-rate_est = rate_est;
est-stats_lock = stats_lock;
@@ -173,16 +174,14 @@ int gen_new_estimator(struct gnet_stats_basic *bstats,
est-last_packets = bstats-packets;
est-avpps = rate_est-pps10;
- est-next = elist[est-interval].list;
- if (est-next == NULL) {
- init_timer(elist[est-interval].timer);
- elist[est-interval].timer.data = est-interval;
- elist[est-interval].timer.expires = jiffies +
((HZest-interval)/4);
- elist[est-interval].timer.function = est_timer;
- add_timer(elist[est-interval].timer);
- }
write_lock_bh(est_lock);
- elist[est-interval].list = est;
+ if (!elist[idx].timer.function)
+ setup_timer(elist[idx].timer, est_timer, est-interval);
+ if (elist[est-interval].list == NULL)
+ mod_timer(elist[idx].timer, jiffies + ((HZidx)/4));
+
+ est-next = elist[idx].list;
+ elist[idx].list = est;
write_unlock_bh(est_lock);
return 0;
}
@@ -202,7 +201,6 @@ void gen_kill_estimator(struct gnet_stats_basic *bstats,
struct gen_estimator *est, **pest;
for (idx=0; idx = EST_MAX_INTERVAL; idx++) {
- int killed = 0;
pest = elist[idx].list;
while ((est=*pest) != NULL) {
if (est-rate_est != rate_est || est-bstats != bstats)
{
@@ -215,10 +213,7 @@ void gen_kill_estimator(struct gnet_stats_basic *bstats,
write_unlock_bh(est_lock);
kfree(est);
- killed++;
}
- if (killed elist[idx].list == NULL)
- del_timer(elist[idx].timer);
}
}
Re: [Devel] Re: [RFD] L2 Network namespace infrastructure
Jeff Garzik wrote: Eric W. Biederman wrote: Jeff Garzik [EMAIL PROTECTED] writes: David Miller wrote: I don't accept that we have to add another function argument to a bunch of core routines just to support this crap, especially since you give no way to turn it off and get that function argument slot back. To be honest I think this form of virtualization is a complete waste of time, even the openvz approach. We're protecting the kernel from itself, and that's an endless uphill battle that you will never win. Let's do this kind of stuff properly with a real minimal hypervisor, hopefully with appropriate hardware level support and good virtualized device interfaces, instead of this namespace stuff. Strongly seconded. This containerized virtualization approach just bloats up the kernel for something that is inherently fragile and IMO less secure -- protecting the kernel from itself. Plenty of other virt approaches don't stir the code like this, while simultaneously providing fewer, more-clean entry points for the virtualization to occur. Wrong. I really don't want to get into a my virtualization approach is better then yours. But this is flat out wrong. 99% of the changes I'm talking about introducing are just: - variable + ptr-variable There are more pieces mostly with when we initialize those variables but that is the essence of the change. You completely dodged the main objection. Which is OK if you are selling something to marketing departments, but not OK It is a pure illusion that one kind of virtualization is better then the other one. Look, maybe *hardware* virtualization and a small size of the hypervisor make you feel safer, however you totally forget about all the emulation drivers etc. which can have bugs and security implications as well and maybe triggerable from inside VM. Containers introduce chroot-jail-like features that give one a false sense of security, while still requiring one to poke holes in the illusion to get hardware-specific tasks accomplished. The concepts of users in any OS (and in Linux in particular) give people a false sense of security as well! I know a bunch of examples of how one user can crash/DoS/abuse another one e.g. on RHEL5 or mainstream. But no one have problems with that and no one thinks that multiuserness is a step-backward or maybe someone does?! Yes, there are always bugs and sometimes security implications, but people leave fine with it when it is fixed. The capable/not-capable model (i.e. superuser / normal user) is _still_ being secured locally, even after decades of work and whitepapers and audits. You are drinking Deep Kool-Aid if you think adding containers to the myriad kernel subsystems does anything besides increasing fragility, and decreasing security. You are securing in-kernel subsystems against other in-kernel subsystems. superuser/user model made that difficult enough... now containers add exponential audit complexity to that. Who is to say that a local root does not also pierce the container model? containers do the only thing: make sure that objects from one context are not visible to another one. If containers are not used - everything returns to the case as it is now, i.e. everything is global and globally visible and no auditing overhead at all. So if you are not interested in containers - the code auditing won't be noticably harder for you. And as opposed to other virtualization approaches so far no one has been able to measure the overhead. I suspect there will be a few more cache line misses somewhere but they haven't shown up yet. If the only use was strong isolation which Dave complains about I would concur that the namespace approach is inappropriate. However there are a lot other uses. Sure there are uses. There are uses to putting the X server into the kernel, too. At some point complexity and featuritis has to take a back seat to basic sanity. I agree about sanity, however I totally disagree about complexity you talk about. Bugs we face/fix in Linux kernel which are found with the help of that kind of virtualization makes me believe that Linux kernel only wins from it. Thanks, Kirill - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] iw_cxgb3: Bug Fixes for 2.6.23
Hey Roland, Here are some bug fixes to the iw_cxgb3 driver that I'd like included for 2.6.23. NOTE: Patch 1 requires a firmware interface change, so there is a version bump to 4.3 included in that patch that hits cxgb3. This will likely conflict with a previous version change that is in Jeff's upstream branch. The net is: we need the firmware version bumped to 4.3 with these iw_cxgb3 changes. Thanks, Steve. Shortlog: iw_cxgb3: Streaming - RDMA mode transition fixes. iw_cxgb3: TERMINATE WRs can hang the tx ofld queue. iw_cxgb3: Don't count neg_adv abort_req_rss messages as real aborts. iw_cxgb3: ctrl-qp init/clear shouldn't set the gen bit. iw_cxgb3: Don't post TID_RELEASE message. iw_cxgb3: Don't abort after failures sending the mpa reply. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] iw_cxgb3: Streaming - RDMA mode transition fixes.
iw_cxgb3: Streaming - RDMA mode transition fixes.
Due to a HW issue, our current scheme to transition the connection from
streaming to rdma mode is broken on the passive side. The firmware
and driver now support a new transition scheme for the passive side:
- driver posts rdma_init_wr (now including the initial receive seqno)
- driver posts last streaming message via TX_DATA message (MPA start
response)
- uP atomically sends the last streaming message and transitions the
tcb to rdma mode.
- driver waits for wr_ack indicating the last streaming message was ACKed.
NOTE: This change also bumps the required firmware version to 4.3.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/cxio_hal.c |2 -
drivers/infiniband/hw/cxgb3/cxio_wr.h |3 +
drivers/infiniband/hw/cxgb3/iwch_cm.c | 82
drivers/infiniband/hw/cxgb3/iwch_cm.h |1
drivers/infiniband/hw/cxgb3/iwch_qp.c |1
drivers/net/cxgb3/version.h|2 -
6 files changed, 38 insertions(+), 53 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c
b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index 76049af..215bbe5 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -833,7 +833,7 @@ int cxio_rdma_init(struct cxio_rdev *rde
wqe-ird = cpu_to_be32(attr-ird);
wqe-qp_dma_addr = cpu_to_be64(attr-qp_dma_addr);
wqe-qp_dma_size = cpu_to_be32(attr-qp_dma_size);
- wqe-rsvd = 0;
+ wqe-irs = cpu_to_be32(attr-irs);
skb-priority = 0; /* 0=ToeQ; 1=CtrlQ */
return (cxgb3_ofld_send(rdev_p-t3cdev_p, skb));
}
diff --git a/drivers/infiniband/hw/cxgb3/cxio_wr.h
b/drivers/infiniband/hw/cxgb3/cxio_wr.h
index ff7290e..c84d4ac 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_wr.h
+++ b/drivers/infiniband/hw/cxgb3/cxio_wr.h
@@ -294,6 +294,7 @@ struct t3_rdma_init_attr {
u64 qp_dma_addr;
u32 qp_dma_size;
u32 flags;
+ u32 irs;
};
struct t3_rdma_init_wr {
@@ -314,7 +315,7 @@ struct t3_rdma_init_wr {
__be32 ird;
__be64 qp_dma_addr; /* 7 */
__be32 qp_dma_size; /* 8 */
- u32 rsvd;
+ u32 irs;
};
struct t3_genbit {
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index b2faff5..7b8d5aa 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -515,7 +515,7 @@ static void send_mpa_req(struct iwch_ep
req-len = htonl(len);
req-param = htonl(V_TX_PORT(ep-l2t-smt_idx) |
V_TX_SNDBUF(snd_win15));
- req-flags = htonl(F_TX_IMM_ACK|F_TX_INIT);
+ req-flags = htonl(F_TX_INIT);
req-sndseq = htonl(ep-snd_seq);
BUG_ON(ep-mpa_skb);
ep-mpa_skb = skb;
@@ -566,7 +566,7 @@ static int send_mpa_reject(struct iwch_e
req-len = htonl(mpalen);
req-param = htonl(V_TX_PORT(ep-l2t-smt_idx) |
V_TX_SNDBUF(snd_win15));
- req-flags = htonl(F_TX_IMM_ACK|F_TX_INIT);
+ req-flags = htonl(F_TX_INIT);
req-sndseq = htonl(ep-snd_seq);
BUG_ON(ep-mpa_skb);
ep-mpa_skb = skb;
@@ -618,7 +618,7 @@ static int send_mpa_reply(struct iwch_ep
req-len = htonl(len);
req-param = htonl(V_TX_PORT(ep-l2t-smt_idx) |
V_TX_SNDBUF(snd_win15));
- req-flags = htonl(F_TX_MORE | F_TX_IMM_ACK | F_TX_INIT);
+ req-flags = htonl(F_TX_INIT);
req-sndseq = htonl(ep-snd_seq);
ep-mpa_skb = skb;
state_set(ep-com, MPA_REP_SENT);
@@ -641,6 +641,7 @@ static int act_establish(struct t3cdev *
cxgb3_insert_tid(ep-com.tdev, t3c_client, ep, tid);
ep-snd_seq = ntohl(req-snd_isn);
+ ep-rcv_seq = ntohl(req-rcv_isn);
set_emss(ep, ntohs(req-tcp_opt));
@@ -1023,6 +1024,9 @@ static int rx_data(struct t3cdev *tdev,
skb_pull(skb, sizeof(*hdr));
skb_trim(skb, dlen);
+ ep-rcv_seq += dlen;
+ BUG_ON(ep-rcv_seq != (ntohl(hdr-seq) + dlen));
+
switch (state_read(ep-com)) {
case MPA_REQ_SENT:
process_mpa_reply(ep, skb);
@@ -1060,7 +1064,6 @@ static int tx_ack(struct t3cdev *tdev, s
struct iwch_ep *ep = ctx;
struct cpl_wr_ack *hdr = cplhdr(skb);
unsigned int credits = ntohs(hdr-credits);
- enum iwch_qp_attr_mask mask;
PDBG(%s ep %p credits %u\n, __FUNCTION__, ep, credits);
@@ -1072,30 +1075,6 @@ static int tx_ack(struct t3cdev *tdev, s
ep-mpa_skb = NULL;
dst_confirm(ep-dst);
if (state_read(ep-com) == MPA_REP_SENT) {
- struct iwch_qp_attributes attrs;
-
- /* bind QP to EP and move to RTS */
- attrs.mpa_attr = ep-mpa_attr;
- attrs.max_ird = ep-ord;
- attrs.max_ord = ep-ord;
- attrs.llp_stream_handle = ep;
- attrs.next_state =
[PATCH 2/6] iw_cxgb3: TERMINATE WRs can hang the tx ofld queue.
iw_cxgb3: TERMINATE WRs can hang the tx ofld queue. Don't set the gen bits nor length bits in the terminate wr. This is done by the LLD driver. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/hw/cxgb3/iwch_qp.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_qp.c b/drivers/infiniband/hw/cxgb3/iwch_qp.c index 679b7c1..dd89b6b 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_qp.c +++ b/drivers/infiniband/hw/cxgb3/iwch_qp.c @@ -628,9 +628,9 @@ int iwch_post_terminate(struct iwch_qp * /* immediate data starts here. */ term = (struct terminate_message *)wqe-send.sgl; build_term_codes(rsp_msg, term-layer_etype, term-ecode); - build_fw_riwrh((void *)wqe, T3_WR_SEND, - T3_COMPLETION_FLAG | T3_NOTIFY_FLAG, 1, - qhp-ep-hwtid, 5); + wqe-send.wrh.op_seop_flags = cpu_to_be32(V_FW_RIWR_OP(T3_WR_SEND) | +V_FW_RIWR_FLAGS(T3_COMPLETION_FLAG | T3_NOTIFY_FLAG)); + wqe-send.wrh.gen_tid_len = cpu_to_be32(V_FW_RIWR_TID(qhp-ep-hwtid)); skb-priority = CPL_PRIORITY_DATA; return cxgb3_ofld_send(qhp-rhp-rdev.t3cdev_p, skb); } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] iw_cxgb3: Don't count neg_adv abort_req_rss messages as real aborts.
iw_cxgb3: Don't count neg_adv abort_req_rss messages as real aborts.
negative advice messages should _not_ count toward the 2 abort requests
needed to indicate an abort request.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index 7b8d5aa..4d7c277 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1465,6 +1465,13 @@ static int peer_abort(struct t3cdev *tde
int ret;
int state;
+ if (is_neg_adv_abort(req-status)) {
+ PDBG(%s neg_adv_abort ep %p tid %d\n, __FUNCTION__, ep,
+ep-hwtid);
+ t3_l2t_send_event(ep-com.tdev, ep-l2t);
+ return CPL_RET_BUF_DONE;
+ }
+
/*
* We get 2 peer aborts from the HW. The first one must
* be ignored except for scribbling that we need one more.
@@ -1474,13 +1481,6 @@ static int peer_abort(struct t3cdev *tde
return CPL_RET_BUF_DONE;
}
- if (is_neg_adv_abort(req-status)) {
- PDBG(%s neg_adv_abort ep %p tid %d\n, __FUNCTION__, ep,
-ep-hwtid);
- t3_l2t_send_event(ep-com.tdev, ep-l2t);
- return CPL_RET_BUF_DONE;
- }
-
state = state_read(ep-com);
PDBG(%s ep %p state %u\n, __FUNCTION__, ep, state);
switch (state) {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] iw_cxgb3: ctrl-qp init/clear shouldn't set the gen bit.
iw_cxgb3: ctrl-qp init/clear shouldn't set the gen bit. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/hw/cxgb3/cxio_hal.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c b/drivers/infiniband/hw/cxgb3/cxio_hal.c index 215bbe5..1518b41 100644 --- a/drivers/infiniband/hw/cxgb3/cxio_hal.c +++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c @@ -144,7 +144,7 @@ static int cxio_hal_clear_qp_ctx(struct } wqe = (struct t3_modify_qp_wr *) skb_put(skb, sizeof(*wqe)); memset(wqe, 0, sizeof(*wqe)); - build_fw_riwrh((struct fw_riwrh *) wqe, T3_WR_QP_MOD, 3, 1, qpid, 7); + build_fw_riwrh((struct fw_riwrh *) wqe, T3_WR_QP_MOD, 3, 0, qpid, 7); wqe-flags = cpu_to_be32(MODQP_WRITE_EC); sge_cmd = qpid 8 | 3; wqe-sge_cmd = cpu_to_be64(sge_cmd); @@ -548,7 +548,7 @@ static int cxio_hal_init_ctrl_qp(struct V_EC_UP_TOKEN(T3_CTL_QP_TID) | F_EC_VALID)) 32; wqe = (struct t3_modify_qp_wr *) skb_put(skb, sizeof(*wqe)); memset(wqe, 0, sizeof(*wqe)); - build_fw_riwrh((struct fw_riwrh *) wqe, T3_WR_QP_MOD, 0, 1, + build_fw_riwrh((struct fw_riwrh *) wqe, T3_WR_QP_MOD, 0, 0, T3_CTL_QP_TID, 7); wqe-flags = cpu_to_be32(MODQP_WRITE_EC); sge_cmd = (3ULL 56) | FW_RI_SGEEC_START 8 | 3; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] iw_cxgb3: Don't post TID_RELEASE message.
iw_cxgb3: Don't post TID_RELEASE message.
The LLD does this for us in cxgb3_remove_tid().
Also fixed active open failure cases where we shouldn't
be releasing the TID as well.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index 4d7c277..228721f 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -254,8 +254,6 @@ static void release_ep_resources(struct
cxgb3_remove_tid(ep-com.tdev, (void *)ep, ep-hwtid);
dst_release(ep-dst);
l2t_release(L2DATA(ep-com.tdev), ep-l2t);
- if (ep-com.tdev-type == T3B)
- release_tid(ep-com.tdev, ep-hwtid, NULL);
put_ep(ep-com);
}
@@ -1103,6 +1101,15 @@ static int abort_rpl(struct t3cdev *tdev
return CPL_RET_BUF_DONE;
}
+/*
+ * Return whether a failed active open has allocated a TID
+ */
+static inline int act_open_has_tid(int status)
+{
+ return status != CPL_ERR_TCAM_FULL status != CPL_ERR_CONN_EXIST
+ status != CPL_ERR_ARP_MISS;
+}
+
static int act_open_rpl(struct t3cdev *tdev, struct sk_buff *skb, void *ctx)
{
struct iwch_ep *ep = ctx;
@@ -1112,7 +1119,7 @@ static int act_open_rpl(struct t3cdev *t
status2errno(rpl-status));
connect_reply_upcall(ep, status2errno(rpl-status));
state_set(ep-com, DEAD);
- if (ep-com.tdev-type == T3B)
+ if (ep-com.tdev-type == T3B act_open_has_tid(rpl-status))
release_tid(ep-com.tdev, GET_TID(rpl), NULL);
cxgb3_free_atid(ep-com.tdev, ep-atid);
dst_release(ep-dst);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] iw_cxgb3: Don't abort after failures sending the mpa reply.
iw_cxgb3: Don't abort after failures sending the mpa reply. This bug results in an abort request being sent down _after_ the tid has been released. If the tid happens to have been reused, then the subsequent generation of the tid gets incorrectly aborted. The thread running iwch_accecpt_cr() must not abort a connection if an error is returned after being awakened. If any errors did occur while iwch_accept_cr() is blocked, then the connection has already been aborted on the thread processing the error. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/hw/cxgb3/iwch_cm.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c index 228721f..3b41dc0 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_cm.c +++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c @@ -1781,7 +1781,6 @@ err: ep-com.cm_id = NULL; ep-com.qp = NULL; cm_id-rem_ref(cm_id); - abort_connection(ep, NULL, GFP_KERNEL); put_ep(ep-com); return err; } - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
a maze of twisty stats, most different
It seems that every driver, when providing support for ethtool -S functionality, has considerable lattitude when it comes to the stats provided. Clearly this is very nice for the driver writer(s) as it allows them to provide whatever stats they feel are most natural for their NIC(s) and name them as they see fit. However :) From the standpoint of someone looking from the outside, say someone wanting to consume ethtool -S statistics, it seems to be a big jumble. Might there be a way to bring those two camps together? Is there already, with the same wide availabilty of ethtool, and I've just not seen it? rick jones - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2 hangs without any messages
On Wed, 23 May 2007 09:54:31 +0200 Tino Keitel [EMAIL PROTECTED] wrote: Hi folks, in the last 2 days, I had 2 outages of the NIC of my Mac mini Core Duo. I checked the kernel log but I found nothing sky2 related. After reloading the module, the interface worked again. Both freezes were connected to access from a remote NFS client to a directory with ~4700 files in it. Both times, after reloading the module and waiting some minutes until the NFS client had recovered from the hanging NFS server, the same action worked. The network is 100 mbit full duplex. I use NFS over TCP and kernel 2.6.21 with the disable flow control patch, the configuration is attached. Here are the sky2 messages that appeared when I discovered the freeze and reloaded the driver: sky2 eth0: disabling interface ACPI: PCI interrupt for device :01:00.0 disabled ACPI: PCI Interrupt :01:00.0[A] - GSI 16 (level, low) - IRQ 17 PCI: Setting latency timer of device :01:00.0 to 64 sky2 :01:00.0: v1.14 addr 0x9020 irq 17 Yukon-EC (0xb6) rev 2 Device driver eth0 lacks bus and class support for being resumed. sky2 eth0: addr 00:16:cb:a4:e1:68 sky2 eth0: enabling interface sky2 eth0: ram buffer 48K sky2 eth0: Link is up at 100 Mbps, full duplex, flow control none There is a reproducible hang (due to missed IRQ) in sky2. It is more reproducible with slower CPU's like Mac Mini. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.21.1] ipconfig: add support for multiple user devs
Update ipconfig to enable users to specify multiple devices on the kernel
commandline
ip= option. This allows for an arbitrary number of devices to be specified
up-to a
255 character limit. Devices are separated by a '/' character.
For example, to limit autoconfig requests to eth0 and eth2:
ip=:eth0/eth2:DHCP
This is required in cases where one might want to allow DHCP requests from
multiple
devices, but not necessarily want to broadcast on all ethernet devices that are
present
in the system.
The implementation manipulates the existing user_dev_name string and replaces
the '/'
characters with NULLs and keeps track of the number of devices parsed. It then
scans
through the multiple NULL terminated string array looking for matches.
This patch was tested successfully under vmware and qemu. In particular:
verified
via tcpdump that all devices in the list were autoconfiguring. That any other
devices
in the system were not autoconfiguring. Also verified that if an empty string
was
supplied it would behave as it did before (broadcast on all suitable devices).
Verified
that a single device behaved as before, and just used the single device.
Signed-off-by: Sean Kormilo [EMAIL PROTECTED]
---
Remove the arbitrary 4 device limit per request from David Miller. I was not
able to
use kmalloc in the ip_auto_config_setup function, it returned NULL. I guess
this may
make sense given that it is in the kernel commandline parsing phase. I settled
on
using an array, but removing the array of pointers.
I'm not subscribed to the mailing list, so please CC my email address on any
responses.
--- linux-2.6.21.1/Documentation/nfsroot.txt2007-06-27 08:41:53.0
-0400
+++ linux-2.6.21.1-ipconfig/Documentation/nfsroot.txt 2007-06-27
13:22:56.0 -0400
@@ -125,7 +125,7 @@ ip=client-ip:server-ip:gw-ip:netm
Default: Client IP address is used in ASCII notation.
- device Name of network device to use.
+ devicesName of network device(s) to use.
Default: If the host only has one device, it is used.
Otherwise the device is determined using
@@ -133,6 +133,14 @@ ip=client-ip:server-ip:gw-ip:netm
autoconfiguration requests out of all devices,
and using the device that received the first reply.
+ It is also possible to restrict the DHCP requests to a set of
+ devices. This can be done by passing in a '/' separated list of
+ device names.
+
+ For example, to specify that DHCP requests should only go out
+ eth0 and eth2:
+ ip=:eth0/eth2:DHCP
+
autoconf Method to use for autoconfiguration. In the case of options
which specify multiple autoconfiguration protocols,
requests are sent using all protocols, and the first one
--- linux-2.6.21.1/net/ipv4/ipconfig.c 2007-06-27 08:42:28.0 -0400
+++ linux-2.6.21.1-ipconfig/net/ipv4/ipconfig.c 2007-06-27 13:34:51.0
-0400
@@ -101,6 +101,9 @@
#define CONF_NAMESERVERS_MAX 3 /* Maximum number of nameservers
- '3' from resolv.h */
+#define CONF_USER_DEVS_MAX_LEN 255
+#define CONF_USER_DEVS_SEP'/' /* Separator for devices */
+
#define NONE __constant_htonl(INADDR_NONE)
/*
@@ -149,8 +152,11 @@ static u8 ic_domain[64]; /* DNS (not NI
* Private state.
*/
-/* Name of user-selected boot device */
-static char user_dev_name[IFNAMSIZ] __initdata = { 0, };
+/* Name of user-selected boot device(s) */
+static char user_dev_name[CONF_USER_DEVS_MAX_LEN] __initdata = { 0, };
+
+/* Number of user selected boot devices */
+static int num_user_devs __initdata = 0;
/* Protocols supported by available interfaces */
static int ic_proto_have_if __initdata = 0;
@@ -184,7 +190,10 @@ static int __init ic_open_devs(void)
struct ic_device *d, **last;
struct net_device *dev;
unsigned short oflags;
-
+ int able;
+ char *udn;
+ int udn_num;
+
last = ic_first_dev;
rtnl_lock();
@@ -195,43 +204,68 @@ static int __init ic_open_devs(void)
for (dev = dev_base; dev; dev = dev-next) {
if (dev == loopback_dev)
continue;
- if (user_dev_name[0] ? !strcmp(dev-name, user_dev_name) :
- (!(dev-flags IFF_LOOPBACK)
-(dev-flags (IFF_POINTOPOINT|IFF_BROADCAST))
-strncmp(dev-name, dummy, 5))) {
- int able = 0;
- if (dev-mtu = 364)
- able |= IC_BOOTP;
- else
- printk(KERN_WARNING DHCP/BOOTP: Ignoring
device %s, MTU %d too small, dev-name, dev-mtu);
- if (!(dev-flags IFF_NOARP))
- able |= IC_RARP;
-
[PATCH 2.6.21.1] ipconfig: add support for multiple user devs
Update ipconfig to enable users to specify multiple devices on the kernel
commandline
ip= option. This allows for an arbitrary number of devices to be specified
up-to a
255 character limit. Devices are separated by a '/' character.
For example, to limit autoconfig requests to eth0 and eth2:
ip=:eth0/eth2:DHCP
This is required in cases where one might want to allow DHCP requests from
multiple
devices, but not necessarily want to broadcast on all ethernet devices that are
present
in the system.
The implementation manipulates the existing user_dev_name string and replaces
the '/'
characters with NULLs and keeps track of the number of devices parsed. It then
scans
through the multiple NULL terminated string array looking for matches.
This patch was tested successfully under vmware and qemu. In particular:
verified
via tcpdump that all devices in the list were autoconfiguring. That any other
devices
in the system were not autoconfiguring. Also verified that if an empty string
was
supplied it would behave as it did before (broadcast on all suitable devices).
Verified
that a single device behaved as before, and just used the single device.
Signed-off-by: Sean Kormilo [EMAIL PROTECTED]
---
Resend last one to fix a small compile warning, and fix patch formatting.
I hit send too soon, sorry!
I'm not subscribed to the mailing list, so please CC my email address on any
responses.
--- linux-2.6.21.1/Documentation/nfsroot.txt2007-06-27 08:41:53.0
-0400
+++ linux-2.6.21.1-ipconfig/Documentation/nfsroot.txt 2007-06-27
13:22:56.0 -0400
@@ -125,7 +125,7 @@ ip=client-ip:server-ip:gw-ip:netm
Default: Client IP address is used in ASCII notation.
- device Name of network device to use.
+ devicesName of network device(s) to use.
Default: If the host only has one device, it is used.
Otherwise the device is determined using
@@ -133,6 +133,14 @@ ip=client-ip:server-ip:gw-ip:netm
autoconfiguration requests out of all devices,
and using the device that received the first reply.
+ It is also possible to restrict the DHCP requests to a set of
+ devices. This can be done by passing in a '/' separated list of
+ device names.
+
+ For example, to specify that DHCP requests should only go out
+ eth0 and eth2:
+ ip=:eth0/eth2:DHCP
+
autoconf Method to use for autoconfiguration. In the case of options
which specify multiple autoconfiguration protocols,
requests are sent using all protocols, and the first one
--- linux-2.6.21.1/net/ipv4/ipconfig.c 2007-06-27 08:42:28.0 -0400
+++ linux-2.6.21.1-ipconfig/net/ipv4/ipconfig.c 2007-06-27 13:34:51.0
-0400
@@ -101,6 +101,9 @@
#define CONF_NAMESERVERS_MAX 3 /* Maximum number of nameservers
- '3' from resolv.h */
+#define CONF_USER_DEVS_MAX_LEN 255
+#define CONF_USER_DEVS_SEP'/' /* Separator for devices */
+
#define NONE __constant_htonl(INADDR_NONE)
/*
@@ -149,8 +152,11 @@ static u8 ic_domain[64]; /* DNS (not NI
* Private state.
*/
-/* Name of user-selected boot device */
-static char user_dev_name[IFNAMSIZ] __initdata = { 0, };
+/* Name of user-selected boot device(s) */
+static char user_dev_name[CONF_USER_DEVS_MAX_LEN] __initdata = { 0, };
+
+/* Number of user selected boot devices */
+static int num_user_devs __initdata = 0;
/* Protocols supported by available interfaces */
static int ic_proto_have_if __initdata = 0;
@@ -184,7 +190,10 @@ static int __init ic_open_devs(void)
struct ic_device *d, **last;
struct net_device *dev;
unsigned short oflags;
-
+ int able;
+ char *udn;
+ int udn_num;
+
last = ic_first_dev;
rtnl_lock();
@@ -195,43 +204,68 @@ static int __init ic_open_devs(void)
for (dev = dev_base; dev; dev = dev-next) {
if (dev == loopback_dev)
continue;
- if (user_dev_name[0] ? !strcmp(dev-name, user_dev_name) :
- (!(dev-flags IFF_LOOPBACK)
-(dev-flags (IFF_POINTOPOINT|IFF_BROADCAST))
-strncmp(dev-name, dummy, 5))) {
- int able = 0;
- if (dev-mtu = 364)
- able |= IC_BOOTP;
- else
- printk(KERN_WARNING DHCP/BOOTP: Ignoring
device %s, MTU %d too small, dev-name, dev-mtu);
- if (!(dev-flags IFF_NOARP))
- able |= IC_RARP;
- able = ic_proto_enabled;
- if (ic_proto_enabled !able)
+
+ if (user_dev_name[0]) {
+ udn = user_dev_name;
+
+
Re: [PATCH] Update MAINTAINERS for USB network devices
Greg == Greg KH [EMAIL PROTECTED] writes: Greg Yeah, this is the cdc_acm driver that is still in the USB drivers/ Greg directory tree as it is a USB class driver that shows up as a tty device Greg to userspace. It should not be moved to the networking list unless no Greg one minds that I never see any queries about it :) Ok, here's an updated patch: Questions regarding the USB network drivers should now go to netdev. Signed-off-by: Peter Korsgaard [EMAIL PROTECTED] Acked-by: David Brownell [EMAIL PROTECTED] --- MAINTAINERS |8 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6.22-rc6/MAINTAINERS === --- linux-2.6.22-rc6.orig/MAINTAINERS +++ linux-2.6.22-rc6/MAINTAINERS @@ -3618,7 +3618,7 @@ USB DAVICOM DM9601 DRIVER P: Peter Korsgaard M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained @@ -3702,8 +3702,8 @@ USB PEGASUS DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3717,8 +3717,8 @@ USB RTL8150 DRIVER P: Petko Manolov M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://pegasus2.sourceforge.net/ S: Maintained @@ -3829,7 +3829,7 @@ USB USBNET DRIVER FRAMEWORK P: David Brownell M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: netdev@vger.kernel.org W: http://www.linux-usb.org/usbnet S: Maintained -- Bye, Peter Korsgaard - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] iw_cxgb3: Bug Fixes for 2.6.23
Here are some bug fixes to the iw_cxgb3 driver that I'd like included for 2.6.23. NOTE: Patch 1 requires a firmware interface change, so there is a version bump to 4.3 included in that patch that hits cxgb3. This will likely conflict with a previous version change that is in Jeff's upstream branch. The net is: we need the firmware version bumped to 4.3 with these iw_cxgb3 changes. OK, I'll probably pull this into my tree and hold off on asking Linus to pull until after he pulls Jeff's net driver tree. Once that happens I'll fix up any conflicts and ask Linus to pull. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] iw_cxgb3: Bug Fixes for 2.6.23
Roland Dreier wrote: Here are some bug fixes to the iw_cxgb3 driver that I'd like included for 2.6.23. NOTE: Patch 1 requires a firmware interface change, so there is a version bump to 4.3 included in that patch that hits cxgb3. This will likely conflict with a previous version change that is in Jeff's upstream branch. The net is: we need the firmware version bumped to 4.3 with these iw_cxgb3 changes. OK, I'll probably pull this into my tree and hold off on asking Linus to pull until after he pulls Jeff's net driver tree. Once that happens I'll fix up any conflicts and ask Linus to pull. Sounds good. Thanks, Steve. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull 'libertas-fixes' branch of wireless-2.6
The following changes since commit 189548642c5962e60c3667bdb3a703fe0bed12a6: Linus Torvalds (1): Linus 2.6.22-rc6 are found in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git libertas-fixes Dan Williams (4): libertas: style fixes libertas: kill wlan_scan_process_results libertas: fix WPA associations by handling ENABLE_RSN correctly libertas: remove private ioctls drivers/net/wireless/libertas/Makefile |2 +- drivers/net/wireless/libertas/README| 275 drivers/net/wireless/libertas/assoc.c | 28 +- drivers/net/wireless/libertas/cmd.c | 12 +- drivers/net/wireless/libertas/cmdresp.c | 21 + drivers/net/wireless/libertas/hostcmd.h |2 +- drivers/net/wireless/libertas/ioctl.c | 1081 --- drivers/net/wireless/libertas/main.c|8 +- drivers/net/wireless/libertas/scan.c| 51 +-- drivers/net/wireless/libertas/wext.c| 152 - drivers/net/wireless/libertas/wext.h| 45 +-- 11 files changed, 79 insertions(+), 1598 deletions(-) delete mode 100644 drivers/net/wireless/libertas/ioctl.c diff --git a/drivers/net/wireless/libertas/Makefile b/drivers/net/wireless/libertas/Makefile index a1097f5..32ed413 100644 --- a/drivers/net/wireless/libertas/Makefile +++ b/drivers/net/wireless/libertas/Makefile @@ -2,7 +2,7 @@ libertas-objs := main.o fw.o wext.o \ rx.o tx.o cmd.o \ cmdresp.o scan.o \ join.o 11d.o \ - ioctl.o debugfs.o \ + debugfs.o \ ethtool.o assoc.o usb8xxx-objs += if_bootcmd.o diff --git a/drivers/net/wireless/libertas/README b/drivers/net/wireless/libertas/README index 1f92f50..0b133ce 100644 --- a/drivers/net/wireless/libertas/README +++ b/drivers/net/wireless/libertas/README @@ -28,281 +28,6 @@ DRIVER LOADING insmod usb8388.ko [fw_name=usb8388.bin] -= -IWPRIV COMMAND -= - -NAME - This manual describes the usage of private commands used in Marvell WLAN - Linux Driver. All the commands available in Wlanconfig will not be available - in the iwpriv. - -SYNOPSIS - iwpriv ethX command [sub-command] ... - - iwpriv ethX setregioncode n - iwpriv ethX getregioncode - -Version 5 Command: - iwpriv ethX ledgpio n - -BT Commands: - The blinding table (BT) contains a list of mac addresses that will be, - by default, ignored by the firmware. It is also possible to invert this - behavior so that we will ignore all traffic except for the portion - coming from mac addresess in the list. It is primarily used for - debugging and testing networks. It can be edited and inspected with - the following commands: - - iwpriv ethX bt_reset - iwpriv ethX bt_add mac_address - iwpriv ethX bt_del mac_address - iwpriv ethX bt_list id - iwpriv ethX bt_get_invert n - iwpriv ethX bt_set_invert n - -FWT Commands: - The forwarding table (FWT) is a feature used to manage mesh network - routing in the firmware. The FWT is essentially a routing table that - associates a destination mac address (da) with a next hop receiver - address (ra). The FWT can be inspected and edited with the following - iwpriv commands, which are described in greater detail below. - Eventually, the table will be automatically maintained by a custom - routing protocol. - - NOTE: FWT commands replace the previous DFT commands. What were the DFT - commands?, you might ask. They were an earlier API to the firmware that - implemented a simple MAC-layer forwarding mechanism. In the unlikely - event that you were using these commands, you must migrate to the new - FWT commands which can be used to achieve the same functionality. - - iwpriv ethX fwt_add [parameters] - iwpriv ethX fwt_del [parameters] - iwpriv ethX fwt_lookup [parameters] - iwpriv ethX fwt_list [parameters] - iwpriv ethX fwt_list_route [parameters] - iwpriv ethX fwt_list_neigh [parameters] - iwpriv ethX fwt_reset [parameters] - iwpriv ethX fwt_cleanup - iwpriv ethX fwt_time - -MESH Commands: - - The MESH commands are used to configure various features of the mesh - routing protocol. The following commands are supported: - - iwpriv ethX mesh_get_ttl - iwpriv ethX mesh_set_ttl ttl - -DESCRIPTION - Those commands are used to send additional commands to the Marvell WLAN - card via the Linux device driver. - - The ethX parameter specifies the network device that is to be used to - perform this command on. it could be eth0, eth1 etc. - -setregioncode - This command is used to set the region code in the station. - where value is 'region
Re: [MaybeSpam] Re: [PATCH 2.6.22-rc5] TCP: Make TCP_RTO_MAX a variable
Patrick McHardy wrote: OBATA Noboru wrote: From: OBATA Noboru [EMAIL PROTECTED] Make TCP_RTO_MAX a variable, and allow a user to change it via a new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can then guarantee TCP retransmission to be more controllable, say, at least once per 10 seconds, by setting it to 10. This is quite helpful on failover-capable network devices, such as an active-backup bonding device. On such devices, it is desirable that TCP retransmits a packet shortly after the failover, which is what I would like to do with this patch. Please see Background and Problem below for rationale in detail. Would it make sense to do this per route? Well, for a certain case, maybe yes. For example, (1) You have both a fast route (link) and a slow route, (2) You want to use a short RTO for the fast route and not for the slow route, and (3) Routes are static, as mentioned by Siim. On such a case, only a global tcp_rto_max, which is set to a very small value, may overload the slow link due to many retransmission packets. Then, as Stephen mentioned, people will find it useful to have per route tcp_rto_max. But let me give you some number. The number of retramsmission packets in the first 60[s] on tcp_rto_max = 10[s], starting from RTO = 0.2[s], are: 10 with tcp_rto_max = 10[s], where 8 with tcp_rto_max = 120[s] (original). Only extra 2 packets per minute per socket should be acceptable in most cases. So if you choose a moderate tcp_rto_max, you may not necessarily need per route tcp_rto_max. Regards, -- OBATA Noboru ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5 2.6.22-rc6] L2TP: Introduce PPP-over-L2TP driver
This patch set adds a driver for PPP over L2TP. Patches to follow. The following changes have been made since the previous version submitted 26-MAY-07. - Add new encap_rcv field to struct udp_sock in udp.h for use by encapsulated sockets. This is set to a protocol specific receive handler for encap sockets. This is instead of the global funcptr that was in the previous version. - Rebased to 2.6.22-rc6. - Update SOL_PPPOL2TP value to avoid clash with RxRPC. - Move pppol2tp.h into the api-changes patch so that the patch can be applied in isolation. - Update core driver to use skb_transport_header() and skb_network_header() functions rather than the old skb-h and skb-nh fields. About this patch series: The implementation uses the existing PPPoX subsystem that is currently used only by PPPoE. A userspace daemon handles all L2TP control protocol messages, while a PPPoX socket carries user data. The system architecture is similar to PPPoE, where a pppd plugin uses the PPPoX socket to send/receive PPP frames over an L2TP tunnel. PPP control frames are delivered to pppd while data frames are handled entirely by the kernel. There are 5 patches in the series:- 1 - Introduce new UDP encapsulation type for L2TP. 2 - API changes for L2TP. Adds definitions for L2TP in existing headers. 3 - pppol2tp driver core. New code. Requires patches 1, 2, and the recently applied skb_queue_walk_safe patch. 4 - Add an entry to MAINTAINERS file for this driver. 5 - Add in-kernel documentation. The driver is being used on x86, ia64, ppc, arm, mips32 and possibly other architectures. It is also known to work on multi-core SMP boxes. -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 2.6.22-rc6] UDP: Introduce UDP encapsulation type for L2TP
This patch adds a new UDP_ENCAP_L2TPINUDP encapsulation type for UDP
sockets. When a UDP socket's encap_type is UDP_ENCAP_L2TPINUDP, the
skb is delivered to a function pointed to by the udp_sock's
encap_rcv funcptr. If the skb isn't wanted by L2TP, it returns 0, which
causes it to be passed through to UDP.
Include padding to put the new encap_rcv field on a 4-byte boundary.
Previously, the only user of UDP encap sockets was ESP, so when
CONFIG_XFRM was not defined, some of the encap code was compiled
out. This patch changes that. As a result, udp_encap_rcv() will
now do a little more work when CONFIG_XFRM is not defined.
Signed-off-by: James Chapman [EMAIL PROTECTED]
---
This mechanism could now be used by any protocol encapsulated in UDP
since the encap_rcv funcptr could be set to point to a
protocol-specific encap_rcv function. Should UDP_ENCAP_L2TPINUDP be
something like UDP_ENCAP_GENERICINUDP?
Index: linux-2.6.22-rc6/include/linux/udp.h
===
--- linux-2.6.22-rc6.orig/include/linux/udp.h
+++ linux-2.6.22-rc6/include/linux/udp.h
@@ -42,6 +42,7 @@ static inline struct udphdr *udp_hdr(con
/* UDP encapsulation types */
#define UDP_ENCAP_ESPINUDP_NON_IKE 1 /* draft-ietf-ipsec-nat-t-ike-00/01 */
#define UDP_ENCAP_ESPINUDP 2 /* draft-ietf-ipsec-udp-encaps-06 */
+#define UDP_ENCAP_L2TPINUDP3 /* rfc2661 */
#ifdef __KERNEL__
#include linux/types.h
@@ -70,6 +71,11 @@ struct udp_sock {
#define UDPLITE_SEND_CC 0x2 /* set via udplite setsockopt */
#define UDPLITE_RECV_CC 0x4 /* set via udplite setsocktopt*/
__u8 pcflag;/* marks socket as UDP-Lite if 0*/
+ __u8 unused[3];
+ /*
+* For encapsulation sockets.
+*/
+ int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
};
static inline struct udp_sock *udp_sk(const struct sock *sk)
Index: linux-2.6.22-rc6/net/ipv4/udp.c
===
--- linux-2.6.22-rc6.orig/net/ipv4/udp.c
+++ linux-2.6.22-rc6/net/ipv4/udp.c
@@ -70,6 +70,7 @@
* Alexey Kuznetsov: allow both IPv4 and IPv6 sockets to bind
* a single port at the same time.
* Derek Atkins [EMAIL PROTECTED]: Add Encapulation Support
+ * James Chapman : Add L2TP encapsulation type.
*
*
* This program is free software; you can redistribute it and/or
@@ -923,12 +924,10 @@ int udp_disconnect(struct sock *sk, int
* 1 if the UDP system should process it
* 0 if we should drop this packet
* -1 if it should get processed by xfrm4_rcv_encap
+ * -2 if it should get processed by l2tp
*/
static int udp_encap_rcv(struct sock * sk, struct sk_buff *skb)
{
-#ifndef CONFIG_XFRM
- return 1;
-#else
struct udp_sock *up = udp_sk(sk);
struct udphdr *uh;
struct iphdr *iph;
@@ -983,8 +982,14 @@ static int udp_encap_rcv(struct sock * s
/* Must be an IKE packet.. pass it through */
return 1;
break;
+ case UDP_ENCAP_L2TPINUDP:
+ /* Let caller know to send this to l2tp */
+ return -2;
}
+#ifndef CONFIG_XFRM
+ return 1;
+#else
/* At this point we are sure that this is an ESPinUDP packet,
* so we need to remove 'len' bytes from the packet (the UDP
* header and optional ESP marker bytes) and then modify the
@@ -1055,12 +1060,25 @@ int udp_queue_rcv_skb(struct sock * sk,
kfree_skb(skb);
return 0;
}
- if (ret 0) {
+ if (ret == -1) {
/* process the ESP packet */
ret = xfrm4_rcv_encap(skb, up-encap_type);
UDP_INC_STATS_BH(UDP_MIB_INDATAGRAMS, up-pcflag);
return -ret;
}
+ if (ret == -2) {
+ /* process the L2TP packet */
+ if (up-encap_rcv != NULL) {
+ ret = (*up-encap_rcv)(sk, skb);
+ if (ret = 0) {
+ UDP_INC_STATS_BH(UDP_MIB_INDATAGRAMS,
up-pcflag);
+ return ret;
+ }
+
+ /* FALLTHROUGH -- pass up as UDP packet */
+ }
+ }
+
/* FALLTHROUGH -- it's a UDP Packet */
}
@@ -1349,6 +1367,7 @@ int udp_lib_setsockopt(struct sock *sk,
case 0:
case UDP_ENCAP_ESPINUDP:
case UDP_ENCAP_ESPINUDP_NON_IKE:
+ case UDP_ENCAP_L2TPINUDP:
up-encap_type = val;
break;
default:
-
To
[PATCH 2/5 2.6.22-rc6] L2TP: Changes to existing ppp and socket kernel headers for L2TP
Add struct sockaddr_pppol2tp to carry L2TP-specific address
information for the PPPoX (PPPoL2TP) socket. Unfortunately we can't
use the union inside struct sockaddr_pppox because the L2TP-specific
data is larger than the current size of the union and we must preserve
the size of struct sockaddr_pppox for binary compatibility.
Also add a PPPIOCGL2TPSTATS ioctl to allow userspace to obtain
L2TP counters and state from the kernel.
Add new if_pppol2tp.h header.
Signed-off-by: James Chapman [EMAIL PROTECTED]
Index: linux-2.6.22-rc6/include/linux/if_ppp.h
===
--- linux-2.6.22-rc6.orig/include/linux/if_ppp.h
+++ linux-2.6.22-rc6/include/linux/if_ppp.h
@@ -110,6 +110,21 @@ struct ifpppcstatsreq {
struct ppp_comp_stats stats;
};
+/* For PPPIOCGL2TPSTATS */
+struct pppol2tp_ioc_stats {
+ __u16 tunnel_id; /* redundant */
+ __u16 session_id; /* if zero, get tunnel stats */
+ __u32 using_ipsec:1; /* valid only for session_id == 0 */
+ __u64 tx_packets;
+ __u64 tx_bytes;
+ __u64 tx_errors;
+ __u64 rx_packets;
+ __u64 rx_bytes;
+ __u64 rx_seq_discards;
+ __u64 rx_oos_packets;
+ __u64 rx_errors;
+};
+
#define ifr__name b.ifr_ifrn.ifrn_name
#define stats_ptr b.ifr_ifru.ifru_data
@@ -146,6 +161,7 @@ struct ifpppcstatsreq {
#define PPPIOCDISCONN _IO('t', 57)/* disconnect channel */
#define PPPIOCATTCHAN _IOW('t', 56, int) /* attach to ppp channel */
#define PPPIOCGCHAN_IOR('t', 55, int) /* get ppp channel number */
+#define PPPIOCGL2TPSTATS _IOR('t', 54, struct pppol2tp_ioc_stats)
#define SIOCGPPPSTATS (SIOCDEVPRIVATE + 0)
#define SIOCGPPPVER (SIOCDEVPRIVATE + 1) /* NEVER change this!! */
Index: linux-2.6.22-rc6/include/linux/if_pppox.h
===
--- linux-2.6.22-rc6.orig/include/linux/if_pppox.h
+++ linux-2.6.22-rc6/include/linux/if_pppox.h
@@ -27,6 +27,7 @@
#include asm/semaphore.h
#include linux/ppp_channel.h
#endif /* __KERNEL__ */
+#include linux/if_pppol2tp.h
/* For user-space programs to pick up these definitions
* which they wouldn't get otherwise without defining __KERNEL__
@@ -50,8 +51,9 @@ struct pppoe_addr{
* Protocols supported by AF_PPPOX
*/
#define PX_PROTO_OE0 /* Currently just PPPoE */
-#define PX_MAX_PROTO 1
-
+#define PX_PROTO_OL2TP 1 /* Now L2TP also */
+#define PX_MAX_PROTO 2
+
struct sockaddr_pppox {
sa_family_t sa_family;/* address family, AF_PPPOX */
unsigned intsa_protocol; /* protocol identifier */
@@ -60,6 +62,16 @@ struct sockaddr_pppox {
}sa_addr;
}__attribute__ ((packed));
+/* The use of the above union isn't viable because the size of this
+ * struct must stay fixed over time -- applications use sizeof(struct
+ * sockaddr_pppox) to fill it. We use a protocol specific sockaddr
+ * type instead.
+ */
+struct sockaddr_pppol2tp {
+ sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned intsa_protocol;/* protocol identifier */
+ struct pppol2tp_addr pppol2tp;
+}__attribute__ ((packed));
/*
*
Index: linux-2.6.22-rc6/include/linux/socket.h
===
--- linux-2.6.22-rc6.orig/include/linux/socket.h
+++ linux-2.6.22-rc6/include/linux/socket.h
@@ -287,6 +287,7 @@ struct ucred {
#define SOL_NETLINK270
#define SOL_TIPC 271
#define SOL_RXRPC 272
+#define SOL_PPPOL2TP 273
/* IPX options */
#define IPX_TYPE 1
Index: linux-2.6.22-rc6/include/linux/if_pppol2tp.h
===
--- /dev/null
+++ linux-2.6.22-rc6/include/linux/if_pppol2tp.h
@@ -0,0 +1,69 @@
+/***
+ * Linux PPP over L2TP (PPPoL2TP) Socket Implementation (RFC 2661)
+ *
+ * This file supplies definitions required by the PPP over L2TP driver
+ * (pppol2tp.c). All version information wrt this file is located in
pppol2tp.c
+ *
+ * License:
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ */
+
+#ifndef __LINUX_IF_PPPOL2TP_H
+#define __LINUX_IF_PPPOL2TP_H
+
+#include asm/types.h
+
+#ifdef __KERNEL__
+#include linux/in.h
+#endif
+
+/* Structure used to connect() the socket to a particular tunnel UDP
+ * socket.
+ */
+struct pppol2tp_addr
+{
+ pid_t pid;/* pid that owns the fd.
+* 0 = current */
+ int fd;
[PATCH 4/5 2.6.22-rc6] L2TP: Add PPPoL2TP maintainer
Signed-off-by: James Chapman [EMAIL PROTECTED] Index: linux-2.6.22-rc6/MAINTAINERS === --- linux-2.6.22-rc6.orig/MAINTAINERS +++ linux-2.6.22-rc6/MAINTAINERS @@ -2903,6 +2903,11 @@ P: Michal Ostrowski M: [EMAIL PROTECTED] S: Maintained +PPP OVER L2TP +P: James Chapman +M: [EMAIL PROTECTED] +S: Maintained + PREEMPTIBLE KERNEL P: Robert Love M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5 2.6.22-rc6] L2TP: Add PPPoL2TP in-kernel documentation
Signed-off-by: James Chapman [EMAIL PROTECTED] Index: linux-2.6.22-rc6/Documentation/networking/l2tp.txt === --- /dev/null +++ linux-2.6.22-rc6/Documentation/networking/l2tp.txt @@ -0,0 +1,169 @@ +This brief document describes how to use the kernel's PPPoL2TP driver +to provide L2TP functionality. L2TP is a protocol that tunnels one or +more PPP sessions over a UDP tunnel. It is commonly used for VPNs +(L2TP/IPSec) and by ISPs to tunnel subscriber PPP sessions over an IP +network infrastructure. + +Design +== + +The PPPoL2TP driver, drivers/net/pppol2tp.c, provides a mechanism by +which PPP frames carried through an L2TP session are passed through +the kernel's PPP subsystem. The standard PPP daemon, pppd, handles all +PPP interaction with the peer. PPP network interfaces are created for +each local PPP endpoint. + +The L2TP protocol http://www.faqs.org/rfcs/rfc2661.html defines L2TP +control and data frames. L2TP control frames carry messages between +L2TP clients/servers and are used to setup / teardown tunnels and +sessions. An L2TP client or server is implemented in userspace and +will use a regular UDP socket per tunnel. L2TP data frames carry PPP +frames, which may be PPP control or PPP data. The kernel's PPP +subsystem arranges for PPP control frames to be delivered to pppd, +while data frames are forwarded as usual. + +Each tunnel and session within a tunnel is assigned a unique tunnel_id +and session_id. These ids are carried in the L2TP header of every +control and data packet. The pppol2tp driver uses them to lookup +internal tunnel and/or session contexts. Zero tunnel / session ids are +treated specially - zero ids are never assigned to tunnels or sessions +in the network. In the driver, the tunnel context keeps a pointer to +the tunnel UDP socket. The session context keeps a pointer to the +PPPoL2TP socket, as well as other data that lets the driver interface +to the kernel PPP subsystem. + +Note that the pppol2tp kernel driver handles only L2TP data frames; +L2TP control frames are simply passed up to userspace in the UDP +tunnel socket. The kernel handles all datapath aspects of the +protocol, including data packet resequencing (if enabled). + +There are a number of requirements on the userspace L2TP daemon in +order to use the pppol2tp driver. + +1. Use a UDP socket per tunnel. + +2. Create a single PPPoL2TP socket per tunnel bound to a special null + session id. This is used only for communicating with the driver but + must remain open while the tunnel is active. Opening this tunnel + management socket causes the driver to mark the tunnel socket as an + L2TP UDP encapsulation socket and flags it for use by the + referenced tunnel id. This hooks up the UDP receive path via + udp_encap_rcv() in net/ipv4/udp.c. PPP data frames are never passed + in this special PPPoX socket. + +3. Create a PPPoL2TP socket per L2TP session. This is typically done + by starting pppd with the pppol2tp plugin and appropriate + arguments. A PPPoL2TP tunnel management socket (Step 2) must be + created before the first PPPoL2TP session socket is created. + +When creating PPPoL2TP sockets, the application provides information +to the driver about the socket in a socket connect() call. Source and +destination tunnel and session ids are provided, as well as the file +descriptor of a UDP socket. See struct pppol2tp_addr in +include/linux/if_ppp.h. Note that zero tunnel / session ids are +treated specially. When creating the per-tunnel PPPoL2TP management +socket in Step 2 above, zero source and destination session ids are +specified, which tells the driver to prepare the supplied UDP file +descriptor for use as an L2TP tunnel socket. + +Userspace may control behavior of the tunnel or session using +setsockopt and ioctl on the PPPoX socket. The following socket +options are supported:- + +DEBUG - bitmask of debug message categories. See below. +SENDSEQ - 0 = don't send packets with sequence numbers +1 = send packets with sequence numbers +RECVSEQ - 0 = receive packet sequence numbers are optional +1 = drop receive packets without sequence numbers +LNSMODE - 0 = act as LAC. +1 = act as LNS. +REORDERTO - reorder timeout (in millisecs). If 0, don't try to reorder. + +Only the DEBUG option is supported by the special tunnel management +PPPoX socket. + +In addition to the standard PPP ioctls, a PPPIOCGL2TPSTATS is provided +to retrieve tunnel and session statistics from the kernel using the +PPPoX socket of the appropriate tunnel or session. + +Debugging += + +The driver supports a flexible debug scheme where kernel trace +messages may be optionally enabled per tunnel and per session. Care is +needed when debugging a live system since the messages are not +rate-limited and a busy system could be swamped. Userspace uses +setsockopt on the PPPoX socket to set a debug mask. + +The
Re: [PATCH] NET: Multiqueue network device support.
On Tue, 2007-26-06 at 13:57 -0700, David Miller wrote: From: jamal [EMAIL PROTECTED] Date: Tue, 26 Jun 2007 09:27:28 -0400 Back to the question: Do you recall how this number was arrived at? 128 packets will be sent out at GiGe in about 80 microsecs, so from a feel-the-wind-direction perspective it seems reasonable. I picked it out of a hat. It is not a bad value for Gige; doubt it will be a good one for 10/100 or even 10GE. But you could say that about the ring sizes too. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5 2.6.22-rc6] UDP: Introduce UDP encapsulation type for L2TP
From: James Chapman [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 23:20:38 +0100 This patch adds a new UDP_ENCAP_L2TPINUDP encapsulation type for UDP sockets. When a UDP socket's encap_type is UDP_ENCAP_L2TPINUDP, the skb is delivered to a function pointed to by the udp_sock's encap_rcv funcptr. If the skb isn't wanted by L2TP, it returns 0, which causes it to be passed through to UDP. Include padding to put the new encap_rcv field on a 4-byte boundary. Previously, the only user of UDP encap sockets was ESP, so when CONFIG_XFRM was not defined, some of the encap code was compiled out. This patch changes that. As a result, udp_encap_rcv() will now do a little more work when CONFIG_XFRM is not defined. Signed-off-by: James Chapman [EMAIL PROTECTED] Patch applied, thanks. Note that we could use the callback pointer for the XFRM case too, and I kind of thought you would understand that logical progression and implement that too :-/ That way we don't need any funny return values, there is just one and it simply triggers the callback. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5 2.6.22-rc6] L2TP: Changes to existing ppp and socket kernel headers for L2TP
From: James Chapman [EMAIL PROTECTED]
Date: Wed, 27 Jun 2007 23:20:38 +0100
Add struct sockaddr_pppol2tp to carry L2TP-specific address
information for the PPPoX (PPPoL2TP) socket. Unfortunately we can't
use the union inside struct sockaddr_pppox because the L2TP-specific
data is larger than the current size of the union and we must preserve
the size of struct sockaddr_pppox for binary compatibility.
Also add a PPPIOCGL2TPSTATS ioctl to allow userspace to obtain
L2TP counters and state from the kernel.
Add new if_pppol2tp.h header.
Signed-off-by: James Chapman [EMAIL PROTECTED]
...
+/* For PPPIOCGL2TPSTATS */
+struct pppol2tp_ioc_stats {
+ __u16 tunnel_id; /* redundant */
+ __u16 session_id; /* if zero, get tunnel stats */
+ __u32 using_ipsec:1; /* valid only for session_id == 0 */
+ __u64 tx_packets;
+ __u64 tx_bytes;
+ __u64 tx_errors;
+ __u64 rx_packets;
+ __u64 rx_bytes;
+ __u64 rx_seq_discards;
+ __u64 rx_oos_packets;
+ __u64 rx_errors;
+};
This is going to cause problems on compat platforms where
__u64 is aligned on an 8-byte boundary on the 64-bit
variant but it is not on the 32-bit cpu variant.
A way to avoid this is to use the aligned_u64 type from
linux/types.h which ensures 8-byte alignment on all
platforms and thus you won't need to provide s compat
ioctl() handler for your statistics ioctl().
I'll make this change for you so we don't have to go
back and forth again just for this.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH UPDATE #2] Ethernet driver for EISA only SNI RM200/RM400 machines
Changes to last version:
- spelling fix
- cleaned up probe code
Thomas.
Ethernet driver for EISA only SNI RM200/RM400 machines
Signed-off-by: Thomas Bogendoerfer [EMAIL PROTECTED]
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b0d0d73..af5c90f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -435,6 +435,13 @@ config LASI_82596
Say Y here to support the builtin Intel 82596 ethernet controller
found in Hewlett-Packard PA-RISC machines with 10Mbit ethernet.
+config SNI_82596
+ tristate SNI RM ethernet
+ depends on NET_ETHERNET SNI_RM
+ help
+ Say Y here to support the on-board Intel 82596 ethernet controller
+ built into SNI RM machines.
+
config MIPS_JAZZ_SONIC
tristate MIPS JAZZ onboard SONIC Ethernet support
depends on NET_ETHERNET MACH_JAZZ
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d268b49..b03270c 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -161,6 +161,7 @@ obj-$(CONFIG_ELPLUS) += 3c505.o
obj-$(CONFIG_AC3200) += ac3200.o 8390.o
obj-$(CONFIG_APRICOT) += 82596.o
obj-$(CONFIG_LASI_82596) += lasi_82596.o
+obj-$(CONFIG_SNI_82596) += sni_82596.o
obj-$(CONFIG_MVME16x_NET) += 82596.o
obj-$(CONFIG_BVME6000_NET) += 82596.o
obj-$(CONFIG_SC92031) += sc92031.o
diff --git a/drivers/net/sni_82596.c b/drivers/net/sni_82596.c
new file mode 100644
index 000..2cf6794
--- /dev/null
+++ b/drivers/net/sni_82596.c
@@ -0,0 +1,185 @@
+/*
+ * sni_82596.c -- driver for intel 82596 ethernet controller, as
+ * used in older SNI RM machines
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/string.h
+#include linux/errno.h
+#include linux/ioport.h
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/skbuff.h
+#include linux/init.h
+#include linux/types.h
+#include linux/bitops.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/irq.h
+
+#define SNI_82596_DRIVER_VERSION SNI RM 82596 driver - Revision: 0.01
+
+static const char sni_82596_string[] = snirm_82596;
+
+#define DMA_ALLOC dma_alloc_coherent
+#define DMA_FREE dma_free_coherent
+#define DMA_WBACK(priv, addr, len) do { } while (0)
+#define DMA_INV(priv, addr, len) do { } while (0)
+#define DMA_WBACK_INV(priv, addr, len) do { } while (0)
+
+#define SYSBUS 0x4400
+
+/* big endian CPU, 82596 little endian */
+#define SWAP32(x) cpu_to_le32((u32)(x))
+#define SWAP16(x) cpu_to_le16((u16)(x))
+
+#define OPT_MPU_16BIT0x01
+
+#include lib82596.c
+
+MODULE_AUTHOR(Thomas Bogendoerfer);
+MODULE_DESCRIPTION(i82596 driver);
+MODULE_LICENSE(GPL);
+module_param(i596_debug, int, 0);
+MODULE_PARM_DESC(i596_debug, 82596 debug mask);
+
+static inline void ca(struct net_device *dev)
+{
+ struct i596_private *lp = netdev_priv(dev);
+
+ writel(0, lp-ca);
+}
+
+
+static void mpu_port(struct net_device *dev, int c, dma_addr_t x)
+{
+ struct i596_private *lp = netdev_priv(dev);
+
+ u32 v = (u32) (c) | (u32) (x);
+
+ if (lp-options OPT_MPU_16BIT) {
+ writew(v 0x, lp-mpu_port);
+ wmb(); /* order writes to MPU port */
+ udelay(1);
+ writew(v 16, lp-mpu_port);
+ } else {
+ writel(v, lp-mpu_port);
+ wmb(); /* order writes to MPU port */
+ udelay(1);
+ writel(v, lp-mpu_port);
+ }
+}
+
+
+static int __devinit sni_82596_probe(struct platform_device *dev)
+{
+ struct net_device *netdevice;
+ struct i596_private *lp;
+ struct resource *res, *ca, *idprom, *options;
+ int retval = -ENOMEM;
+ void __iomem *mpu_addr;
+ void __iomem *ca_addr;
+ u8 __iomem *eth_addr;
+
+ res = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ ca = platform_get_resource(dev, IORESOURCE_MEM, 1);
+ options = platform_get_resource(dev, 0, 0);
+ idprom = platform_get_resource(dev, IORESOURCE_MEM, 2);
+ if (!res || !ca || !options || !idprom)
+ return -ENODEV;
+ mpu_addr = ioremap_nocache(res-start, 4);
+ if (!mpu_addr)
+ return -ENOMEM;
+ ca_addr = ioremap_nocache(ca-start, 4);
+ if (!ca_addr)
+ goto probe_failed_free_mpu;
+
+ printk(KERN_INFO Found i82596 at 0x%x\n, res-start);
+
+ netdevice = alloc_etherdev(sizeof(struct i596_private));
+ if (!netdevice)
+ goto probe_failed_free_ca;
+
+ SET_NETDEV_DEV(netdevice, dev-dev);
+ platform_set_drvdata (dev, netdevice);
+
+ netdevice-base_addr = res-start;
+ netdevice-irq = platform_get_irq(dev, 0);
+
+ eth_addr = ioremap_nocache(idprom-start, 0x10);
+ if (!eth_addr)
+ goto probe_failed;
+
+ /* someone seems to like messed up stuff
Re: [PATCH 3/5 2.6.22-rc6] L2TP: PPP over L2TP driver core
From: James Chapman [EMAIL PROTECTED]
Date: Wed, 27 Jun 2007 23:20:38 +0100
This driver handles only L2TP data frames; control frames are handled
by a userspace application. It implements L2TP using the PPPoX socket
family. There is a PPPoX socket for each L2TP session in an L2TP tunnel.
PPP data within each session is passed through the kernel's
PPP subsystem via this driver. Kernel parameters of each socket can be
read or modified using ioctl() or [gs]etsockopt() calls.
Signed-off-by: James Chapman [EMAIL PROTECTED]
Applied, and I added the following build warning fix on top:
commit 24c65a03093b1c33fb90bbae6a024d161faa437a
Author: David S. Miller [EMAIL PROTECTED]
Date: Wed Jun 27 15:52:25 2007 -0700
[PPPOL2TP]: Use proper printf format specifier for size_t.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/drivers/net/pppol2tp.c b/drivers/net/pppol2tp.c
index 8a6bff5..5891a0f 100644
--- a/drivers/net/pppol2tp.c
+++ b/drivers/net/pppol2tp.c
@@ -890,11 +890,11 @@ static int pppol2tp_sendmsg(struct kiocb *iocb, struct
socket *sock, struct msgh
/* Debug */
if (session-send_seq)
PRINTK(session-debug, PPPOL2TP_MSG_DATA, KERN_DEBUG,
- %s: send %d bytes, ns=%hu\n, session-name,
+ %s: send %Zd bytes, ns=%hu\n, session-name,
total_len, session-ns - 1);
else
PRINTK(session-debug, PPPOL2TP_MSG_DATA, KERN_DEBUG,
- %s: send %d bytes\n, session-name, total_len);
+ %s: send %Zd bytes\n, session-name, total_len);
if (session-debug PPPOL2TP_MSG_DATA) {
int i;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5 2.6.22-rc6] L2TP: Add PPPoL2TP maintainer
From: James Chapman [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 23:20:38 +0100 Signed-off-by: James Chapman [EMAIL PROTECTED] Patch applied. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5 2.6.22-rc6] L2TP: Add PPPoL2TP in-kernel documentation
From: James Chapman [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 23:20:38 +0100 Signed-off-by: James Chapman [EMAIL PROTECTED] Also applied, thanks a lot. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: Multiqueue network device support.
From: jamal [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 18:32:45 -0400 On Tue, 2007-26-06 at 13:57 -0700, David Miller wrote: From: jamal [EMAIL PROTECTED] Date: Tue, 26 Jun 2007 09:27:28 -0400 Back to the question: Do you recall how this number was arrived at? 128 packets will be sent out at GiGe in about 80 microsecs, so from a feel-the-wind-direction perspective it seems reasonable. I picked it out of a hat. It is not a bad value for Gige; doubt it will be a good one for 10/100 or even 10GE. But you could say that about the ring sizes too. The thing that's really important is that the value is not so large such that the TX ring can become empty. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote:
I wonder if we should hold off on this API until we've worked out the
multicast issue.
Even if the ACPI thing goes in first, you will have to change a few
others that are existing in-kernel that need to be changed sooner or
later. So either way is fine.
My proposition for the actual dynamic registration interface would be to
add a .groups array to pointers to struct genl_family with that just
being
struct genl_multicast_group {
char *name;
u32 id;
}
heres some feedback:
- I think you should use the same approach as we use for ops.
a) i.e other than the reserved group for controller (which you seem to
be taking care of), every other genetlink user has to explicitly
register when they need a mcast group.
b) While the names may vary on a per-family basis, the Grpids should be
unique (e.g when you run out of group ids - it would take a lot more
allocations than there are families; 32 bit vs 16 bit for that to
happen)
c) Use a global hash table to store all the genl_multicast_groups;
I think this (handwaving) should be searchable by i) name ii)ID and iii)
family.
--- wireless-dev.orig/include/net/genetlink.h 2007-06-25 23:56:59.085732308
+0200
+++ wireless-dev/include/net/genetlink.h 2007-06-26 00:01:43.935732308
+0200
@@ -5,12 +5,26 @@
#include net/netlink.h
/**
+ * struct genl_multicast_group - generic netlink multicast group
+ * @name: name of the multicast group, names are per-family
+ * @id: multicast group ID, assigned by the core, to use with
+ * genlmsg_multicast().
+ */
+struct genl_multicast_group
+{
+ charname[GENL_NAMSIZ];
+ u32 id;
+};
Add the list constructs on the struct - look at the way commands are
done.
We do use hash tables for global storage of families for example.
+/**
* struct genl_family - generic netlink family
* @id: protocol family idenfitier
* @hdrsize: length of user specific header in bytes
* @name: name of family
* @version: protocol version
* @maxattr: maximum number of attributes supported
+ * @multicast_groups: multicast groups to be registered
+ * for this family (%NULL-terminated array)
* @attrbuf: buffer to store parsed attributes
* @ops_list: list of all assigned operations
* @family_list: family list
@@ -22,6 +36,7 @@ struct genl_family
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
+ struct genl_multicast_group **multicast_groups;
If you do the lists (struct list_head) you wont need this.
+static unsigned long mcast_group_start = 0x3;
+static unsigned long *multicast_groups = mcast_group_start;
+static unsigned long multicast_group_bits = BITS_PER_LONG;
I think if you used a hash table you wont need to keep track of the
above; maybe not - You may still need the above to keep track of which
IDs are in use and where holes in multicast group ID space exist
(assuming some are going to be unregistered over time etc)
+
+static int genl_register_mcast_groups(struct genl_family *family)
+{
we use a simple scheme in the case of families; once all
IDs are consumed we dont alloc more - in the case of mcast grps this is
not necessary IMO i.e it doesnt matter if there is collision when you
run out. You return errors at the moment.
--- wireless-dev.orig/include/linux/genetlink.h 2007-06-25
23:56:19.895732308 +0200
+++ wireless-dev/include/linux/genetlink.h2007-06-26 00:33:36.785732308
+0200
@@ -52,6 +52,9 @@ enum {
CTRL_ATTR_HDRSIZE,
CTRL_ATTR_MAXATTR,
CTRL_ATTR_OPS,
+ CTRL_ATTR_MCAST_GROUPS,
+ CTRL_ATTR_MCAST_GRP_NAME,
+ CTRL_ATTR_MCAST_GRP_ID,
Dont think those last two belong in the same namespace. i.e they should
be a separate enum; even more the name/id pair probably belong in one
TLV under the struct genl_multicast_group that is exported to user
space.
Overall: I think you are on the right path. Good stuff.
I see user space doing a discovery of which groups a family belongs to
or even doing a bind-by-name in which the underlying user-space code
does a discovery to find the id, then does a bind to that id.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[WIP][PATCHES] Network xmit batching - tg3 support
peoplez,
I have added support for tg3 on batching. I see equivalent performance
improvement for pktgen as i did with e1000 when using gige.
I have only tested on two machines (one being a laptop which does
10/100Mbps). Unfortunately in both cases these are considered to be in
the class of buggy tg3s (which take a longer code path).
To the tg3 folks - can you double check if am off on something?
I have split a few things that you may like as well.
I havent upgraded the tree - it is still circa 2.6.22-rc4 based; at some
point i will sync with Daves net-26
Anyone who has tg3 based hardware: I would appreciate any testing and
results ...
The git tree is at:
git://git.kernel.org/pub/scm/linux/kernel/git/hadi/batch-lin26.git
but i have attached the patch in case you just wanna stare.
cheers,
jamal
commit 91859b60521653a2f72ac70dfe9bfada4fdb28cb
Author: Jamal Hadi Salim [EMAIL PROTECTED]
Date: Wed Jun 27 19:50:35 2007 -0400
[NET_BATCH] Add tg3 batch support
Make tg3 use the batch api.
I have tested on my old laptop and another server class
machine; they all seem to work - unfortunately they are
both considered old class tg3.
I am sure theres improvements to be made, but this is as a
functional good start.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2f31841..be03cbd 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -581,6 +581,7 @@ static inline void tg3_netif_stop(struct tg3 *tp)
static inline void tg3_netif_start(struct tg3 *tp)
{
netif_wake_queue(tp-dev);
+ tp-dev-xmit_win = TG3_TX_RING_SIZE 2;
/* NOTE: unconditional netif_wake_queue is only appropriate
* so long as all callers are assured to have free tx slots
* (such as after tg3_init_hw)
@@ -3066,6 +3067,7 @@ static inline u32 tg3_tx_avail(struct tg3 *tp)
*/
static void tg3_tx(struct tg3 *tp)
{
+ int dcount;
u32 hw_idx = tp-hw_status-idx[0].tx_consumer;
u32 sw_idx = tp-tx_cons;
@@ -3118,12 +3120,16 @@ static void tg3_tx(struct tg3 *tp)
*/
smp_mb();
+ dcount = tg3_tx_avail(tp);
if (unlikely(netif_queue_stopped(tp-dev)
-(tg3_tx_avail(tp) TG3_TX_WAKEUP_THRESH(tp {
+(dcount TG3_TX_WAKEUP_THRESH(tp {
netif_tx_lock(tp-dev);
+ tp-dev-xmit_win = 1;
if (netif_queue_stopped(tp-dev)
- (tg3_tx_avail(tp) TG3_TX_WAKEUP_THRESH(tp)))
+ (dcount TG3_TX_WAKEUP_THRESH(tp))) {
netif_wake_queue(tp-dev);
+ tp-dev-xmit_win = dcount;
+ }
netif_tx_unlock(tp-dev);
}
}
@@ -3877,47 +3883,56 @@ static void tg3_set_txd(struct tg3 *tp, int entry,
txd-vlan_tag = vlan_tag TXD_VLAN_TAG_SHIFT;
}
-/* hard_start_xmit for devices that don't have any bugs and
- * support TG3_FLG2_HW_TSO_2 only.
- */
-static int tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
-{
- struct tg3 *tp = netdev_priv(dev);
- dma_addr_t mapping;
- u32 len, entry, base_flags, mss;
-
- len = skb_headlen(skb);
+struct tg3_tx_cbdata {
+ u32 base_flags;
+ int count;
+ unsigned int max_per_txd;
+ unsigned int nr_frags;
+ unsigned int mss;
+};
+#define TG3_SKB_CB(__skb) ((struct tg3_tx_cbdata *)((__skb)-cb[0]))
+#define NETDEV_TX_DROPPED -5
- /* We are running in BH disabled context with netif_tx_lock
-* and TX reclaim runs via tp-poll inside of a software
-* interrupt. Furthermore, IRQ processing runs lockless so we have
-* no IRQ context deadlocks to worry about either. Rejoice!
-*/
- if (unlikely(tg3_tx_avail(tp) = (skb_shinfo(skb)-nr_frags + 1))) {
- if (!netif_queue_stopped(dev)) {
- netif_stop_queue(dev);
+static int tg3_prep_bug_frame(struct sk_buff *skb, struct net_device *dev)
+{
+ struct tg3_tx_cbdata *cb = TG3_SKB_CB(skb);
- /* This is a hard error, log it. */
- printk(KERN_ERR PFX %s: BUG! Tx Ring full when
- queue awake!\n, dev-name);
+ cb-base_flags = 0;
+ cb-mss = skb_shinfo(skb)-gso_size;
+ if (cb-mss != 0) {
+ if (skb_header_cloned(skb)
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
+ dev_kfree_skb(skb);
+ return NETDEV_TX_DROPPED;
}
- return NETDEV_TX_BUSY;
+
+ cb-base_flags |= (TXD_FLAG_CPU_PRE_DMA |
+ TXD_FLAG_CPU_POST_DMA);
}
- entry = tp-tx_prod;
- base_flags = 0;
- mss = 0;
- if ((mss = skb_shinfo(skb)-gso_size) != 0) {
+ if (skb-ip_summed == CHECKSUM_PARTIAL)
+ cb-base_flags |=
Re: [PATCH] NET: Multiqueue network device support.
On Wed, 2007-27-06 at 15:54 -0700, David Miller wrote: The thing that's really important is that the value is not so large such that the TX ring can become empty. In the case of batching, varying the values makes a difference. The logic is that if you can tune it so that the driver takes sufficiently long to stay closed the more packets you accumulate at the qdisc and the more you can batch to the driver (when it opens up). Deciding what sufficiently long is an art - and i am sure speed dependent. With e1000 at gige 128 seems to be a good value, going above or below that gave lesser performance. cheers, jamal - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET: Multiqueue network device support.
From: jamal [EMAIL PROTECTED] Date: Wed, 27 Jun 2007 20:15:47 -0400 On Wed, 2007-27-06 at 15:54 -0700, David Miller wrote: The thing that's really important is that the value is not so large such that the TX ring can become empty. In the case of batching, varying the values makes a difference. The logic is that if you can tune it so that the driver takes sufficiently long to stay closed the more packets you accumulate at the qdisc and the more you can batch to the driver (when it opens up). Deciding what sufficiently long is an art - and i am sure speed dependent. With e1000 at gige 128 seems to be a good value, going above or below that gave lesser performance. Right. And another thing you want to moderate is lock hold times, perhaps even at the slight expense of performance. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled
Hi Oleg, On 6/27/07, Oleg Nesterov [EMAIL PROTECTED] wrote: On 06/27, Satyam Sharma wrote: Thanks for your comments, I'm still not convinced, however. An perhaps you are right. I don't have a very strong opinion on that. Still I can't understand why it is better if kthread_stop() sends a signal as well. [...] One can always use force_sig() or allow_signal() + send_sig() when it is really needed, like cifs does. The way I look at it, this is about an API being the one with least surprise. So when one writes a kthread using its API, one would expect kthread_stop() to dtrt and just work, which it will not, if the kthread has one of such functions (which are just like any other, after all). Also, imagine such a function being added to a kthread that didn't have it previously ... the solution to which (sending a signal before kthread_stop) is un-intuitive. Hence, why not make it part of the API itself ... It's not like the signal would do any harm to other kthreads (that don't use such function) either. Contrary, I believe we should avoid signals when it comes to kernel threads. And I agree, but there's quite a subtle difference between signals being used like they normally are, and this case here. Fact is, there is simply no other way to break out of certain functions (if there was, I would've preferred that myself). In fact, what I'm proposing is that kthreads should *not* be tinkering with (flushing, handling, dequeueing, whatever) signals at all, because like you mentioned, if they do that, it's possible that the TIF_SIGPENDING could get lost. Anyway, I think _all_ usages of kthread_stop() in the kernel *do* want the thread to stop *right then*. After all, kthread_stop() doesn't even return (gets blocked on wait_for_completion()) till it knows the target kthread *has* exited completely. Yes, kthread_stop(k) means that k should exit eventually, but I don't think that kthread_stop() should try to force the exit. Well, it's just an additional notice (apart from setting kthread_stop_info) sent to the target kthread that its time has come ... I'm not sure how a kthread would have exit forced upon it just by sending it a signal. Also, note that _not_ using a signal would in fact mean that the kthread _never_ exits at all (forget asap). I am talking about the case when wait_event_interruptible() should not fail (unless something bad happens) inside the while (!kthread_should_stop()) loop. Note also that kthread could use TASK_INTERRUPTIBLE sleep [...] and because it knows that all signals are ignored. Ok, I think you're saying that if a kthread used wait_event_interruptible (and was not expecting signals, because it ignores them), then bad things (say exit in inconsistent state, etc) will happen if we break that wait_event_interruptible unexpectedly. First, such an error ought to be handled gracefully by kthread itself anyway -- anybody who doesn't check the return of _interruptible() functions is just asking for trouble. Second, the kthread must expect that the stop notification _could_ have come during that sleep (in fact all good kthreads I've seen do always put a kthread_should_stop() after all such blocking functions, and not only in the while loop's condition) -- but even if it doesn't check explicitly, what do we lose? If the kthread code _after_ the wait_event_interruptible is written such that it assumes that the wait condition has become true (as I mentioned above), then that code is inherently buggy. And thirdly, what I'm proposing is putting the check for checking the SIGKILL in kthread_should_stop itself, in /addition/ to the kthread_stop_info.k == current check. So the kthread will check should_stop(), and if true, then exiting cleanly -- this is something that all existing kthreads would do already (if some kthread out there exits _uncleanly_ even after seeing seeing kthread_should_stop == true, then it needs fixing anyway). Satyam - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22-rc5] TCP: Make TCP_RTO_MAX a variable
In article [EMAIL PROTECTED] (at Mon, 25 Jun 2007 22:09:39 +0900 (JST)), OBATA Noboru [EMAIL PROTECTED] says: Please note that this is effective in IPv6 as well. Of course, I'm happy with this. --yoshfuji - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
