* Re: [net-next-2.6 PATCH v5 5/5 RFC] TCPCT part1e: initial SYN exchange with SYNACK data
From: William Allen Simpson @ 2009-11-11 17:35 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: Eric Dumazet, Linux Kernel Network Developers, Joe Perches
In-Reply-To: <alpine.DEB.2.00.0911110235270.2864@melkinpaasi.cs.helsinki.fi>
Ilpo Järvinen wrote:
> On Tue, 10 Nov 2009, William Allen Simpson wrote:
>> Well, that's what I did with the (now) parts 1b, 1c, and 1d, but somebody
>> complained that the callers didn't exist yet.
>
> I guess there's misunderstanding here. Yes, if you bring in new helpers
> that solely are used with your feature, then it that feature patch (and
> I found DaveM commenting specifically this point I think), or right
> beforehand with a clear note that it will be used in the subsequent patch.
If I understand correctly, in that case I look forward to your Ack for
part 1d, a self-contained "helper" feature patch "with a clear note".
^ permalink raw reply
* Re: [PATCH resent] Documentation: rw_lock lessons learned
From: Stephen Hemminger @ 2009-11-11 17:37 UTC (permalink / raw)
To: William Allen Simpson
Cc: Paul E. McKenney, Linus Torvalds, Linux Kernel Developers,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <4AFAEF78.4080807@gmail.com>
On Wed, 11 Nov 2009 12:08:08 -0500
William Allen Simpson <william.allen.simpson@gmail.com> wrote:
> Stephen Hemminger wrote:
> > I would rather see the text in Documentation/spinlocks give an explaination
> > as to why reader/writer locks are normally not desirable.
> >
> > The whole document needs work to make it a developer document, rather than
> > a historical mail thread.. A good document says what should be done today,
> > and does not have old junk or ask the reader to overly new context
> > on old information.
> >
> You wish me to merge our patches?
Sure, I am more concerned about document structure being readable than
preserving my sloppy prose.
> Or this is a second patch in a proposed series?
No. But taking more input from others (maybe Randy will help he is a good
editor) would get this back in shape.
--
^ permalink raw reply
* [PATCH 1/2] decnet: add RTNL lock when reading address list
From: Stephen Hemminger @ 2009-11-11 17:39 UTC (permalink / raw)
To: steve, David Miller
Cc: Eric Dumazet, Christine Caulfield, Hannes Eder, Alexey Dobriyan,
Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <20091110182436.GA13374@fogou.chygwyn.com>
Add missing locking in the case of auto binding to the
default device. The address list might change while this code is looking
at the list.
Compile tested only, I am not a decnet user.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/decnet/dn_dev.c 2009-11-11 09:18:02.935313559 -0800
+++ b/net/decnet/dn_dev.c 2009-11-11 09:22:32.157313924 -0800
@@ -828,13 +828,17 @@ static int dn_dev_get_first(struct net_d
struct dn_dev *dn_db = (struct dn_dev *)dev->dn_ptr;
struct dn_ifaddr *ifa;
int rv = -ENODEV;
+
if (dn_db == NULL)
goto out;
+
+ rtnl_lock();
ifa = dn_db->ifa_list;
if (ifa != NULL) {
*addr = ifa->ifa_local;
rv = 0;
}
+ rtnl_unlock();
out:
return rv;
}
^ permalink raw reply
* [PATCH 2/2] decnet: convert dndev_lock to spinlock
From: Stephen Hemminger @ 2009-11-11 17:40 UTC (permalink / raw)
To: steve, David Miller
Cc: Eric Dumazet, Christine Caulfield, Hannes Eder, Alexey Dobriyan,
Steven Whitehouse, netdev, linux-decnet-users
In-Reply-To: <20091111093927.4a08999d@nehalam>
There is no reason for this lock to be reader/writer since
the reader only has lock held for a very brief period.
The overhead of read_lock is more expensive than spinlock.
Compile tested only, I am not a decnet user.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/decnet/dn_dev.c 2009-11-10 17:39:53.652984752 -0800
+++ b/net/decnet/dn_dev.c 2009-11-10 17:41:15.942736073 -0800
@@ -68,7 +68,7 @@ extern struct neigh_table dn_neigh_table
*/
__le16 decnet_address = 0;
-static DEFINE_RWLOCK(dndev_lock);
+static DEFINE_SPINLOCK(dndev_lock);
static struct net_device *decnet_default_device;
static BLOCKING_NOTIFIER_HEAD(dnaddr_chain);
@@ -557,7 +557,8 @@ rarok:
struct net_device *dn_dev_get_default(void)
{
struct net_device *dev;
- read_lock(&dndev_lock);
+
+ spin_lock(&dndev_lock);
dev = decnet_default_device;
if (dev) {
if (dev->dn_ptr)
@@ -565,7 +566,8 @@ struct net_device *dn_dev_get_default(vo
else
dev = NULL;
}
- read_unlock(&dndev_lock);
+ spin_unlock(&dndev_lock);
+
return dev;
}
@@ -575,13 +577,15 @@ int dn_dev_set_default(struct net_device
int rv = -EBUSY;
if (!dev->dn_ptr)
return -ENODEV;
- write_lock(&dndev_lock);
+
+ spin_lock(&dndev_lock);
if (force || decnet_default_device == NULL) {
old = decnet_default_device;
decnet_default_device = dev;
rv = 0;
}
- write_unlock(&dndev_lock);
+ spin_unlock(&dndev_lock);
+
if (old)
dev_put(old);
return rv;
@@ -589,13 +593,14 @@ int dn_dev_set_default(struct net_device
static void dn_dev_check_default(struct net_device *dev)
{
- write_lock(&dndev_lock);
+ spin_lock(&dndev_lock);
if (dev == decnet_default_device) {
decnet_default_device = NULL;
} else {
dev = NULL;
}
- write_unlock(&dndev_lock);
+ spin_unlock(&dndev_lock);
+
if (dev)
dev_put(dev);
}
^ permalink raw reply
* RE: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Sean Hefty @ 2009-11-11 18:18 UTC (permalink / raw)
To: 'Eric Dumazet', David S. Miller
Cc: Linux Netdev List, Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <4AF8EBA4.2070102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>for_each_netdev() should be used with RTNL or dev_base_lock held,
>or risk a crash.
>
>Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Thanks - I'm working on a patch set in this area. Roland, I can merge Eric's
changes into that patch set if it makes things easier.
> drivers/infiniband/core/addr.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
>index bd07803..5ca0b2c 100644
>--- a/drivers/infiniband/core/addr.c
>+++ b/drivers/infiniband/core/addr.c
>@@ -131,6 +131,7 @@ int rdma_translate_ip(struct sockaddr *addr, struct
The changes to this function are still valid.
>@@ -391,15 +393,17 @@ static int addr_resolve_local(struct sockaddr *src_in,
This function is going away.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] sctp: Fix regression introduced by new sctp_connectx api
From: Vlad Yasevich @ 2009-11-11 18:19 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-sctp, Vlad Yasevich
A new (unrealeased to the user) sctp_connectx api
c6ba68a26645dbc5029a9faa5687ebe6fcfc53e4
sctp: support non-blocking version of the new sctp_connectx() API
introduced a regression cought by the user regression test
suite. In particular, the API requires the user library to
re-allocate the buffer and could potentially trigger a SIGFAULT.
This change corrects that regression by passing the original
address buffer to the kernel unmodified, but still allows for
a returned association id.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
---
net/sctp/socket.c | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index bf705ba..3a95fcb 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1276,22 +1276,30 @@ SCTP_STATIC int sctp_setsockopt_connectx(struct sock* sk,
}
/*
- * New (hopefully final) interface for the API. The option buffer is used
- * both for the returned association id and the addresses.
+ * New (hopefully final) interface for the API.
+ * We use the sctp_getaddrs_old structure so that use-space library
+ * can avoid any unnecessary allocations. The only defferent part
+ * is that we store the actual length of the address buffer into the
+ * addrs_num structure member. That way we can re-use the existing
+ * code.
*/
SCTP_STATIC int sctp_getsockopt_connectx3(struct sock* sk, int len,
char __user *optval,
int __user *optlen)
{
+ struct sctp_getaddrs_old param;
sctp_assoc_t assoc_id = 0;
int err = 0;
- if (len < sizeof(assoc_id))
+ if (len < sizeof(param))
return -EINVAL;
+ if (copy_from_user(¶m, optval, sizeof(param)))
+ return -EFAULT;
+
err = __sctp_setsockopt_connectx(sk,
- (struct sockaddr __user *)(optval + sizeof(assoc_id)),
- len - sizeof(assoc_id), &assoc_id);
+ (struct sockaddr __user *)param.addrs,
+ param.addr_num, &assoc_id);
if (err == 0 || err == -EINPROGRESS) {
if (copy_to_user(optval, &assoc_id, sizeof(assoc_id)))
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] rps: changes to bnx2x to get device hash
From: Stephen Hemminger @ 2009-11-11 18:19 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <65634d660911102253lbfc0927i4e4c0eba6d7d765d@mail.gmail.com>
On Tue, 10 Nov 2009 22:53:36 -0800
Tom Herbert <therbert@google.com> wrote:
> +
> + if (get_hdrhash && (cqe_fp_status_flags &
> + ETH_FAST_PATH_RX_CQE_RSS_HASH_FLG)) {
> + u8 hash_type = cqe_fp_status_flags &
> + ETH_FAST_PATH_RX_CQE_RSS_HASH_TYPE;
> +
> + skb->rxhash = le32_to_cpu(
> + cqe->fast_path_cqe.rss_hash_result);
> + if (!skb->rxhash)
> + skb->rxhash = 1;
> +
> + /* unicast IPv4 packet? */
> + if (((hash_type == IPV4_HASH_TYPE) ||
> + (hash_type == TCP_IPV4_HASH_TYPE)) &&
> + (cqe_fp_pars_flags &
> + PARSING_FLAGS_ETHERNET_ADDRESS_TYPE)) {
> + skb->dev = bp->dev;
> + skb_reset_mac_header(skb);
> + skb_pull(skb, ETH_HLEN);
> + skb->protocol =
> + __constant_htons(ETH_P_IP);
> + } else
> + skb->protocol =
> + eth_type_trans(skb, bp->dev);
> + } else
> + skb->protocol = eth_type_trans(skb, bp->dev);
How about putting this all in an inline function:
static inline u16 bn2x_get_type(...) {
}
skb->protocol = bn2x_get_type(...);
Then you won't have two calls to eth_type_trans,
Also: __constant_htons() should not be used directly (except switch statements),
macro for htons() does it automatically if argument is constant.
^ permalink raw reply
* r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Raimonds Cicans @ 2009-11-11 18:20 UTC (permalink / raw)
To: romieu; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: r8169-mtu1536.patch --]
[-- Type: text/plain, Size: 938 bytes --]
Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
1) exact number depends on some factors:
- VLAN tagged or not
- patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
applied or not
Bonus: got rid of magic number 8
Signed-off-by: Raimonds Cicans <ray@apollo.lv>
---
--- linux-2.6.31/drivers/net/r8169.c.orig 2009-11-06 21:52:12.722326601 +0200
+++ linux-2.6.31/drivers/net/r8169.c 2009-11-06 22:09:17.242224014 +0200
@@ -2229,9 +2229,9 @@ static void __devexit rtl8169_remove_one
static void rtl8169_set_rxbufsize(struct rtl8169_private *tp,
struct net_device *dev)
{
- unsigned int mtu = dev->mtu;
+ unsigned int max_frame = dev->mtu + VLAN_ETH_HLEN + ETH_FCS_LEN;
- tp->rx_buf_sz = (mtu > RX_BUF_SIZE) ? mtu + ETH_HLEN + 8 : RX_BUF_SIZE;
+ tp->rx_buf_sz = (max_frame > RX_BUF_SIZE) ? max_frame : RX_BUF_SIZE;
}
static int rtl8169_open(struct net_device *dev)
^ permalink raw reply
* [PATCH] SUNRPC: Address buffer overrun in rpc_uaddr2sockaddr()
From: Chuck Lever @ 2009-11-11 18:22 UTC (permalink / raw)
To: argp-YZAGAMbGdGKGw+nKnLezzg
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
The size of buf[] must account for the string termination needed for
the first strict_strtoul() call.
Fábio Olivé Leite points out that strict_strtoul() requires _either_
'\n\0' _or_ '\0' termination, so use the simpler '\0' here instead.
See http://bugzilla.kernel.org/show_bug.cgi?id=14546 .
Reported-by: argp-YZAGAMbGdGKGw+nKnLezzg@public.gmane.org
Signed-off-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Fábio Olivé Leite <fleite-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Would you please test this fix to see if it addresses the problem?
net/sunrpc/addr.c | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/sunrpc/addr.c b/net/sunrpc/addr.c
index 22e8fd8..c7450c8 100644
--- a/net/sunrpc/addr.c
+++ b/net/sunrpc/addr.c
@@ -306,24 +306,25 @@ EXPORT_SYMBOL_GPL(rpc_sockaddr2uaddr);
* @sap: buffer into which to plant socket address
* @salen: size of buffer
*
+ * @uaddr does not have to be '\0'-terminated, but strict_strtoul() and
+ * rpc_pton() require proper string termination to be successful.
+ *
* Returns the size of the socket address if successful; otherwise
* zero is returned.
*/
size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
struct sockaddr *sap, const size_t salen)
{
- char *c, buf[RPCBIND_MAXUADDRLEN];
+ char *c, buf[RPCBIND_MAXUADDRLEN + sizeof('\0')];
unsigned long portlo, porthi;
unsigned short port;
- if (uaddr_len > sizeof(buf))
+ if (uaddr_len > RPCBIND_MAXUADDRLEN)
return 0;
memcpy(buf, uaddr, uaddr_len);
- buf[uaddr_len] = '\n';
- buf[uaddr_len + 1] = '\0';
-
+ buf[uaddr_len] = '\0';
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
@@ -332,9 +333,7 @@ size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
if (unlikely(portlo > 255))
return 0;
- c[0] = '\n';
- c[1] = '\0';
-
+ *c = '\0';
c = strrchr(buf, '.');
if (unlikely(c == NULL))
return 0;
@@ -345,8 +344,7 @@ size_t rpc_uaddr2sockaddr(const char *uaddr, const size_t uaddr_len,
port = (unsigned short)((porthi << 8) | portlo);
- c[0] = '\0';
-
+ *c = '\0';
if (rpc_pton(buf, strlen(buf), sap, salen) == 0)
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: net 01/02: allow to propagate errors through ->ndo_hard_start_xmit()
From: Patrick McHardy @ 2009-11-11 18:25 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
In-Reply-To: <4AF99156.9050301@trash.net>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
Patrick McHardy wrote:
> The following two patches add support for error propagation
> through ->ndo_hard_start_xmit() and use it to propagate qdisc
> submission state through VLAN and macvlan devices.
>
> I'm also experimenting with returning errno codes from
> tunnel devices to the originating socket, but those patches
> still need some work.
>
> The only change relative to the patch posted yesterday is
> removal of an unnecessary initialization in dev_hard_start_xmit().
Attached is a new version with a more detailed changelog entry,
as requested by Jarek.
[-- Attachment #2: 01.diff --]
[-- Type: text/x-patch, Size: 6447 bytes --]
commit 9c0290f7b05fdb5c3ef4a98d16b7acc8f0ffc119
Author: Patrick McHardy <kaber@trash.net>
Date: Wed Nov 11 19:29:59 2009 +0100
net: allow to propagate errors through ->ndo_hard_start_xmit()
Currently the ->ndo_hard_start_xmit() callbacks are only permitted to return
one of the NETDEV_TX codes. This prevents any kind of error propagation for
virtual devices, like queue congestion of the underlying device in case of
layered devices, or unreachability in case of tunnels.
This patch changes the NET_XMIT codes to avoid clashes with the NETDEV_TX
codes and changes the two callers of dev_hard_start_xmit() to expect either
errno codes, NET_XMIT codes or NETDEV_TX codes as return value.
Drivers are expected to free the packet when returning an errno or NET_XMIT
error code. When this happens while transmitting GSO segments,
dev_hard_start_xmit() frees the remaining segments.
In case of qdisc_restart(), all non NETDEV_TX codes are mapped to NETDEV_TX_OK
since no error propagation is possible when using qdiscs. In case of
dev_queue_xmit(), the error is propagated upwards.
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 465add6..ab2812c 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -63,27 +63,48 @@ struct wireless_dev;
#define HAVE_FREE_NETDEV /* free_netdev() */
#define HAVE_NETDEV_PRIV /* netdev_priv() */
-#define NET_XMIT_SUCCESS 0
-#define NET_XMIT_DROP 1 /* skb dropped */
-#define NET_XMIT_CN 2 /* congestion notification */
-#define NET_XMIT_POLICED 3 /* skb is shot by police */
-#define NET_XMIT_MASK 0xFFFF /* qdisc flags in net/sch_generic.h */
+/*
+ * Transmit return codes: transmit return codes originate from three different
+ * namespaces:
+ *
+ * - qdisc return codes
+ * - driver transmit return codes
+ * - errno values
+ *
+ * Drivers are allowed to return any one of those in their hard_start_xmit()
+ * function. Real network devices commonly used with qdiscs should only return
+ * the driver transmit return codes though - when qdiscs are used, the actual
+ * transmission happens asynchronously, so the value is not propagated to
+ * higher layers. Virtual network devices transmit synchronously, in this case
+ * the driver transmit return codes are consumed by dev_queue_xmit(), all
+ * others are propagated to higher layers.
+ */
+
+/* qdisc ->enqueue() return codes. */
+#define NET_XMIT_SUCCESS 0x00
+#define NET_XMIT_DROP 0x10 /* skb dropped */
+#define NET_XMIT_CN 0x20 /* congestion notification */
+#define NET_XMIT_POLICED 0x30 /* skb is shot by police */
+#define NET_XMIT_MASK 0xf0 /* qdisc flags in net/sch_generic.h */
/* Backlog congestion levels */
-#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
-#define NET_RX_DROP 1 /* packet dropped */
+#define NET_RX_SUCCESS 0 /* keep 'em coming, baby */
+#define NET_RX_DROP 1 /* packet dropped */
/* NET_XMIT_CN is special. It does not guarantee that this packet is lost. It
* indicates that the device will soon be dropping packets, or already drops
* some packets of the same priority; prompting us to send less aggressively. */
-#define net_xmit_eval(e) ((e) == NET_XMIT_CN? 0 : (e))
+#define net_xmit_eval(e) ((e) == NET_XMIT_CN ? 0 : (e))
#define net_xmit_errno(e) ((e) != NET_XMIT_CN ? -ENOBUFS : 0)
/* Driver transmit return codes */
+#define NETDEV_TX_MASK 0xf
+
enum netdev_tx {
- NETDEV_TX_OK = 0, /* driver took care of packet */
- NETDEV_TX_BUSY, /* driver tx path was busy*/
- NETDEV_TX_LOCKED = -1, /* driver tx lock was already taken */
+ __NETDEV_TX_MIN = INT_MIN, /* make sure enum is signed */
+ NETDEV_TX_OK = 0, /* driver took care of packet */
+ NETDEV_TX_BUSY = 1, /* driver tx path was busy*/
+ NETDEV_TX_LOCKED = 2, /* driver tx lock was already taken */
};
typedef enum netdev_tx netdev_tx_t;
diff --git a/net/core/dev.c b/net/core/dev.c
index bf629ac..babd45f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1756,7 +1756,7 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
struct netdev_queue *txq)
{
const struct net_device_ops *ops = dev->netdev_ops;
- int rc;
+ int rc = NETDEV_TX_OK;
if (likely(!skb->next)) {
if (!list_empty(&ptype_all))
@@ -1804,6 +1804,8 @@ gso:
nskb->next = NULL;
rc = ops->ndo_start_xmit(nskb, dev);
if (unlikely(rc != NETDEV_TX_OK)) {
+ if (rc & ~NETDEV_TX_MASK)
+ goto out_kfree_gso_skb;
nskb->next = skb->next;
skb->next = nskb;
return rc;
@@ -1813,11 +1815,12 @@ gso:
return NETDEV_TX_BUSY;
} while (skb->next);
- skb->destructor = DEV_GSO_CB(skb)->destructor;
-
+out_kfree_gso_skb:
+ if (likely(skb->next == NULL))
+ skb->destructor = DEV_GSO_CB(skb)->destructor;
out_kfree_skb:
kfree_skb(skb);
- return NETDEV_TX_OK;
+ return rc;
}
static u32 skb_tx_hashrnd;
@@ -1905,6 +1908,23 @@ static inline int __dev_xmit_skb(struct sk_buff *skb, struct Qdisc *q,
return rc;
}
+static inline bool dev_xmit_complete(int rc)
+{
+ /* successful transmission */
+ if (rc == NETDEV_TX_OK)
+ return true;
+
+ /* error while transmitting, driver consumed skb */
+ if (rc < 0)
+ return true;
+
+ /* error while queueing to a different device, driver consumed skb */
+ if (rc & NET_XMIT_MASK)
+ return true;
+
+ return false;
+}
+
/**
* dev_queue_xmit - transmit a buffer
* @skb: buffer to transmit
@@ -2002,8 +2022,8 @@ gso:
HARD_TX_LOCK(dev, txq, cpu);
if (!netif_tx_queue_stopped(txq)) {
- rc = NET_XMIT_SUCCESS;
- if (!dev_hard_start_xmit(skb, dev, txq)) {
+ rc = dev_hard_start_xmit(skb, dev, txq);
+ if (dev_xmit_complete(rc)) {
HARD_TX_UNLOCK(dev, txq);
goto out;
}
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 4ae6aa5..b13821a 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -120,8 +120,15 @@ int sch_direct_xmit(struct sk_buff *skb, struct Qdisc *q,
HARD_TX_LOCK(dev, txq, smp_processor_id());
if (!netif_tx_queue_stopped(txq) &&
- !netif_tx_queue_frozen(txq))
+ !netif_tx_queue_frozen(txq)) {
ret = dev_hard_start_xmit(skb, dev, txq);
+
+ /* an error implies that the skb was consumed */
+ if (ret < 0)
+ ret = NETDEV_TX_OK;
+ /* all NET_XMIT codes map to NETDEV_TX_OK */
+ ret &= ~NET_XMIT_MASK;
+ }
HARD_TX_UNLOCK(dev, txq);
spin_lock(root_lock);
^ permalink raw reply related
* Re: [PATCH] RDMA/addr: Use appropriate locking with for_each_netdev()
From: Roland Dreier @ 2009-11-11 18:25 UTC (permalink / raw)
To: Sean Hefty
Cc: 'Eric Dumazet', David S. Miller, Linux Netdev List,
Roland Dreier, Hal Rosenstock, linux-rdma
In-Reply-To: <D5E1FB213939498DBFFEB5A3B83C08AD-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
> >for_each_netdev() should be used with RTNL or dev_base_lock held,
> >or risk a crash.
> >
> >Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Thanks - I'm working on a patch set in this area. Roland, I can merge Eric's
> changes into that patch set if it makes things easier.
Would it be possible for you to take Eric's patch as the first in your
set (keeping his From: of course) and base your fixes on top of that?
That seems the cleanest thing to me.
Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Ben Hutchings @ 2009-11-11 18:33 UTC (permalink / raw)
To: Raimonds Cicans; +Cc: romieu, netdev
In-Reply-To: <4AFB0061.7020908@apollo.lv>
On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
>
> 1) exact number depends on some factors:
> - VLAN tagged or not
> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
> applied or not
[...]
MTU is a limit on transmission; it is not required to limit received
frames.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Your email ID has been awarded 1,000,000,00 GBP in our BT promo !!!
From: Tobacco Alart @ 2009-11-11 18:35 UTC (permalink / raw)
Your Email ID has been awarded 1,000,000,00 GBP in British Promo
1.Full Name:
2.Full Address:
3.Status:
4.Occupation:
5.Phone Number:
6.Country:
^ permalink raw reply
* [PATCH] [next-next-2.6] net: configurable device name hash
From: Octavian Purdila @ 2009-11-11 19:16 UTC (permalink / raw)
To: netdev
Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 0addd45..8a129d5 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -29,8 +29,7 @@ struct net_generic;
struct sock;
-#define NETDEV_HASHBITS 8
-#define NETDEV_HASHENTRIES (1 << NETDEV_HASHBITS)
+#define NETDEV_HASHENTRIES (1 << CONFIG_NETDEV_HASHBITS)
struct net {
atomic_t count; /* To decided when the network
diff --git a/net/Kconfig b/net/Kconfig
index 041c35e..f5db7b2 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -45,6 +45,13 @@ config COMPAT_NETLINK_MESSAGES
menu "Networking options"
+config NETDEV_HASHBITS
+ int "Network device hash size"
+ range 8 20
+ default 8
+ help
+ Select network device hash size as a power of 2.
+
source "net/packet/Kconfig"
source "net/unix/Kconfig"
source "net/xfrm/Kconfig"
^ permalink raw reply related
* Re: pull request: wireless-2.6 2009-11-11
From: David Miller @ 2009-11-11 19:20 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20091111172255.GH4392@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 11 Nov 2009 12:22:55 -0500
> Here is another batch of small fixes intended for 2.6.32. Along with a
> number of simple fixes, there is also a MAINTAINERS update, some LED
> handling quirks for ath5k, a libertas beautification that is a prereq
> for a libertas fix, and an iwlwifi fix that was already sent for
> net-next-2.6 but which is needed to support an iwlwifi regression fix.
>
> My personal favorite is the ath5k mcast filtering fix. The problem
> only revealed itself when using IP autoconf w/ multicast DNS... :-)
>
> Please let me know if there are problems!
Pulled, but that libertas "coding style cleanup" really pushes
the edge of what I'm willing to take into net-2.6 right now.
And I don't want to hear anything about how it "makes the bug fix
change simpler". That absolutely doesn't apply when we're this deep
in -rc territory.
> P.S. Due to the aformentioned iwlwifi fix, this will cause -next
> conflicts for sfr. You may want to pull net-2.6 into net-next-2.6 after
> pulling this. The iwlwifi conflicts can be resolved by taking the bigger
> hunks...
Yep, I noticed this, I'll sort it out, thanks.
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: David Miller @ 2009-11-11 19:21 UTC (permalink / raw)
To: opurdila; +Cc: netdev
In-Reply-To: <200911112116.14103.opurdila@ixiacom.com>
From: Octavian Purdila <opurdila@ixiacom.com>
Date: Wed, 11 Nov 2009 21:16:14 +0200
> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
We're not doing this sorry.
Dynamically size it at boot time or something, but a config
option is out of the question.
^ permalink raw reply
* Re: [PATCH] add HAVE_UNREGISTER_NETDEV_QUEUE define for out-of-tree modules
From: David Miller @ 2009-11-11 19:24 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20091110220004.GT21704@kvack.org>
From: Benjamin LaHaise <bcrl@lhnet.ca>
Date: Tue, 10 Nov 2009 17:00:04 -0500
> I have an out of tree network driver (GPL'd) that would like to make use of
> the unregister_netdevice_queue interface for bulk unregister of devices.
> Add a #define HAVE_UNREGISTER_NETDEV_QUEUE to allow the source to detect
> that the kernel supports this.
Please get your code upstream :-)
We're already overcluttered with these "HAVE_PANTS", "HAVE_JACKET",
"HAVE_KITCHEN", "HAVE_SINK" ugly defines spewed all over netdevice.h,
and I'm not adding any more of that.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-11-11
From: David Miller @ 2009-11-11 19:41 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20091111.112031.184370997.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Wed, 11 Nov 2009 11:20:31 -0800 (PST)
> From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Date: Wed, 11 Nov 2009 12:22:55 -0500
>
>> P.S. Due to the aformentioned iwlwifi fix, this will cause -next
>> conflicts for sfr. You may want to pull net-2.6 into net-next-2.6 after
>> pulling this. The iwlwifi conflicts can be resolved by taking the bigger
>> hunks...
>
> Yep, I noticed this, I'll sort it out, thanks.
I just pushed out the merge to net-next-2.6, please double
check my work.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Octavian Purdila @ 2009-11-11 19:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091111.112120.134023270.davem@davemloft.net>
On Wednesday 11 November 2009 21:21:20 you wrote:
> From: Octavian Purdila <opurdila@ixiacom.com>
> Date: Wed, 11 Nov 2009 21:16:14 +0200
>
> > Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
>
> We're not doing this sorry.
>
> Dynamically size it at boot time or something, but a config
> option is out of the question.
>
I don't think we can dynamically size it at boot time since it depends on the
usage pattern which is impossible to determine at boot time, right?
Would it be acceptable to grow it at runtime, in list_netdevice for instance?
^ permalink raw reply
* Re: [PATCH] add HAVE_UNREGISTER_NETDEV_QUEUE define for out-of-tree modules
From: Benjamin LaHaise @ 2009-11-11 19:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20091111.112457.54237892.davem@davemloft.net>
On Wed, Nov 11, 2009 at 11:24:57AM -0800, David Miller wrote:
> From: Benjamin LaHaise <bcrl@lhnet.ca>
> Date: Tue, 10 Nov 2009 17:00:04 -0500
>
> > I have an out of tree network driver (GPL'd) that would like to make use of
> > the unregister_netdevice_queue interface for bulk unregister of devices.
> > Add a #define HAVE_UNREGISTER_NETDEV_QUEUE to allow the source to detect
> > that the kernel supports this.
>
> Please get your code upstream :-)
It's a completely separate PPP & L2TP / PPPoE from the existing code that
is in tree. Somehow, I don't think people are interested in merging duplicate
functionality regardless of what differences there are in the interfaces.
> We're already overcluttered with these "HAVE_PANTS", "HAVE_JACKET",
> "HAVE_KITCHEN", "HAVE_SINK" ugly defines spewed all over netdevice.h,
> and I'm not adding any more of that.
If there was some other way of detecting that the interface is present,
I'd use it, but there isn't.
-ben
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Raimonds Cicans @ 2009-11-11 20:05 UTC (permalink / raw)
To: Ben Hutchings; +Cc: romieu, netdev
In-Reply-To: <1257964419.2839.58.camel@achroite.uk.solarflarecom.com>
Ben Hutchings:
> On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
>> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
>>
>> 1) exact number depends on some factors:
>> - VLAN tagged or not
>> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
>> applied or not
> [...]
>
> MTU is a limit on transmission; it is not required to limit received
> frames.
???
In r8169 driver MTU is used to calculate receive buffer size.
Receive buffer size is used to configure hardware incoming packet filter.
For jumbo frames:
Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
(vlan header) + 4 (ethernet checksum) = MTU + 22
Bug:
driver for all MTU up to 1536 use receive buffer size 1536
As you can see from formula, this mean all IP packets > 1536 - 22
(for vlan tagged, 1536 - 18 for not tagged) are dropped by hardware
filter.
Example:
host_good> ifconfig eth0 mtu 1536
host_r8169> ifconfig eth0 mtu 1536
host_good> ping host_r8169
Ok
host_good> ping -s 1500 host_r8169
Fail
host_good> ifconfig eth0 mtu 7000
host_r8169> ifconfig eth0 mtu 7000
host_good> ping -s 1500 host_r8169
Ok
Raimonds Cicans
^ permalink raw reply
* Re: [PATCH] [next-next-2.6] net: configurable device name hash
From: Eric Dumazet @ 2009-11-11 20:08 UTC (permalink / raw)
To: Octavian Purdila; +Cc: David Miller, netdev
In-Reply-To: <200911112138.44074.opurdila@ixiacom.com>
Octavian Purdila a écrit :
> On Wednesday 11 November 2009 21:21:20 you wrote:
>> From: Octavian Purdila <opurdila@ixiacom.com>
>> Date: Wed, 11 Nov 2009 21:16:14 +0200
>>
>>> Signed-off-by: Octavian Purdila <opurdila@ixiacom.com>
>> We're not doing this sorry.
>>
>> Dynamically size it at boot time or something, but a config
>> option is out of the question.
>>
>
> I don't think we can dynamically size it at boot time since it depends on the
> usage pattern which is impossible to determine at boot time, right?
>
> Would it be acceptable to grow it at runtime, in list_netdevice for instance?
It will be really hard, now we use RCU lookups...
What workload could reasonably need 1.000.000 hash slots, and 16.000.000 netdevices ?
^ permalink raw reply
* Re: r8169: fix driver drop incoming packets >= 1515 if MTU is set between 1515 and 1536
From: Ben Hutchings @ 2009-11-11 20:15 UTC (permalink / raw)
To: Raimonds Cicans; +Cc: romieu, netdev
In-Reply-To: <4AFB190F.2020009@apollo.lv>
On Wed, 2009-11-11 at 22:05 +0200, Raimonds Cicans wrote:
> Ben Hutchings:
> > On Wed, 2009-11-11 at 20:20 +0200, Raimonds Cicans wrote:
> >> Driver drop incoming packets >= 1515(1) if MTU is set between 1515(1) and 1536.
> >>
> >> 1) exact number depends on some factors:
> >> - VLAN tagged or not
> >> - patch "r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames"
> >> applied or not
> > [...]
> >
> > MTU is a limit on transmission; it is not required to limit received
> > frames.
>
> ???
>
> In r8169 driver MTU is used to calculate receive buffer size.
> Receive buffer size is used to configure hardware incoming packet filter.
>
> For jumbo frames:
> Receive buffer size = Max frame size = MTU + 14 (ethernet header) + 4
> (vlan header) + 4 (ethernet checksum) = MTU + 22
>
> Bug:
> driver for all MTU up to 1536 use receive buffer size 1536
[...]
OK, now I understand. The subject line you used is not grammatical and
I originally thought you considered it a bug that the driver might
accept packets with payload greater than MTU.
To make it clear, perhaps you could change the subject to:
'r8169: Fix receive buffer length when MTU is between 1515 and 1536'
and then explain the current behaviour below that.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-11 20:19 UTC (permalink / raw)
To: Frans Pop; +Cc: linux-kernel, netdev
In-Reply-To: <200910311944.35922.elendil@planet.nl>
not to be impatient or ungrateful, but has anyone had time to look at
this? will I be able to upgrade to 31.6? will 32.0 work?
On Sat, Oct 31, 2009 at 1:44 PM, Frans Pop <elendil@planet.nl> wrote:
> Adding netdev in CC. Original message + attachments follow.
>
> =========
> so ever since arch rolled out 2.6.31.x I've been having problems with
> my network (again) where I've been losing a large amount of packets
> (just testing with mtr somewhere between 30/50%). first I figured it
> was the same problem as I had in 2.6.30.x (and maybe it is?) but that
> appeared to get fixed. when I started bisecting the bug wasn't
> apparent in 2.6.31.0 but I knew for sure it was in .5 (I couldn't
> remember if I had noticed it again in .3)
>
> I'm attaching the bisection log and a 'good' dmesg output.
>
> c9fb3ded7a8a6769f3bcb3ef3d9aed61d3e376a9 is the first bad commit
>
> I'm not going to pretend to understand why this patch is breaking my
> networking but between bisection and testing it appears to be... I've
> never bisected before and I'm definitely not a kernel hacker (I can
> barely read C).
>
> I should also note that the wireshark dump here
> http://bugzilla.kernel.org/show_bug.cgi?id=13835 is related to this.
> and if it's not the same bug then possibly a new one should be opened.
>
> P.S. I'm not subscribed to the list please CC me
>
> Caleb Cushing
> http://xenoterracide.blogspot.com
>
>
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH 2/4] [RFC] Add c/r support for connected INET sockets (v4)
From: Serge E. Hallyn @ 2009-11-11 20:32 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev
In-Reply-To: <1257878856-25520-3-git-send-email-danms@us.ibm.com>
Quoting Dan Smith (danms@us.ibm.com):
> This patch adds basic support for C/R of open INET sockets. I think that
> all the important bits of the TCP and ICSK socket structures is saved,
> but I think there is still some additional IPv6 stuff that needs to be
> handled.
>
> With this patch applied, the following script can be used to demonstrate
> the functionality:
>
> https://lists.linux-foundation.org/pipermail/containers/2009-October/021239.html
>
> It shows that this enables migration of a sendmail process with open
> connections from one machine to another without dropping.
>
> We probably need comments from the netdev people about the quality of
> sanity checking we do on the values in the ckpt_hdr_socket_inet
> structure on restart.
>
> Note that this still doesn't address lingering sockets yet.
>
> Changes in v4:
> - Use the new socket buffer restore functions introduced in the
> previous patch
> - Move listen_sockets list under the restart items in ckpt_ctx
> - Rename RESTART_SOCK_LISTENONLY to RESTART_CONN_RESET
>
> Changes in v3:
> - Prevent restart from allowing a bind on a <1024 port unless the
> user is granted that capability
> - Add some sanity checking in the inet_precheck() function to make sure
> the values read from the checkpoint image are within acceptable ranges
> - Check the result of sock_restore_header_info() and fail if needed
>
> Changes in v2:
> - Restore saddr, rcv_saddr, daddr, sport, and dport from the sockaddr
> structure instead of saving them separately
> - Fix 'sock' naming in sock_cptrst()
> - Don't take the queue lock before skb_queue_tail() since it is
> done for us
> - Allow "listen only" restore behavior if RESTART_SOCK_LISTENONLY
> flag is specified on sys_restart()
> - Pull the implementation of the list of listening sockets back into
> this patch
> - Fix dangling printk
> - Add some comments around the parent/child restore logic
>
> Cc: netdev@vger.kernel.org
> Acked-by: Oren Laadan <orenl@librato.com>
> Signed-off-by: Dan Smith <danms@us.ibm.com>
Acked-by: Serge Hallyn <serue@us.ibm.com>
There are probably still gremlins in there somewhere, but imo it's
past time to get this in the tree so we can be testing it.
-serge
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox