* [PATCH 5/7] x25: remove the BKL
From: Arnd Bergmann @ 2011-03-01 23:13 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Andrew Hendry, linux-x25, netdev, Eric Dumazet
In-Reply-To: <1299021191-17961-1-git-send-email-arnd@arndb.de>
This replaces all instances of lock_kernel in x25
with lock_sock, taking care to release the socket
lock around sleeping functions (sock_alloc_send_skb
and skb_recv_datagram). It is not clear whether
this is a correct solution, but it seem to be what
other protocols do in the same situation.
Includes a fix suggested by Eric Dumazet.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
Cc: linux-x25@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
net/x25/Kconfig | 1 -
net/x25/af_x25.c | 58 ++++++++++++++++------------------------------------
net/x25/x25_out.c | 7 ++++-
3 files changed, 23 insertions(+), 43 deletions(-)
diff --git a/net/x25/Kconfig b/net/x25/Kconfig
index 2196e55..e6759c9 100644
--- a/net/x25/Kconfig
+++ b/net/x25/Kconfig
@@ -5,7 +5,6 @@
config X25
tristate "CCITT X.25 Packet Layer (EXPERIMENTAL)"
depends on EXPERIMENTAL
- depends on BKL # should be fixable
---help---
X.25 is a set of standardized network protocols, similar in scope to
frame relay; the one physical line from your box to the X.25 network
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index ad96ee9..4680b1e 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -40,7 +40,6 @@
#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/sched.h>
-#include <linux/smp_lock.h>
#include <linux/timer.h>
#include <linux/string.h>
#include <linux/net.h>
@@ -432,15 +431,6 @@ void x25_destroy_socket_from_timer(struct sock *sk)
sock_put(sk);
}
-static void x25_destroy_socket(struct sock *sk)
-{
- sock_hold(sk);
- lock_sock(sk);
- __x25_destroy_socket(sk);
- release_sock(sk);
- sock_put(sk);
-}
-
/*
* Handling for system calls applied via the various interfaces to a
* X.25 socket object.
@@ -647,18 +637,19 @@ static int x25_release(struct socket *sock)
struct sock *sk = sock->sk;
struct x25_sock *x25;
- lock_kernel();
if (!sk)
- goto out;
+ return 0;
x25 = x25_sk(sk);
+ sock_hold(sk);
+ lock_sock(sk);
switch (x25->state) {
case X25_STATE_0:
case X25_STATE_2:
x25_disconnect(sk, 0, 0, 0);
- x25_destroy_socket(sk);
+ __x25_destroy_socket(sk);
goto out;
case X25_STATE_1:
@@ -678,7 +669,8 @@ static int x25_release(struct socket *sock)
sock_orphan(sk);
out:
- unlock_kernel();
+ release_sock(sk);
+ sock_put(sk);
return 0;
}
@@ -1085,7 +1077,7 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
size_t size;
int qbit = 0, rc = -EINVAL;
- lock_kernel();
+ lock_sock(sk);
if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_OOB|MSG_EOR|MSG_CMSG_COMPAT))
goto out;
@@ -1148,7 +1140,9 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
size = len + X25_MAX_L2_LEN + X25_EXT_MIN_LEN;
+ release_sock(sk);
skb = sock_alloc_send_skb(sk, size, noblock, &rc);
+ lock_sock(sk);
if (!skb)
goto out;
X25_SKB_CB(skb)->flags = msg->msg_flags;
@@ -1231,26 +1225,10 @@ static int x25_sendmsg(struct kiocb *iocb, struct socket *sock,
len++;
}
- /*
- * lock_sock() is currently only used to serialize this x25_kick()
- * against input-driven x25_kick() calls. It currently only blocks
- * incoming packets for this socket and does not protect against
- * any other socket state changes and is not called from anywhere
- * else. As x25_kick() cannot block and as long as all socket
- * operations are BKL-wrapped, we don't need take to care about
- * purging the backlog queue in x25_release().
- *
- * Using lock_sock() to protect all socket operations entirely
- * (and making the whole x25 stack SMP aware) unfortunately would
- * require major changes to {send,recv}msg and skb allocation methods.
- * -> 2.5 ;)
- */
- lock_sock(sk);
x25_kick(sk);
- release_sock(sk);
rc = len;
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
out_kfree_skb:
kfree_skb(skb);
@@ -1271,7 +1249,7 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
unsigned char *asmptr;
int rc = -ENOTCONN;
- lock_kernel();
+ lock_sock(sk);
/*
* This works for seqpacket too. The receiver has ordered the queue for
* us! We do one quick check first though
@@ -1300,8 +1278,10 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
msg->msg_flags |= MSG_OOB;
} else {
/* Now we can treat all alike */
+ release_sock(sk);
skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
flags & MSG_DONTWAIT, &rc);
+ lock_sock(sk);
if (!skb)
goto out;
@@ -1338,14 +1318,12 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock,
msg->msg_namelen = sizeof(struct sockaddr_x25);
- lock_sock(sk);
x25_check_rbuf(sk);
- release_sock(sk);
rc = copied;
out_free_dgram:
skb_free_datagram(sk, skb);
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1581,18 +1559,18 @@ out_cud_release:
case SIOCX25CALLACCPTAPPRV: {
rc = -EINVAL;
- lock_kernel();
+ lock_sock(sk);
if (sk->sk_state != TCP_CLOSE)
break;
clear_bit(X25_ACCPT_APPRV_FLAG, &x25->flags);
- unlock_kernel();
+ release_sock(sk);
rc = 0;
break;
}
case SIOCX25SENDCALLACCPT: {
rc = -EINVAL;
- lock_kernel();
+ lock_sock(sk);
if (sk->sk_state != TCP_ESTABLISHED)
break;
/* must call accptapprv above */
@@ -1600,7 +1578,7 @@ out_cud_release:
break;
x25_write_internal(sk, X25_CALL_ACCEPTED);
x25->state = X25_STATE_3;
- unlock_kernel();
+ release_sock(sk);
rc = 0;
break;
}
diff --git a/net/x25/x25_out.c b/net/x25/x25_out.c
index d00649f..0144271 100644
--- a/net/x25/x25_out.c
+++ b/net/x25/x25_out.c
@@ -68,8 +68,11 @@ int x25_output(struct sock *sk, struct sk_buff *skb)
frontlen = skb_headroom(skb);
while (skb->len > 0) {
- if ((skbn = sock_alloc_send_skb(sk, frontlen + max_len,
- noblock, &err)) == NULL){
+ release_sock(sk);
+ skbn = sock_alloc_send_skb(sk, frontlen + max_len,
+ noblock, &err);
+ lock_sock(sk);
+ if (!skbn) {
if (err == -EWOULDBLOCK && noblock){
kfree_skb(skb);
return sent;
--
1.7.1
^ permalink raw reply related
* [PATCH 6/7] appletalk: remove the BKL
From: Arnd Bergmann @ 2011-03-01 23:13 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Arnaldo Carvalho de Melo, David Miller, netdev
In-Reply-To: <1299021191-17961-1-git-send-email-arnd@arndb.de>
This changes appletalk to use lock_sock instead of
lock_kernel for serialization. I tried to make sure
that we don't hold the socket lock during sleeping
functions, but I did not try to prove whether the
locks are necessary in the first place.
Compile-tested only.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
drivers/net/appletalk/Kconfig | 1 -
net/appletalk/ddp.c | 40 ++++++++++++++++------------------------
2 files changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/net/appletalk/Kconfig b/drivers/net/appletalk/Kconfig
index 0b376a9..f5a8916 100644
--- a/drivers/net/appletalk/Kconfig
+++ b/drivers/net/appletalk/Kconfig
@@ -3,7 +3,6 @@
#
config ATALK
tristate "Appletalk protocol support"
- depends on BKL # waiting to be removed from net/appletalk/ddp.c
select LLC
---help---
AppleTalk is the protocol that Apple computers can use to communicate
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index c410b93..3d4f4b0 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -54,7 +54,6 @@
#include <linux/capability.h>
#include <linux/module.h>
#include <linux/if_arp.h>
-#include <linux/smp_lock.h>
#include <linux/termios.h> /* For TIOCOUTQ/INQ */
#include <linux/compat.h>
#include <linux/slab.h>
@@ -1052,13 +1051,13 @@ static int atalk_release(struct socket *sock)
{
struct sock *sk = sock->sk;
- lock_kernel();
+ lock_sock(sk);
if (sk) {
sock_orphan(sk);
sock->sk = NULL;
atalk_destroy_socket(sk);
}
- unlock_kernel();
+ release_sock(sk);
return 0;
}
@@ -1143,7 +1142,7 @@ static int atalk_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
if (addr->sat_family != AF_APPLETALK)
return -EAFNOSUPPORT;
- lock_kernel();
+ lock_sock(sk);
if (addr->sat_addr.s_net == htons(ATADDR_ANYNET)) {
struct atalk_addr *ap = atalk_find_primary();
@@ -1179,7 +1178,7 @@ static int atalk_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
sock_reset_flag(sk, SOCK_ZAPPED);
err = 0;
out:
- unlock_kernel();
+ release_sock(sk);
return err;
}
@@ -1215,7 +1214,7 @@ static int atalk_connect(struct socket *sock, struct sockaddr *uaddr,
#endif
}
- lock_kernel();
+ lock_sock(sk);
err = -EBUSY;
if (sock_flag(sk, SOCK_ZAPPED))
if (atalk_autobind(sk) < 0)
@@ -1233,7 +1232,7 @@ static int atalk_connect(struct socket *sock, struct sockaddr *uaddr,
sk->sk_state = TCP_ESTABLISHED;
err = 0;
out:
- unlock_kernel();
+ release_sock(sk);
return err;
}
@@ -1249,7 +1248,7 @@ static int atalk_getname(struct socket *sock, struct sockaddr *uaddr,
struct atalk_sock *at = at_sk(sk);
int err;
- lock_kernel();
+ lock_sock(sk);
err = -ENOBUFS;
if (sock_flag(sk, SOCK_ZAPPED))
if (atalk_autobind(sk) < 0)
@@ -1277,17 +1276,7 @@ static int atalk_getname(struct socket *sock, struct sockaddr *uaddr,
memcpy(uaddr, &sat, sizeof(sat));
out:
- unlock_kernel();
- return err;
-}
-
-static unsigned int atalk_poll(struct file *file, struct socket *sock,
- poll_table *wait)
-{
- int err;
- lock_kernel();
- err = datagram_poll(file, sock, wait);
- unlock_kernel();
+ release_sock(sk);
return err;
}
@@ -1596,7 +1585,7 @@ static int atalk_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr
if (len > DDP_MAXSZ)
return -EMSGSIZE;
- lock_kernel();
+ lock_sock(sk);
if (usat) {
err = -EBUSY;
if (sock_flag(sk, SOCK_ZAPPED))
@@ -1651,7 +1640,9 @@ static int atalk_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr
sk, size, dev->name);
size += dev->hard_header_len;
+ release_sock(sk);
skb = sock_alloc_send_skb(sk, size, (flags & MSG_DONTWAIT), &err);
+ lock_sock(sk);
if (!skb)
goto out;
@@ -1738,7 +1729,7 @@ static int atalk_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr
SOCK_DEBUG(sk, "SK %p: Done write (%Zd).\n", sk, len);
out:
- unlock_kernel();
+ release_sock(sk);
return err ? : len;
}
@@ -1753,9 +1744,10 @@ static int atalk_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr
int err = 0;
struct sk_buff *skb;
- lock_kernel();
skb = skb_recv_datagram(sk, flags & ~MSG_DONTWAIT,
flags & MSG_DONTWAIT, &err);
+ lock_sock(sk);
+
if (!skb)
goto out;
@@ -1787,7 +1779,7 @@ static int atalk_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr
skb_free_datagram(sk, skb); /* Free the datagram. */
out:
- unlock_kernel();
+ release_sock(sk);
return err ? : copied;
}
@@ -1887,7 +1879,7 @@ static const struct proto_ops atalk_dgram_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = atalk_getname,
- .poll = atalk_poll,
+ .poll = datagram_poll,
.ioctl = atalk_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = atalk_compat_ioctl,
--
1.7.1
^ permalink raw reply related
* [PATCH 7/7] ipx: remove the BKL
From: Arnd Bergmann @ 2011-03-01 23:13 UTC (permalink / raw)
To: linux-kernel; +Cc: Arnd Bergmann, Arnaldo Carvalho de Melo, netdev
In-Reply-To: <1299021191-17961-1-git-send-email-arnd@arndb.de>
This replaces all instances of lock_kernel in the
IPX code with lock_sock. As far as I can tell, this
is safe to do, because there is no global state
that needs to be locked in IPX, and the code does
not recursively take the lock or sleep indefinitely
while holding it.
Compile-tested only.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: netdev@vger.kernel.org
---
net/ipx/Kconfig | 1 -
net/ipx/af_ipx.c | 52 ++++++++++++++++++++--------------------------------
2 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/net/ipx/Kconfig b/net/ipx/Kconfig
index 02549cb..e9ad006 100644
--- a/net/ipx/Kconfig
+++ b/net/ipx/Kconfig
@@ -3,7 +3,6 @@
#
config IPX
tristate "The IPX protocol"
- depends on BKL # should be fixable
select LLC
---help---
This is support for the Novell networking protocol, IPX, commonly
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index da3d21c..2731b51 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -42,7 +42,6 @@
#include <linux/uio.h>
#include <linux/slab.h>
#include <linux/skbuff.h>
-#include <linux/smp_lock.h>
#include <linux/socket.h>
#include <linux/sockios.h>
#include <linux/string.h>
@@ -1299,7 +1298,7 @@ static int ipx_setsockopt(struct socket *sock, int level, int optname,
int opt;
int rc = -EINVAL;
- lock_kernel();
+ lock_sock(sk);
if (optlen != sizeof(int))
goto out;
@@ -1314,7 +1313,7 @@ static int ipx_setsockopt(struct socket *sock, int level, int optname,
ipx_sk(sk)->type = opt;
rc = 0;
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1326,7 +1325,7 @@ static int ipx_getsockopt(struct socket *sock, int level, int optname,
int len;
int rc = -ENOPROTOOPT;
- lock_kernel();
+ lock_sock(sk);
if (!(level == SOL_IPX && optname == IPX_TYPE))
goto out;
@@ -1347,7 +1346,7 @@ static int ipx_getsockopt(struct socket *sock, int level, int optname,
rc = 0;
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1396,7 +1395,7 @@ static int ipx_release(struct socket *sock)
if (!sk)
goto out;
- lock_kernel();
+ lock_sock(sk);
if (!sock_flag(sk, SOCK_DEAD))
sk->sk_state_change(sk);
@@ -1404,7 +1403,7 @@ static int ipx_release(struct socket *sock)
sock->sk = NULL;
sk_refcnt_debug_release(sk);
ipx_destroy_socket(sk);
- unlock_kernel();
+ release_sock(sk);
out:
return 0;
}
@@ -1530,11 +1529,12 @@ out:
static int ipx_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
{
+ struct sock *sk = sock->sk;
int rc;
- lock_kernel();
+ lock_sock(sk);
rc = __ipx_bind(sock, uaddr, addr_len);
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1551,7 +1551,7 @@ static int ipx_connect(struct socket *sock, struct sockaddr *uaddr,
sk->sk_state = TCP_CLOSE;
sock->state = SS_UNCONNECTED;
- lock_kernel();
+ lock_sock(sk);
if (addr_len != sizeof(*addr))
goto out;
addr = (struct sockaddr_ipx *)uaddr;
@@ -1598,7 +1598,7 @@ static int ipx_connect(struct socket *sock, struct sockaddr *uaddr,
ipxrtr_put(rt);
rc = 0;
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1614,7 +1614,7 @@ static int ipx_getname(struct socket *sock, struct sockaddr *uaddr,
*uaddr_len = sizeof(struct sockaddr_ipx);
- lock_kernel();
+ lock_sock(sk);
if (peer) {
rc = -ENOTCONN;
if (sk->sk_state != TCP_ESTABLISHED)
@@ -1649,19 +1649,7 @@ static int ipx_getname(struct socket *sock, struct sockaddr *uaddr,
rc = 0;
out:
- unlock_kernel();
- return rc;
-}
-
-static unsigned int ipx_datagram_poll(struct file *file, struct socket *sock,
- poll_table *wait)
-{
- int rc;
-
- lock_kernel();
- rc = datagram_poll(file, sock, wait);
- unlock_kernel();
-
+ release_sock(sk);
return rc;
}
@@ -1736,7 +1724,7 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
int rc = -EINVAL;
int flags = msg->msg_flags;
- lock_kernel();
+ lock_sock(sk);
/* Socket gets bound below anyway */
/* if (sk->sk_zapped)
return -EIO; */ /* Socket not bound */
@@ -1788,7 +1776,7 @@ static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock,
if (rc >= 0)
rc = len;
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1803,7 +1791,7 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
struct sk_buff *skb;
int copied, rc;
- lock_kernel();
+ lock_sock(sk);
/* put the autobinding in */
if (!ipxs->port) {
struct sockaddr_ipx uaddr;
@@ -1862,7 +1850,7 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock,
out_free:
skb_free_datagram(sk, skb);
out:
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1874,7 +1862,7 @@ static int ipx_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
struct sock *sk = sock->sk;
void __user *argp = (void __user *)arg;
- lock_kernel();
+ lock_sock(sk);
switch (cmd) {
case TIOCOUTQ:
amount = sk->sk_sndbuf - sk_wmem_alloc_get(sk);
@@ -1937,7 +1925,7 @@ static int ipx_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
rc = -ENOIOCTLCMD;
break;
}
- unlock_kernel();
+ release_sock(sk);
return rc;
}
@@ -1984,7 +1972,7 @@ static const struct proto_ops ipx_dgram_ops = {
.socketpair = sock_no_socketpair,
.accept = sock_no_accept,
.getname = ipx_getname,
- .poll = ipx_datagram_poll,
+ .poll = datagram_poll,
.ioctl = ipx_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = ipx_compat_ioctl,
--
1.7.1
^ permalink raw reply related
* [PATCH 0/7] Final BKL removal, take 2
From: Arnd Bergmann @ 2011-03-01 23:13 UTC (permalink / raw)
To: linux-kernel
Cc: Arnd Bergmann, Andi Kleen, Andrew Hendry,
Arnaldo Carvalho de Melo, David Miller, Eric Dumazet,
Evgeniy Dushistov, Greg Kroah-Hartman, linux-fsdevel, linux-x25,
Mauro Carvalho Chehab, Max Vozeler, Mikulas Patocka, netdev,
Nick Bowler, Nick Piggin, Palash Bandyopadhyay,
Takahiro Hirofuchi
This is the set of patches that remain from
my previous submission one month ago. I've
dropped the ones that have either gone into
linux-next or got a sufficient number of
Acked-by:s so I put them into my own tree.
I've updated the usbip, hpfs, ufs and appletalk
patches according to the feedback I got.
If possible, I'd like the three networking patches
to go through the net-next tree, and the two
staging patches through the staging tree. I'll
add the other ones to my own series if I hear
no objections.
Arnd
Arnd Bergmann (7):
staging/usbip: convert to kthread
staging/cx25721: serialize access to devlist
hpfs: remove the BKL
ufs: remove the BKL
x25: remove the BKL
appletalk: remove the BKL
ipx: remove the BKL
drivers/net/appletalk/Kconfig | 1 -
drivers/staging/cx25821/Kconfig | 1 -
drivers/staging/cx25821/cx25821-alsa.c | 2 +
drivers/staging/cx25821/cx25821-core.c | 16 ++---
drivers/staging/cx25821/cx25821-video.c | 9 +--
drivers/staging/cx25821/cx25821.h | 3 +-
drivers/staging/usbip/Kconfig | 2 +-
drivers/staging/usbip/stub.h | 4 +-
drivers/staging/usbip/stub_dev.c | 12 ++--
drivers/staging/usbip/stub_rx.c | 13 ++---
drivers/staging/usbip/stub_tx.c | 17 +++---
drivers/staging/usbip/usbip_common.c | 105 -------------------------------
drivers/staging/usbip/usbip_common.h | 20 +-----
drivers/staging/usbip/usbip_event.c | 38 ++++-------
drivers/staging/usbip/vhci.h | 4 +-
drivers/staging/usbip/vhci_hcd.c | 10 ++-
drivers/staging/usbip/vhci_rx.c | 16 ++---
drivers/staging/usbip/vhci_sysfs.c | 9 +--
drivers/staging/usbip/vhci_tx.c | 17 +++---
fs/hpfs/Kconfig | 2 +-
fs/hpfs/dir.c | 23 +++----
fs/hpfs/file.c | 9 +--
fs/hpfs/hpfs_fn.h | 22 +++++++
fs/hpfs/inode.c | 9 +--
fs/hpfs/namei.c | 49 +++++++-------
fs/hpfs/super.c | 23 +++----
fs/ufs/Kconfig | 1 -
fs/ufs/inode.c | 78 ++++++-----------------
fs/ufs/namei.c | 35 +++++-----
fs/ufs/super.c | 64 +++++++++++--------
fs/ufs/truncate.c | 5 +-
fs/ufs/ufs.h | 6 ++-
fs/ufs/util.c | 2 +-
net/appletalk/ddp.c | 40 +++++-------
net/ipx/Kconfig | 1 -
net/ipx/af_ipx.c | 52 ++++++---------
net/x25/Kconfig | 1 -
net/x25/af_x25.c | 58 +++++------------
net/x25/x25_out.c | 7 ++-
39 files changed, 296 insertions(+), 490 deletions(-)
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Andrew Hendry <andrew.hendry@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Evgeniy Dushistov <dushistov@mail.ru>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-x25@vger.kernel.org
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Max Vozeler <max@vozeler.com>
Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>
Cc: netdev@vger.kernel.org
Cc: Nick Bowler <nbowler@elliptictech.com>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Palash Bandyopadhyay <palash.bandyopadhyay@conexant.com>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
^ permalink raw reply
* Re: [PATCH 6/7] appletalk: remove the BKL
From: David Miller @ 2011-03-01 23:15 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1299021191-17961-7-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 2 Mar 2011 00:13:10 +0100
> This changes appletalk to use lock_sock instead of
> lock_kernel for serialization. I tried to make sure
> that we don't hold the socket lock during sleeping
> functions, but I did not try to prove whether the
> locks are necessary in the first place.
>
> Compile-tested only.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 5/7] x25: remove the BKL
From: David Miller @ 2011-03-01 23:16 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, andrew.hendry, linux-x25, netdev, eric.dumazet
In-Reply-To: <1299021191-17961-6-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 2 Mar 2011 00:13:09 +0100
> This replaces all instances of lock_kernel in x25
> with lock_sock, taking care to release the socket
> lock around sleeping functions (sock_alloc_send_skb
> and skb_recv_datagram). It is not clear whether
> this is a correct solution, but it seem to be what
> other protocols do in the same situation.
>
> Includes a fix suggested by Eric Dumazet.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 7/7] ipx: remove the BKL
From: David Miller @ 2011-03-01 23:15 UTC (permalink / raw)
To: arnd; +Cc: linux-kernel, acme, netdev
In-Reply-To: <1299021191-17961-8-git-send-email-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 2 Mar 2011 00:13:11 +0100
> This replaces all instances of lock_kernel in the
> IPX code with lock_sock. As far as I can tell, this
> is safe to do, because there is no global state
> that needs to be locked in IPX, and the code does
> not recursively take the lock or sleep indefinitely
> while holding it.
>
> Compile-tested only.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy and source mac selection mode
From: Stephen Hemminger @ 2011-03-01 23:29 UTC (permalink / raw)
To: Oleg V. Ukhno; +Cc: netdev, Jay Vosburgh, David S. Miller
In-Reply-To: <20110301223458.GA24403@yandex-team.ru>
On Wed, 2 Mar 2011 01:34:58 +0300
"Oleg V. Ukhno" <olegu@yandex-team.ru> wrote:
> Patch introduces two new (related) features to bonding module.
> First feature is round-robin hashing policy, which is primarily
> intended for use with 802.3ad mode, and puts every next IPv4 and
> IPv6 packet into next availables slave without taling into account
> which layer3 and above protocol is used.
> Second feature makes possible choosing which MAC-address will be set
> in the transmitted packet - when set to src-mac it will force setting
> slave's interface real MAC address as source MAC address in every
> packet, sent via this slave interface.
> Main goal of this patch is to make possible single TCP stream
> equally striped for both transmitted and received packets over all
> available slaves.
> This operating mode is not fully 802.3ad compliant, and will cause
> some packet reordering in TCP stream, to some kernel tuning may be
> required.
> For correct working enabling round-robin hashing policy plus using
> real slave's MAC addresses as source MAC addresses in transmitted
> packets requires specific switch setting)hashing mode for port-channel
> ("etherchannel) should be set to src-mac or src-dst-mac to get
> correct load-striping on the receiving host's etherchannel.
> General requirements for using bonding in this operating mode are:
> - even and preferrably equal number of slaves on sending and receiving
> hosts;
> - equal RTT between sending and receiving hosts on all slaves;
> - switch capable of doing etherchannels and using src-mac or src-dst-mac
> hashing policy for egress load striping
>
> Signed-off-by: Oleg V. Ukhno <olegu@yandex-team.ru>
It seems to me the whole bonding policy is getting so complex
that the code is a mess. Perhaps it should be somehow linked into
existing packet classification or firewall mechanisms. This would
increase the flexibility and reduce the amount of policy code
in the bonding driver itself.
--
^ permalink raw reply
* Re: skb->frag_list != NULL in start_xmit for device without NETIF_F_FRAGLIST
From: Jesse Gross @ 2011-03-01 23:41 UTC (permalink / raw)
To: Ian Campbell; +Cc: netdev, Paul Durrant
In-Reply-To: <1298980019.5034.2238.camel@zakaz.uk.xensource.com>
On Tue, Mar 1, 2011 at 3:46 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> Hi,
>
> We are seeing cases where Xen netback's start_xmit is being passed an
> skb which has a ->frag_list, despite the driver not advertising the
> NETIF_F_FRAGLIST feature.
>
> Is this indicative of a problem somewhere? Are drivers expected to
> handle a frag_list? grepping for frag_list in drivers/net it appears not
> many drivers do anything with the frag_list.
It certainly sounds like a problem to me. Off the top of my head I
don't know of any drivers that actually set and handle
NETIF_F_FRAGLIST (except for pseudo-devices like bridging).
>
> The netback driver is bridged with a tg3 physical device and we think
> the problematic skb's are originating on the wire.
>
> The case we are actually seeing is with 2.6.32 + tg3 3.110g so obviously
> the next step is to reproduce on a more modern kernel and the in-tree
> driver and then to attempt to determine if the fault is in what the
> physical interface's driver is passing up the stack or in the stack's
> handling of those skbs. Any hints on where to look would be much
> appreciated.
I'd guess that the most likely source of frag_lists generated here are
from GRO, in skb_gro_receive(). The driver/NIC can definitely
influence the strategy that GRO uses for reassembly but it seems less
likely that the driver itself will create frag_lists.
>
> In particular I'm not sure where the frag_list is supposed to get
> resolved in the case where dev_hard_start_xmit takes the netif_needs_gso
> == true path and calls dev_gso_segment rather than taking the
> __skb_linearize path (the issue appears to occur only when the netback
> device has NETIF_F_GSO but not NETIF_F_TSO). AFAICT dev_gso_segment goes
> to tcp_tso_segment and then to skb_segment which does appear to create
> skbs with a frag_list (although it's not outside the realms of
> possibility that I'm reading it wrong).
I'm fairly certain that the problem is in skb_segment(). It's not the
most tolerant of skbs with frag_lists that do not line up with the
requested mss. Depending on how the original skb is laid out,
sometimes this will trigger a BUG_ON and sometimes it creates new
frag_lists. Since there are no further checks after GSO, the skb with
a frag_list will get passed to the driver, even if it is not
supported.
I believe that not much has changed in this regard between 2.6.32 and net-next.
> I did wonder if perhaps we should just ignore the field, since something
> higher up the stack walked the list and called start_xmit repeatedly,
> but if that's the case I can't see where...
That will happen for GSO but those packets shouldn't have a frag_list
if the driver doesn't support it.
^ permalink raw reply
* [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: David Miller @ 2011-03-01 23:48 UTC (permalink / raw)
To: herbert; +Cc: netdev
The route lookup code in icmp_send() is slightly tricky as a result of
having to handle all of the requirements of RFC 4301 host relookups.
Pull the route resolution into a seperate function, so that the error
handling and route reference counting is hopefully easier to see and
contained wholly within this new routine.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/icmp.c | 175 ++++++++++++++++++++++++++++++-------------------------
1 files changed, 96 insertions(+), 79 deletions(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index ad2bcf1..527ffd1 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -369,6 +369,98 @@ out_unlock:
icmp_xmit_unlock(sk);
}
+struct rtable *icmp_route_lookup(struct net *net, struct sk_buff *skb_in,
+ struct iphdr *iph,
+ __be32 saddr, u8 tos,
+ int type, int code,
+ struct icmp_bxm *param)
+{
+ struct flowi fl = {
+ .fl4_dst = (param->replyopts.srr ?
+ param->replyopts.faddr : iph->saddr),
+ .fl4_src = saddr,
+ .fl4_tos = RT_TOS(tos),
+ .proto = IPPROTO_ICMP,
+ .fl_icmp_type = type,
+ .fl_icmp_code = code,
+ };
+ struct rtable *rt, *rt2;
+ int err;
+
+ security_skb_classify_flow(skb_in, &fl);
+ err = __ip_route_output_key(net, &rt, &fl);
+ if (err)
+ return ERR_PTR(err);
+
+ /* No need to clone since we're just using its address. */
+ rt2 = rt;
+
+ if (!fl.fl4_src)
+ fl.fl4_src = rt->rt_src;
+
+ err = xfrm_lookup(net, (struct dst_entry **)&rt, &fl, NULL, 0);
+ switch (err) {
+ case 0:
+ if (rt != rt2)
+ return rt;
+ break;
+ case -EPERM:
+ rt = NULL;
+ break;
+ default:
+ return ERR_PTR(err);
+ }
+
+ err = xfrm_decode_session_reverse(skb_in, &fl, AF_INET);
+ if (err)
+ goto relookup_failed;
+
+ if (inet_addr_type(net, fl.fl4_src) == RTN_LOCAL) {
+ err = __ip_route_output_key(net, &rt2, &fl);
+ } else {
+ struct flowi fl2 = {};
+ unsigned long orefdst;
+
+ fl2.fl4_dst = fl.fl4_src;
+ err = ip_route_output_key(net, &rt2, &fl2);
+ if (err)
+ goto relookup_failed;
+ /* Ugh! */
+ orefdst = skb_in->_skb_refdst; /* save old refdst */
+ err = ip_route_input(skb_in, fl.fl4_dst, fl.fl4_src,
+ RT_TOS(tos), rt2->dst.dev);
+
+ dst_release(&rt2->dst);
+ rt2 = skb_rtable(skb_in);
+ skb_in->_skb_refdst = orefdst; /* restore old refdst */
+ }
+
+ if (err)
+ goto relookup_failed;
+
+ err = xfrm_lookup(net, (struct dst_entry **)&rt2, &fl, NULL,
+ XFRM_LOOKUP_ICMP);
+ switch (err) {
+ case 0:
+ dst_release(&rt->dst);
+ rt = rt2;
+ break;
+ case -EPERM:
+ return ERR_PTR(err);
+ default:
+ if (!rt)
+ return ERR_PTR(err);
+ break;
+ }
+
+
+ return rt;
+
+relookup_failed:
+ if (rt)
+ return rt;
+ return ERR_PTR(err);
+}
/*
* Send an ICMP message in response to a situation
@@ -506,86 +598,11 @@ void icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info)
ipc.opt = &icmp_param.replyopts;
ipc.tx_flags = 0;
- {
- struct flowi fl = {
- .fl4_dst = icmp_param.replyopts.srr ?
- icmp_param.replyopts.faddr : iph->saddr,
- .fl4_src = saddr,
- .fl4_tos = RT_TOS(tos),
- .proto = IPPROTO_ICMP,
- .fl_icmp_type = type,
- .fl_icmp_code = code,
- };
- int err;
- struct rtable *rt2;
-
- security_skb_classify_flow(skb_in, &fl);
- if (__ip_route_output_key(net, &rt, &fl))
- goto out_unlock;
-
- /* No need to clone since we're just using its address. */
- rt2 = rt;
-
- if (!fl.nl_u.ip4_u.saddr)
- fl.nl_u.ip4_u.saddr = rt->rt_src;
-
- err = xfrm_lookup(net, (struct dst_entry **)&rt, &fl, NULL, 0);
- switch (err) {
- case 0:
- if (rt != rt2)
- goto route_done;
- break;
- case -EPERM:
- rt = NULL;
- break;
- default:
- goto out_unlock;
- }
-
- if (xfrm_decode_session_reverse(skb_in, &fl, AF_INET))
- goto relookup_failed;
-
- if (inet_addr_type(net, fl.fl4_src) == RTN_LOCAL)
- err = __ip_route_output_key(net, &rt2, &fl);
- else {
- struct flowi fl2 = {};
- unsigned long orefdst;
-
- fl2.fl4_dst = fl.fl4_src;
- if (ip_route_output_key(net, &rt2, &fl2))
- goto relookup_failed;
-
- /* Ugh! */
- orefdst = skb_in->_skb_refdst; /* save old refdst */
- err = ip_route_input(skb_in, fl.fl4_dst, fl.fl4_src,
- RT_TOS(tos), rt2->dst.dev);
-
- dst_release(&rt2->dst);
- rt2 = skb_rtable(skb_in);
- skb_in->_skb_refdst = orefdst; /* restore old refdst */
- }
-
- if (err)
- goto relookup_failed;
-
- err = xfrm_lookup(net, (struct dst_entry **)&rt2, &fl, NULL,
- XFRM_LOOKUP_ICMP);
- switch (err) {
- case 0:
- dst_release(&rt->dst);
- rt = rt2;
- break;
- case -EPERM:
- goto ende;
- default:
-relookup_failed:
- if (!rt)
- goto out_unlock;
- break;
- }
- }
+ rt = icmp_route_lookup(net, skb_in, iph, saddr, tos,
+ type, code, &icmp_param);
+ if (IS_ERR(rt))
+ goto out_unlock;
-route_done:
if (!icmpv4_xrlim_allow(net, rt, type, code))
goto ende;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: David Miller @ 2011-03-01 23:50 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20110301.154816.212683830.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 01 Mar 2011 15:48:16 -0800 (PST)
>
> The route lookup code in icmp_send() is slightly tricky as a result of
> having to handle all of the requirements of RFC 4301 host relookups.
>
> Pull the route resolution into a seperate function, so that the error
> handling and route reference counting is hopefully easier to see and
> contained wholly within this new routine.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
...
> +struct rtable *icmp_route_lookup(struct net *net, struct sk_buff *skb_in,
Of course this should be static :-)
^ permalink raw reply
* Re: [question] fcoe: bonding support
From: Robert Love @ 2011-03-02 0:05 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110228122957.GB4043@psychotron.brq.redhat.com>
On Mon, 2011-02-28 at 04:29 -0800, Jiri Pirko wrote:
> Hi Robert.
>
Hi Jirka,
I think the other community members have probably answered your
questions sufficiently, but since you addressed me directly I figured I
should reply. Let me know if you need any further assistance. I'll also
be happy to pick up your patch when it's done.
//Rob
> I wonder what's the meaning of the following code in fcoe_interface_setup():
>
> /* Do not support for bonding device */
> if ((netdev->priv_flags & IFF_MASTER_ALB) ||
> (netdev->priv_flags & IFF_SLAVE_INACTIVE) ||
> (netdev->priv_flags & IFF_MASTER_8023AD)) {
> FCOE_NETDEV_DBG(netdev, "Bonded interfaces not supported\n");
> return -EOPNOTSUPP;
> }
>
> From this I cannot understand if bonding is not supported at all or
> only alb and 8023ad modes are not supported (leaving aside completely
> bogus checking for IFF_SLAVE_INACTIVE).
>
> How about to check IFF_BONDING only (in case bonding should not be
> supported at all)
>
> Thanks.
>
> Jirka
^ permalink raw reply
* (unknown),
From: Mr. henry @ 2011-03-01 23:48 UTC (permalink / raw)
Van szüksége a hitel bármilyen célra? Van egy pénzügyi probléma? Nem
szükség van a pénzügyi megoldás? Mr. Henrik
hitelek a megoldás toall a pénzügyi problémákat, mi hitelek könnyen,
olcsó, és gyors. Írjon nekünk ma, hogy a kölcsönt, amire vágytok, akkor
intézkedik minden olyan kölcsön, hogy megfeleljen a költségvetés mindössze
3%-os kamat. Ha
érdekli, lépjen velünk kapcsolatba immediately.Optional Hitel A védelem
lehetővé teszi,
hogy megfeleljen a hiteltörlesztés, ha nem tud dolgozni, betegség miatt,
baleset vagy
munkanélküliség. Csak akkor vegye ki az értékes biztosítást, ha alkalmazni
az Ön kölcsönt,
emlékszem, hogy elmondja nekünk, ha azt szeretné, hogy
henmoralendingfirm@gmail.com
* HITEL JELENTKEZÉSI LAP *
* Teljes név ............*
* Otthoni cím ....................... ..*
* Születési dátum ......................*
* Telefonszám ...................*
* MOBIL szám, ha ..............*
* HITEL szükséges mennyiség .................*
* FAX .................*
* Állampolgárság ..................*
* ORSZÁG ........................*
* SZAKMA ....................*
* SEX ..................................*
* FÉRFI .............................*
* FEMAL .........................*
* VÁLÁS HA ......................*
* Legközelebbi hozzátartozó .......................*
* NÉV .......................... ...*
* Születési dátum .....................*
* CÉLJA KÖLCSÖNZÉS .......................... .......*
* A kölcsön időtartamát ........................*
* ID .......................*
* A Üdvözlettel *
* Mr. henry *
^ permalink raw reply
* Re: [Bugme-new] [Bug 30082] New: after lxc-stop: unregister_netdevice: waiting for lo to become free. Usage count: 3
From: Andrew Morton @ 2011-03-02 0:13 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, mjt
In-Reply-To: <bug-30082-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 28 Feb 2011 14:47:03 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=30082
>
> Summary: after lxc-stop: unregister_netdevice: waiting for lo
> to become free. Usage count: 3
> Product: Networking
> Version: 2.5
> Kernel Version: 2.6.36 2.6.37
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Other
> AssignedTo: acme@ghostprotocols.net
> ReportedBy: mjt@tls.msk.ru
> Regression: No
>
>
> As far as I can tell so far this is triggered by lxc version 0.7.4, at least I
> haven't seen this before. I tried 2.6.36[.3] and 2.6.37[.2] kernels so far,
> both behaves similarly.
>
> The problem is, when I shut down a container which uses bridged veth interface
> pair using lxc-stop, the container terminates, but host system starts crying
> about unregister_netdevice like this:
>
> [902885.096462] unregister_netdevice: waiting for lo to become free. Usage
> count = 3
> [902895.229785] unregister_netdevice: waiting for lo to become free. Usage
> count = 3
> [...]
> [904247.123002] unregister_netdevice: waiting for lo to become free. Usage
> count = 3
>
> After some, random, time, this stops - sometimes after just one message,
> sometimes after several minutes. Sometimes it does not happen at all.
>
> This looks like a kernel issue triggerable by lxc-0.7.4.
>
^ permalink raw reply
* RE: e1000 - rx misses
From: John Bermudez @ 2011-03-02 0:14 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: cramerj, Ronciak, John, Kirsher, Jeffrey T, Kok, Auke-jan H,
netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net
In-Reply-To: <alpine.WNT.2.00.1102281058040.5424@JBRANDEB-DESK2.amr.corp.intel.com>
Thanks for your time
Can you tell me the command to lengthen the input fifo rx queue?
is this possible
Thank you and have a nice day,
Mr. John Bermudez
NOC Level 3 Engineer
-----Original Message-----
From: Brandeburg, Jesse [mailto:jesse.brandeburg@intel.com]
Sent: Monday, February 28, 2011 11:05 AM
To: John Bermudez
Cc: cramerj; Ronciak, John; Kirsher, Jeffrey T; Kok, Auke-jan H; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
Subject: Re: e1000 - rx misses
added e1000-devel, responses inline...
On Wed, 23 Feb 2011, John Bermudez wrote:
> Hello All,
> I got your contact info in a forum.
> maybe you could give me a quick pointer.
>
> I have a device that is experiencing RX misses. I tried 1000/full and 100/full
> it occurs at both speeds. I seem to get a burst of loss so I am assuming I am overrunning the FIFO RX queue.
overrunning at 100Mb/s seems pretty unlikely to be our hardware's fault,
as your buffer (in time) is increasing by 10x.
>
> Any known workarounds?
> Configuration modifications?
>
> your time is much appreciated
>
>
>
> /lib/modules/2.4.31-uc0/kernel/drivers/net/e1000
> # ls
> e1000.o
ow, 2.4.31 kernel is pretty much so old as to not be supportable.
> # ethtool -S eth1
> NIC statistics:
> rx_packets: 217454512
> tx_packets: 266698397
> rx_bytes: 172995819593
> tx_bytes: 246744709750
> rx_broadcast: 0
> tx_broadcast: 528
<snip>
> rx_no_buffer_count: 925
This count above indicates that your cpu is not returning buffers to
hardware fast enough. Do you have NAPI enabled?
> rx_missed_errors: 48206
This error means that for the length of time the fifo was buffering the
adapter was not able to get any data buffers from the OS, filled the FIFO
and had to drop this many packets.
> tx_aborted_errors: 0
> tx_carrier_errors: 0
> tx_fifo_errors: 0
> tx_heartbeat_errors: 0
> tx_window_errors: 0
> tx_abort_late_coll: 0
> tx_deferred_ok: 0
> tx_single_coll_ok: 0
> tx_multi_coll_ok: 0
> tx_timeout_count: 0
> tx_restart_queue: 0
> rx_long_length_errors: 0
> rx_short_length_errors: 0
> rx_align_errors: 0
> tx_tcp_seg_good: 0
> tx_tcp_seg_failed: 0
> rx_flow_control_xon: 0
> rx_flow_control_xoff: 0
> tx_flow_control_xon: 0
> tx_flow_control_xoff: 0
flow control is either not happenning or is disabled, if it is disabled
you could try enabling it on both ends to get a little more buffering in
your switch.
> rx_long_byte_count: 172995819593
> rx_csum_offload_good: 217406235
> rx_csum_offload_errors: 17
> rx_header_split: 0
> alloc_rx_buff_failed: 0
> tx_smbus: 0
> rx_smbus: 5262
hm, you have IPMI traffic, could these be related to your stalls?
> dropped_smbus: 0
> #
>
>
> Thank you and have a nice day,
>
> Mr. John Bermudez
> NOC Level 3 Engineer
>
>
You didn't include lots of data we need, like hardware type, adapter/chip,
ethtool -i output, cat /proc/interrupts, system info, .config, etc.
I suggest that something is running either in interrupt context on your
system for a very long time (keeping us from running our interrupt
handler) or that your cpu is underpowered and unable to keep up with
whatever tasks it is running besides the network driver.
If you wish to continue troubleshooting please file a bug at e1000.sf.net
and attach the requested info there.
Jesse
^ permalink raw reply
* Re: [Bugme-new] [Bug 30092] New: smsc911x.c drops long packets with VLAN tags
From: Andrew Morton @ 2011-03-02 0:15 UTC (permalink / raw)
To: netdev; +Cc: bugzilla-daemon, bugme-daemon, weinholt, Steve Glendinning
In-Reply-To: <bug-30092-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Mon, 28 Feb 2011 15:57:14 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=30092
>
> Summary: smsc911x.c drops long packets with VLAN tags
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.36.4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: weinholt@csbnet.se
> Regression: No
>
>
> The smsc911x.c driver can't receive packets of the maximum MTU if they have a
> 802.1q tag. Testing with ping -s 1500 shows that the frame with the first IP
> segment is dropped.
>
> The source of the problem is this line at smsc911x.c:1023 (smsc911x_poll):
>
> if (unlikely(rxstat & RX_STS_ES_)) {
>
> The datasheet at
> http://www.smsc.com/media/Downloads_Public/Data_Sheets/9221.pdf describes this
> bit as a logical OR of bits 11, 7, 6 and 1. The problem is that bit 7 is set if
> the packet is longer than 1518 bytes, which is true for the 802.1q tagged
> packets. As a quick and dirty solution, I replaced RX_STS_ES_ with
> (1<<11|1<<6|1<<1), and now 802.1q tagged packets are received just fine.
>
> This was tested on an IGEPv2, which has a SMSC LAN9221i.
>
Thanks. Become famous, get more girls: send us a patch as per
Documentation/SubmittingPatches :)
^ permalink raw reply
* (unknown),
From: Mr. henry @ 2011-03-01 23:47 UTC (permalink / raw)
Van szüksége a hitel bármilyen célra? Van egy pénzügyi probléma? Nem
szükség van a pénzügyi megoldás? Mr. Henrik
hitelek a megoldás toall a pénzügyi problémákat, mi hitelek könnyen,
olcsó, és gyors. Írjon nekünk ma, hogy a kölcsönt, amire vágytok, akkor
intézkedik minden olyan kölcsön, hogy megfeleljen a költségvetés mindössze
3%-os kamat. Ha
érdekli, lépjen velünk kapcsolatba immediately.Optional Hitel A védelem
lehetővé teszi,
hogy megfeleljen a hiteltörlesztés, ha nem tud dolgozni, betegség miatt,
baleset vagy
munkanélküliség. Csak akkor vegye ki az értékes biztosítást, ha alkalmazni
az Ön kölcsönt,
emlékszem, hogy elmondja nekünk, ha azt szeretné, hogy
henmoralendingfirm@gmail.com
* HITEL JELENTKEZÉSI LAP *
* Teljes név ............*
* Otthoni cím ....................... ..*
* Születési dátum ......................*
* Telefonszám ...................*
* MOBIL szám, ha ..............*
* HITEL szükséges mennyiség .................*
* FAX .................*
* Állampolgárság ..................*
* ORSZÁG ........................*
* SZAKMA ....................*
* SEX ..................................*
* FÉRFI .............................*
* FEMAL .........................*
* VÁLÁS HA ......................*
* Legközelebbi hozzátartozó .......................*
* NÉV .......................... ...*
* Születési dátum .....................*
* CÉLJA KÖLCSÖNZÉS .......................... .......*
* A kölcsön időtartamát ........................*
* ID .......................*
* A Üdvözlettel *
* Mr. henry *
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 0:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <1298997084.3284.119.camel@edumazet-laptop>
On Tue, Mar 01, 2011 at 05:31:24PM +0100, Eric Dumazet wrote:
>
> This wont work for tcp streams, you could imagine a multi-threaded
> application using a shared tcp socket as well. Too many OOO packets.
Think about it, a TCP socket cannot be used by a multi-threaded app
in a scalable way.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ipv4: Make icmp route lookup code a bit clearer.
From: Herbert Xu @ 2011-03-02 0:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110301.155015.258117084.davem@davemloft.net>
On Tue, Mar 01, 2011 at 03:50:15PM -0800, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 01 Mar 2011 15:48:16 -0800 (PST)
>
> >
> > The route lookup code in icmp_send() is slightly tricky as a result of
> > having to handle all of the requirements of RFC 4301 host relookups.
> >
> > Pull the route resolution into a seperate function, so that the error
> > handling and route reference counting is hopefully easier to see and
> > contained wholly within this new routine.
> >
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> ...
> > +struct rtable *icmp_route_lookup(struct net *net, struct sk_buff *skb_in,
>
> Of course this should be static :-)
Looks good to me.
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* RE: e1000 - rx misses
From: Brandeburg, Jesse @ 2011-03-02 1:01 UTC (permalink / raw)
To: John Bermudez
Cc: Ronciak, John, Kirsher, Jeffrey T, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <2DF55ECAAA7FFF478FB4ED007EF478E7656B100F27@NETS.hillside.glowpoint.com>
<removed non-relevant users>
On Tue, 1 Mar 2011, John Bermudez wrote:
> Thanks for your time
> Can you tell me the command to lengthen the input fifo rx queue?
> is this possible
You can try increasing the number of rx buffers via the command
# ethtool -G ethX rx 4096
and if you were really gung ho, you could increase the amount of fifo
allocated to the rx side of the fifo by modifying the source. That said,
I don't think that will buy you anything because it seems from the small
amount of data provided that you are having exceptionally long periods of
time where the data is coming faster than your machine can process (for
whatever reason) and increasing the fifo only will give you a marginal
(4kB or so) increasing in buffering.
>
> -----Original Message-----
> From: Brandeburg, Jesse [mailto:jesse.brandeburg@intel.com]
> Sent: Monday, February 28, 2011 11:05 AM
> To: John Bermudez
> Cc: cramerj; Ronciak, John; Kirsher, Jeffrey T; Kok, Auke-jan H; netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
> Subject: Re: e1000 - rx misses
>
> added e1000-devel, responses inline...
>
> On Wed, 23 Feb 2011, John Bermudez wrote:
>
> > Hello All,
> > I got your contact info in a forum.
> > maybe you could give me a quick pointer.
> >
> > I have a device that is experiencing RX misses. I tried 1000/full and 100/full
> > it occurs at both speeds. I seem to get a burst of loss so I am assuming I am overrunning the FIFO RX queue.
>
> overrunning at 100Mb/s seems pretty unlikely to be our hardware's fault,
> as your buffer (in time) is increasing by 10x.
>
> >
> > Any known workarounds?
> > Configuration modifications?
> >
> > your time is much appreciated
> >
> >
> >
> > /lib/modules/2.4.31-uc0/kernel/drivers/net/e1000
> > # ls
> > e1000.o
>
> ow, 2.4.31 kernel is pretty much so old as to not be supportable.
>
> > # ethtool -S eth1
> > NIC statistics:
> > rx_packets: 217454512
> > tx_packets: 266698397
> > rx_bytes: 172995819593
> > tx_bytes: 246744709750
> > rx_broadcast: 0
> > tx_broadcast: 528
> <snip>
> > rx_no_buffer_count: 925
>
> This count above indicates that your cpu is not returning buffers to
> hardware fast enough. Do you have NAPI enabled?
>
> > rx_missed_errors: 48206
>
> This error means that for the length of time the fifo was buffering the
> adapter was not able to get any data buffers from the OS, filled the FIFO
> and had to drop this many packets.
>
> > tx_aborted_errors: 0
> > tx_carrier_errors: 0
> > tx_fifo_errors: 0
> > tx_heartbeat_errors: 0
> > tx_window_errors: 0
> > tx_abort_late_coll: 0
> > tx_deferred_ok: 0
> > tx_single_coll_ok: 0
> > tx_multi_coll_ok: 0
> > tx_timeout_count: 0
> > tx_restart_queue: 0
> > rx_long_length_errors: 0
> > rx_short_length_errors: 0
> > rx_align_errors: 0
> > tx_tcp_seg_good: 0
> > tx_tcp_seg_failed: 0
> > rx_flow_control_xon: 0
> > rx_flow_control_xoff: 0
> > tx_flow_control_xon: 0
> > tx_flow_control_xoff: 0
>
> flow control is either not happenning or is disabled, if it is disabled
> you could try enabling it on both ends to get a little more buffering in
> your switch.
>
> > rx_long_byte_count: 172995819593
> > rx_csum_offload_good: 217406235
> > rx_csum_offload_errors: 17
> > rx_header_split: 0
> > alloc_rx_buff_failed: 0
> > tx_smbus: 0
> > rx_smbus: 5262
>
> hm, you have IPMI traffic, could these be related to your stalls?
>
> > dropped_smbus: 0
> > #
> >
> >
> > Thank you and have a nice day,
> >
> > Mr. John Bermudez
> > NOC Level 3 Engineer
> >
> >
>
> You didn't include lots of data we need, like hardware type, adapter/chip,
> ethtool -i output, cat /proc/interrupts, system info, .config, etc.
>
> I suggest that something is running either in interrupt context on your
> system for a very long time (keeping us from running our interrupt
> handler) or that your cpu is underpowered and unable to keep up with
> whatever tasks it is running besides the network driver.
>
> If you wish to continue troubleshooting please file a bug at e1000.sf.net
> and attach the requested info there.
>
> Jesse
>
^ permalink raw reply
* Re: [PATCH 1/2 net-next][v2] bonding: fix incorrect transmit queue offset
From: Phil Oester @ 2011-03-02 1:40 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: David Miller, bhutchings, netdev, fubar
In-Reply-To: <20110301153135.GL11864@gospo.rdu.redhat.com>
On Tue, Mar 01, 2011 at 10:31:36AM -0500, Andy Gospodarek wrote:
> > The patch works as expected. Do we have any agreement on a final version?
> >
>
> Thanks for the testing, Phil.
>
> I'm in favor of this patch as it does alert the admin that bonding may
> not have enough default queues, but it is not as verbose (backtrace et
> al) and likely to create bug reports as a message from WARN_ON.
> + if (net_ratelimit())
> + pr_warning("%s selects invalid tx queue %d. Consider"
> + " setting module option tx_queues > %d.",
> + dev->name, txq, dev->real_num_tx_queues);
It is unclear why we need to alert the admin to this situation (repeatedly).
Say the incoming nic has 32 queues, and is headed out a bond (with 16).
With your patch, we will log 50% of the time, no? What benefit is this
log spew?
While WARN_ONCE may be a bit extreme due to the backtrace, perhaps we
should at least throw a 'static bool warned' variable in there to lessen
the nuisance?
Phil
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Eric Dumazet @ 2011-03-02 2:00 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <20110302002353.GA15009@gondor.apana.org.au>
Le mercredi 02 mars 2011 à 08:23 +0800, Herbert Xu a écrit :
> On Tue, Mar 01, 2011 at 05:31:24PM +0100, Eric Dumazet wrote:
> >
> > This wont work for tcp streams, you could imagine a multi-threaded
> > application using a shared tcp socket as well. Too many OOO packets.
>
> Think about it, a TCP socket cannot be used by a multi-threaded app
> in a scalable way.
Well...
If you think about it, SO_REUSEPORT patch has exactly the same goal :
Let each thread use a different socket, to scale without kernel limits.
We cant modify TX selection each time we want to "fix" a problem without
changing user side (not adding an API), and as side effect make non
optimal applications become miserable.
We added RPS and XPS that works correctly if each socket is used by one
thread. Maybe we need to add an user API or automatically detect a
particular DGRAM socket is used by many different threads to :
0) Decide OOM is ok for this workload (many threads issuing send() at
the same time)
1) Setup several receive queues (up to num_possible_cpus())
2) Use an appropriate TX queue selection
^ permalink raw reply
* Re: SO_REUSEPORT - can it be done in kernel?
From: Herbert Xu @ 2011-03-02 2:39 UTC (permalink / raw)
To: Eric Dumazet
Cc: Thomas Graf, David Miller, rick.jones2, therbert, wsommerfeld,
daniel.baluta, netdev
In-Reply-To: <1299031203.2930.26.camel@edumazet-laptop>
On Wed, Mar 02, 2011 at 03:00:03AM +0100, Eric Dumazet wrote:
> >
> > Think about it, a TCP socket cannot be used by a multi-threaded app
> > in a scalable way.
>
> Well...
>
> If you think about it, SO_REUSEPORT patch has exactly the same goal :
UDP is a datagram protocol, TCP is not.
Anyway, here is an alternate proposal. When a TCP socket transmits
for the first time (SYN or SYN-ACK), we pick a queue based on CPU and
store it in the socket. From then on we stick to that selection.
We would only allow changes if we can ensure that all transmitted
packets have left the queue. Or we just never change it like we
do now.
For datagram protocols we simply use the current CPU.
> We added RPS and XPS that works correctly if each socket is used by one
> thread. Maybe we need to add an user API or automatically detect a
> particular DGRAM socket is used by many different threads to :
No we don't need that for datagram protocols at all. By definition
there is no ordering guarantee across CPUs for datagram sockets.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 4/4 V2] net,rcu: don't assume the size of struct rcu_head
From: Lai Jiangshan @ 2011-03-02 2:46 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, mingo, paulmck, cl, penberg, mpm, linux-mm,
linux-kernel, netdev
In-Reply-To: <1298971213.3284.4.camel@edumazet-laptop>
On 03/01/2011 05:20 PM, Eric Dumazet wrote:
> Le mardi 01 mars 2011 à 16:53 +0800, Lai Jiangshan a écrit :
>> On 03/01/2011 04:16 PM, David Miller wrote:
>>> From: Lai Jiangshan <laijs@cn.fujitsu.com>
>>> Date: Tue, 01 Mar 2011 16:03:44 +0800
>>>
>>>>
>>>> struct dst_entry assumes the size of struct rcu_head as 2 * sizeof(long)
>>>> and manually adds pads for aligning for "__refcnt".
>>>>
>>>> When the size of struct rcu_head is changed, these manual padding
>>>> is wrong. Use __attribute__((aligned (64))) instead.
>>>>
>>>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>>>
>>> We don't want to use the align if it's going to waste lots of space.
>>>
>>> Instead we want to rearrange the structure so that the alignment comes
>>> more cheaply.
>>
>> Subject: [PATCH 4/4 V2] net,rcu: don't assume the size of struct rcu_head
>>
>> struct dst_entry assumes the size of struct rcu_head as 2 * sizeof(long)
>> and manually adds pads for aligning for "__refcnt".
>>
>> When the size of struct rcu_head is changed, these manual padding
>> are hardly suit for the changes. So we rearrange the structure,
>> and move the seldom access rcu_head to the end of the structure.
>>
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>>
>> diff --git a/include/net/dst.h b/include/net/dst.h
>> index 93b0310..d8c5296 100644
>> --- a/include/net/dst.h
>> +++ b/include/net/dst.h
>> @@ -37,7 +37,6 @@
>> struct sk_buff;
>>
>> struct dst_entry {
>> - struct rcu_head rcu_head;
>> struct dst_entry *child;
>> struct net_device *dev;
>> short error;
>> @@ -78,6 +77,13 @@ struct dst_entry {
>> __u32 __pad2;
>> #endif
>>
>> + unsigned long lastuse;
>> + union {
>> + struct dst_entry *next;
>> + struct rtable __rcu *rt_next;
>> + struct rt6_info *rt6_next;
>> + struct dn_route __rcu *dn_next;
>> + };
>>
>> /*
>> * Align __refcnt to a 64 bytes alignment
>> @@ -92,13 +98,7 @@ struct dst_entry {
>> */
>> atomic_t __refcnt; /* client references */
>> int __use;
>> - unsigned long lastuse;
>> - union {
>> - struct dst_entry *next;
>> - struct rtable __rcu *rt_next;
>> - struct rt6_info *rt6_next;
>> - struct dn_route __rcu *dn_next;
>> - };
>> + struct rcu_head rcu_head;
>> };
>>
>> #ifdef __KERNEL__
>
> Nope...
>
> "lastuse" and "next" must be in this place, or this introduce false
> sharing we wanted to avoid in the past.
>
> I suggest you leave this code as is, we will address the problem when
> rcu_head changes (assuming we can test a CONFIG_RCU_HEAD_DEBUG or
> something)
>
> First part of "struct dst_entry" is mostly read, while part beginning
> after refcnt is often written.
>
Is it the cause of false sharing? I thought that all are rare write(except __refcnt)
since it is protected by RCU.
Do you allow me just move the seldom access rcu_head to the end of the structure
and add pads before __refcnt? I guess it increases about 3% the size of dst_entry.
I accept that I leave this code as is, when I change rcu_head I will notify you.
Thanks,
Lai
^ permalink raw reply
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Lai Jiangshan @ 2011-03-02 2:55 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Ingo Molnar, Paul E. McKenney, Eric Dumazet,
David S. Miller, Matt Mackall, linux-mm, linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.00.1103010909320.6253@router.home>
On 03/01/2011 11:11 PM, Christoph Lameter wrote:
> On Tue, 1 Mar 2011, Pekka Enberg wrote:
>
>> The SLAB and SLUB patches are fine by me if there are going to be real
>> users for this. Christoph, Paul?
>
> The solution is a bit overkill. It would be much simpler to add a union to
> struct page that has lru and the rcu in there similar things can be done
> for SLAB and the network layer. A similar issue already exists for the
> spinlock in struct page. Lets follow the existing way of handling this.
I don't want to impact the whole system too much to
touch struct page. The solution changes existed things little,
and the reversed data may just make use of the pad data.
>
> Struct page may be larger for debugging purposes already because of the
> need for extended spinlock data.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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