* (unknown),
From: kindergartenchaos2 @ 2017-10-16 11:30 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 567333220.zip --]
[-- Type: application/zip, Size: 46094 bytes --]
^ permalink raw reply
* [PATCH] [net-next] net: systemport: add NET_DSA dependency
From: Arnd Bergmann @ 2017-10-16 11:32 UTC (permalink / raw)
To: Florian Fainelli
Cc: Arnd Bergmann, David S. Miller, Michael Chan, Sathya Perla,
Nicolas Pitre, netdev, linux-kernel
The notifier cause a link error when NET_DSA is a loadable
module:
drivers/net/ethernet/broadcom/bcmsysport.o: In function `bcm_sysport_remove':
bcmsysport.c:(.text+0x1582): undefined reference to `unregister_dsa_notifier'
drivers/net/ethernet/broadcom/bcmsysport.o: In function `bcm_sysport_probe':
bcmsysport.c:(.text+0x278d): undefined reference to `register_dsa_notifier'
This adds a dependency that forces the systemport driver to be
a loadable module as well when that happens, but otherwise
allows it to be built normally when DSA is either built-in or
completely disabled.
Fixes: d156576362c0 ("net: systemport: Establish lower/upper queue mapping")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/broadcom/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/broadcom/Kconfig b/drivers/net/ethernet/broadcom/Kconfig
index 67134ece1107..af75156919ed 100644
--- a/drivers/net/ethernet/broadcom/Kconfig
+++ b/drivers/net/ethernet/broadcom/Kconfig
@@ -184,6 +184,7 @@ config BGMAC_PLATFORM
config SYSTEMPORT
tristate "Broadcom SYSTEMPORT internal MAC support"
depends on OF
+ depends on NET_DSA || !NET_DSA
select MII
select PHYLIB
select FIXED_PHY
--
2.9.0
^ permalink raw reply related
* [PATCH net] dev_ioctl: add missing NETDEV_CHANGE_TX_QUEUE_LEN event notification
From: Xin Long @ 2017-10-16 11:43 UTC (permalink / raw)
To: network dev; +Cc: davem
When changing dev tx_queue_len via netlink or net-sysfs,
a NETDEV_CHANGE_TX_QUEUE_LEN event notification will be
called.
But dev_ioctl missed this event notification, which could
cause no userspace notification would be sent.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/core/dev_ioctl.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/net/core/dev_ioctl.c b/net/core/dev_ioctl.c
index 709a4e6..f9c7a88 100644
--- a/net/core/dev_ioctl.c
+++ b/net/core/dev_ioctl.c
@@ -303,7 +303,18 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
case SIOCSIFTXQLEN:
if (ifr->ifr_qlen < 0)
return -EINVAL;
- dev->tx_queue_len = ifr->ifr_qlen;
+ if (dev->tx_queue_len ^ ifr->ifr_qlen) {
+ unsigned int orig_len = dev->tx_queue_len;
+
+ dev->tx_queue_len = ifr->ifr_qlen;
+ err = call_netdevice_notifiers(
+ NETDEV_CHANGE_TX_QUEUE_LEN, dev);
+ err = notifier_to_errno(err);
+ if (err) {
+ dev->tx_queue_len = orig_len;
+ return err;
+ }
+ }
return 0;
case SIOCSIFNAME:
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2 0/2] net: add memcpy_to[from]_msg()
From: yuan linyu @ 2017-10-16 12:10 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, yuan linyu
From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
v2:
fix kbuild warning
yuan linyu (2):
net: move memcpy_to[from]_msg() from skbuff.h to socket.h
net: add skb_memcpy_to[from]_msg() to optimize skb code
drivers/isdn/mISDN/socket.c | 2 +-
drivers/staging/irda/net/af_irda.c | 2 +-
include/linux/skbuff.h | 8 ++++----
include/linux/socket.h | 13 ++++++++++++-
net/appletalk/ddp.c | 2 +-
net/ax25/af_ax25.c | 2 +-
net/bluetooth/hci_sock.c | 4 ++--
net/bluetooth/rfcomm/sock.c | 2 +-
net/bluetooth/sco.c | 2 +-
net/caif/caif_socket.c | 6 +++---
net/can/bcm.c | 4 ++--
net/can/raw.c | 4 ++--
net/dccp/proto.c | 2 +-
net/decnet/af_decnet.c | 4 ++--
net/ieee802154/socket.c | 4 ++--
net/ipx/ipx_route.c | 2 +-
net/key/af_key.c | 2 +-
net/l2tp/l2tp_ip.c | 2 +-
net/l2tp/l2tp_ppp.c | 2 +-
net/llc/af_llc.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/nfc/rawsock.c | 2 +-
net/packet/af_packet.c | 2 +-
net/phonet/datagram.c | 2 +-
net/phonet/pep.c | 2 +-
25 files changed, 46 insertions(+), 35 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next v2 1/2] net: move memcpy_to[from]_msg() from skbuff.h to socket.h
From: yuan linyu @ 2017-10-16 12:10 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, yuan linyu
From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
these two functions used by skb and other places,
move to socket.h where struct msghdr defined.
Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
---
include/linux/skbuff.h | 10 ----------
include/linux/socket.h | 13 ++++++++++++-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 03634ec2..90868d1 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3294,16 +3294,6 @@ int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
struct sk_buff *pskb_extract(struct sk_buff *skb, int off, int to_copy,
gfp_t gfp);
-static inline int memcpy_from_msg(void *data, struct msghdr *msg, int len)
-{
- return copy_from_iter_full(data, len, &msg->msg_iter) ? 0 : -EFAULT;
-}
-
-static inline int memcpy_to_msg(struct msghdr *msg, void *data, int len)
-{
- return copy_to_iter(data, len, &msg->msg_iter) == len ? 0 : -EFAULT;
-}
-
struct skb_checksum_ops {
__wsum (*update)(const void *mem, int len, __wsum wsum);
__wsum (*combine)(__wsum csum, __wsum csum2, int offset, int len);
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 8ad963c..0a2048e 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -2,6 +2,7 @@
#define _LINUX_SOCKET_H
+#include <linux/errno.h>
#include <asm/socket.h> /* arch-dependent defines */
#include <linux/sockios.h> /* the SIOCxxx I/O controls */
#include <linux/uio.h> /* iovec support */
@@ -53,7 +54,17 @@ struct msghdr {
unsigned int msg_flags; /* flags on received message */
struct kiocb *msg_iocb; /* ptr to iocb for async requests */
};
-
+
+static inline int memcpy_from_msg(void *data, struct msghdr *msg, int len)
+{
+ return copy_from_iter_full(data, len, &msg->msg_iter) ? 0 : -EFAULT;
+}
+
+static inline int memcpy_to_msg(struct msghdr *msg, void *data, int len)
+{
+ return copy_to_iter(data, len, &msg->msg_iter) == len ? 0 : -EFAULT;
+}
+
struct user_msghdr {
void __user *msg_name; /* ptr to socket address structure */
int msg_namelen; /* size of socket address structure */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: add skb_memcpy_to[from]_msg() to optimize skb code
From: yuan linyu @ 2017-10-16 12:11 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller, yuan linyu
From: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
add these two wrappers in skbuff.h which is better named
than previous and only used for skb.
Signed-off-by: yuan linyu <Linyu.Yuan@alcatel-sbell.com.cn>
---
drivers/isdn/mISDN/socket.c | 2 +-
drivers/staging/irda/net/af_irda.c | 2 +-
include/linux/skbuff.h | 10 ++++++++++
net/appletalk/ddp.c | 2 +-
net/ax25/af_ax25.c | 2 +-
net/bluetooth/hci_sock.c | 4 ++--
net/bluetooth/rfcomm/sock.c | 2 +-
net/bluetooth/sco.c | 2 +-
net/caif/caif_socket.c | 6 +++---
net/can/bcm.c | 4 ++--
net/can/raw.c | 4 ++--
net/dccp/proto.c | 2 +-
net/decnet/af_decnet.c | 4 ++--
net/ieee802154/socket.c | 4 ++--
net/ipx/ipx_route.c | 2 +-
net/key/af_key.c | 2 +-
net/l2tp/l2tp_ip.c | 2 +-
net/l2tp/l2tp_ppp.c | 2 +-
net/llc/af_llc.c | 2 +-
net/netlink/af_netlink.c | 2 +-
net/nfc/rawsock.c | 2 +-
net/packet/af_packet.c | 2 +-
net/phonet/datagram.c | 2 +-
net/phonet/pep.c | 2 +-
24 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers/isdn/mISDN/socket.c b/drivers/isdn/mISDN/socket.c
index c5603d1..19ecf62 100644
--- a/drivers/isdn/mISDN/socket.c
+++ b/drivers/isdn/mISDN/socket.c
@@ -202,7 +202,7 @@ mISDN_sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
if (!skb)
goto done;
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
err = -EFAULT;
goto done;
}
diff --git a/drivers/staging/irda/net/af_irda.c b/drivers/staging/irda/net/af_irda.c
index 23fa7c8..159fc1a 100644
--- a/drivers/staging/irda/net/af_irda.c
+++ b/drivers/staging/irda/net/af_irda.c
@@ -1469,7 +1469,7 @@ static int irda_recvmsg_stream(struct socket *sock, struct msghdr *msg,
}
chunk = min_t(unsigned int, skb->len, size);
- if (memcpy_to_msg(msg, skb->data, chunk)) {
+ if (skb_memcpy_to_msg(msg, skb, chunk)) {
skb_queue_head(&sk->sk_receive_queue, skb);
if (copied == 0)
copied = -EFAULT;
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 90868d1..901fa60 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3294,6 +3294,16 @@ int skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci);
struct sk_buff *pskb_extract(struct sk_buff *skb, int off, int to_copy,
gfp_t gfp);
+static inline int skb_memcpy_from_msg(struct sk_buff *skb, struct msghdr *msg, int len)
+{
+ return memcpy_from_msg(skb_put(skb, len), msg, len);
+}
+
+static inline int skb_memcpy_to_msg(struct msghdr *msg, struct sk_buff *skb, int len)
+{
+ return memcpy_to_msg(msg, skb->data, len);
+}
+
struct skb_checksum_ops {
__wsum (*update)(const void *mem, int len, __wsum wsum);
__wsum (*combine)(__wsum csum, __wsum csum2, int offset, int len);
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 5d035c1..c7846c3 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1658,7 +1658,7 @@ static int atalk_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
SOCK_DEBUG(sk, "SK %p: Copy user data (%zd bytes).\n", sk, len);
- err = memcpy_from_msg(skb_put(skb, len), msg, len);
+ err = skb_memcpy_from_msg(skb, msg, len);
if (err) {
kfree_skb(skb);
err = -EFAULT;
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index f3f9d18..442763e 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1552,7 +1552,7 @@ static int ax25_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
skb_reserve(skb, size - len);
/* User data follows immediately after the AX.25 data */
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
err = -EFAULT;
kfree_skb(skb);
goto out;
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 65d734c..349c79a 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -1601,7 +1601,7 @@ static int hci_logging_frame(struct sock *sk, struct msghdr *msg, int len)
if (!skb)
return err;
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
err = -EFAULT;
goto drop;
}
@@ -1726,7 +1726,7 @@ static int hci_sock_sendmsg(struct socket *sock, struct msghdr *msg,
if (!skb)
goto done;
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
err = -EFAULT;
goto drop;
}
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 1aaccf6..41d19dc 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -594,7 +594,7 @@ static int rfcomm_sock_sendmsg(struct socket *sock, struct msghdr *msg,
}
skb_reserve(skb, RFCOMM_SKB_HEAD_RESERVE);
- err = memcpy_from_msg(skb_put(skb, size), msg, size);
+ err = skb_memcpy_from_msg(skb, msg, size);
if (err) {
kfree_skb(skb);
if (sent == 0)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 795e920..01958d2 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -288,7 +288,7 @@ static int sco_send_frame(struct sock *sk, struct msghdr *msg, int len)
if (!skb)
return err;
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
kfree_skb(skb);
return -EFAULT;
}
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 632d5a4..6b49e5a 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -422,7 +422,7 @@ static int caif_stream_recvmsg(struct socket *sock, struct msghdr *msg,
}
release_sock(sk);
chunk = min_t(unsigned int, skb->len, size);
- if (memcpy_to_msg(msg, skb->data, chunk)) {
+ if (skb_memcpy_to_msg(msg, skb, chunk)) {
skb_queue_head(&sk->sk_receive_queue, skb);
if (copied == 0)
copied = -EFAULT;
@@ -570,7 +570,7 @@ static int caif_seqpkt_sendmsg(struct socket *sock, struct msghdr *msg,
skb_reserve(skb, cf_sk->headroom);
- ret = memcpy_from_msg(skb_put(skb, len), msg, len);
+ ret = skb_memcpy_from_msg(skb, msg, len);
if (ret)
goto err;
@@ -645,7 +645,7 @@ static int caif_stream_sendmsg(struct socket *sock, struct msghdr *msg,
*/
size = min_t(int, size, skb_tailroom(skb));
- err = memcpy_from_msg(skb_put(skb, size), msg, size);
+ err = skb_memcpy_from_msg(skb, msg, size);
if (err) {
kfree_skb(skb);
goto out_err;
diff --git a/net/can/bcm.c b/net/can/bcm.c
index 47a8748d..6fb4670 100644
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -1269,7 +1269,7 @@ static int bcm_tx_send(struct msghdr *msg, int ifindex, struct sock *sk,
can_skb_reserve(skb);
- err = memcpy_from_msg(skb_put(skb, cfsiz), msg, cfsiz);
+ err = skb_memcpy_from_msg(skb, msg, cfsiz);
if (err < 0) {
kfree_skb(skb);
return err;
@@ -1642,7 +1642,7 @@ static int bcm_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
if (skb->len < size)
size = skb->len;
- err = memcpy_to_msg(msg, skb->data, size);
+ err = skb_memcpy_to_msg(msg, skb, size);
if (err < 0) {
skb_free_datagram(sk, skb);
return err;
diff --git a/net/can/raw.c b/net/can/raw.c
index 864c80d..b52d1db 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -766,7 +766,7 @@ static int raw_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
can_skb_prv(skb)->ifindex = dev->ifindex;
can_skb_prv(skb)->skbcnt = 0;
- err = memcpy_from_msg(skb_put(skb, size), msg, size);
+ err = skb_memcpy_from_msg(skb, msg, size);
if (err < 0)
goto free_skb;
@@ -813,7 +813,7 @@ static int raw_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
else
size = skb->len;
- err = memcpy_to_msg(msg, skb->data, size);
+ err = skb_memcpy_to_msg(msg, skb, size);
if (err < 0) {
skb_free_datagram(sk, skb);
return err;
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index b68168f..affe21a 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -785,7 +785,7 @@ int dccp_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
goto out_release;
skb_reserve(skb, sk->sk_prot->max_header);
- rc = memcpy_from_msg(skb_put(skb, len), msg, len);
+ rc = skb_memcpy_from_msg(skb, msg, len);
if (rc != 0)
goto out_discard;
diff --git a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c
index 73a0399..6fa54fd 100644
--- a/net/decnet/af_decnet.c
+++ b/net/decnet/af_decnet.c
@@ -1765,7 +1765,7 @@ static int dn_recvmsg(struct socket *sock, struct msghdr *msg, size_t size,
if ((chunk + copied) > size)
chunk = size - copied;
- if (memcpy_to_msg(msg, skb->data, chunk)) {
+ if (skb_memcpy_to_msg(msg, skb, chunk)) {
rv = -EFAULT;
break;
}
@@ -2036,7 +2036,7 @@ static int dn_sendmsg(struct socket *sock, struct msghdr *msg, size_t size)
skb_reserve(skb, 64 + DN_MAX_NSP_DATA_HEADER);
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
err = -EFAULT;
goto out;
}
diff --git a/net/ieee802154/socket.c b/net/ieee802154/socket.c
index a60658c..c4072a4 100644
--- a/net/ieee802154/socket.c
+++ b/net/ieee802154/socket.c
@@ -296,7 +296,7 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
skb_reset_mac_header(skb);
skb_reset_network_header(skb);
- err = memcpy_from_msg(skb_put(skb, size), msg, size);
+ err = skb_memcpy_from_msg(skb, msg, size);
if (err < 0)
goto out_skb;
@@ -684,7 +684,7 @@ static int dgram_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)
if (err < 0)
goto out_skb;
- err = memcpy_from_msg(skb_put(skb, size), msg, size);
+ err = skb_memcpy_from_msg(skb, msg, size);
if (err < 0)
goto out_skb;
diff --git a/net/ipx/ipx_route.c b/net/ipx/ipx_route.c
index b5d9144..72c8403 100644
--- a/net/ipx/ipx_route.c
+++ b/net/ipx/ipx_route.c
@@ -229,7 +229,7 @@ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx,
memcpy(ipx->ipx_dest.node, usipx->sipx_node, IPX_NODE_LEN);
ipx->ipx_dest.sock = usipx->sipx_port;
- rc = memcpy_from_msg(skb_put(skb, len), msg, len);
+ rc = skb_memcpy_from_msg(skb, msg, len);
if (rc) {
kfree_skb(skb);
goto out_put;
diff --git a/net/key/af_key.c b/net/key/af_key.c
index a00d607..af9b4b9 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -3637,7 +3637,7 @@ static int pfkey_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
goto out;
err = -EFAULT;
- if (memcpy_from_msg(skb_put(skb,len), msg, len))
+ if (skb_memcpy_from_msg(skb, msg, len))
goto out;
hdr = pfkey_get_base_msg(skb, &err);
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 4d322c1..3640f92 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -458,7 +458,7 @@ static int l2tp_ip_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
*((__be32 *) skb_put(skb, 4)) = 0;
/* Copy user data into skb */
- rc = memcpy_from_msg(skb_put(skb, len), msg, len);
+ rc = skb_memcpy_from_msg(skb, msg, len);
if (rc < 0) {
kfree_skb(skb);
goto error;
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index bc6e8bf..c54ebaf 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -329,7 +329,7 @@ static int pppol2tp_sendmsg(struct socket *sock, struct msghdr *m,
skb_put(skb, 2);
/* Copy user data into skb */
- error = memcpy_from_msg(skb_put(skb, total_len), m, total_len);
+ error = skb_memcpy_from_msg(skb, m, total_len);
if (error < 0) {
kfree_skb(skb);
goto error_put_sess_tun;
diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c
index c38d16f..aed88a1 100644
--- a/net/llc/af_llc.c
+++ b/net/llc/af_llc.c
@@ -928,7 +928,7 @@ static int llc_ui_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
skb->dev = llc->dev;
skb->protocol = llc_proto_type(addr->sllc_arphrd);
skb_reserve(skb, hdrlen);
- rc = memcpy_from_msg(skb_put(skb, copied), msg, copied);
+ rc = skb_memcpy_from_msg(skb, msg, copied);
if (rc)
goto out;
if (sk->sk_type == SOCK_DGRAM || addr->sllc_ua) {
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index f347506..5ce9ac2 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1844,7 +1844,7 @@ static int netlink_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
NETLINK_CB(skb).flags = netlink_skb_flags;
err = -EFAULT;
- if (memcpy_from_msg(skb_put(skb, len), msg, len)) {
+ if (skb_memcpy_from_msg(skb, msg, len)) {
kfree_skb(skb);
goto out;
}
diff --git a/net/nfc/rawsock.c b/net/nfc/rawsock.c
index e2188de..a7bf4d4 100644
--- a/net/nfc/rawsock.c
+++ b/net/nfc/rawsock.c
@@ -230,7 +230,7 @@ static int rawsock_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)
if (skb == NULL)
return rc;
- rc = memcpy_from_msg(skb_put(skb, len), msg, len);
+ rc = skb_memcpy_from_msg(skb, msg, len);
if (rc < 0) {
kfree_skb(skb);
return rc;
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 3f5caa3..162460b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1972,7 +1972,7 @@ static int packet_sendmsg_spkt(struct socket *sock, struct msghdr *msg,
if (len < hhlen)
skb_reset_network_header(skb);
}
- err = memcpy_from_msg(skb_put(skb, len), msg, len);
+ err = skb_memcpy_from_msg(skb, msg, len);
if (err)
goto out_free;
goto retry;
diff --git a/net/phonet/datagram.c b/net/phonet/datagram.c
index b44fb90..1ea1105 100644
--- a/net/phonet/datagram.c
+++ b/net/phonet/datagram.c
@@ -108,7 +108,7 @@ static int pn_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
return err;
skb_reserve(skb, MAX_PHONET_HEADER);
- err = memcpy_from_msg((void *)skb_put(skb, len), msg, len);
+ err = skb_memcpy_from_msg(skb, msg, len);
if (err < 0) {
kfree_skb(skb);
return err;
diff --git a/net/phonet/pep.c b/net/phonet/pep.c
index 9fc76b1..84870b6 100644
--- a/net/phonet/pep.c
+++ b/net/phonet/pep.c
@@ -1143,7 +1143,7 @@ static int pep_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
return err;
skb_reserve(skb, MAX_PHONET_HEADER + 3 + pn->aligned);
- err = memcpy_from_msg(skb_put(skb, len), msg, len);
+ err = skb_memcpy_from_msg(skb, msg, len);
if (err < 0)
goto outfree;
--
2.7.4
^ permalink raw reply related
* Re: RFC: making cn_proc work in {pid,user} namespaces
From: Aleksa Sarai @ 2017-10-16 12:11 UTC (permalink / raw)
To: Eric W. Biederman
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Linux Containers,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, dev,
cyphar-gVpy/LI/lHzQT0dZR+AlfA@public.gmane.org >> Aleksa Sarai,
Evgeniy Polyakov, Christian Brauner
In-Reply-To: <87r2u4nign.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>> At the moment, cn_proc is not usable by containers or container runtimes. In
>> addition, all connectors have an odd relationship with init_net (for example,
>> /proc/net/connectors only exists in init_net). There are two main use-cases that
>> would be perfect for cn_proc, which is the reason for me pushing this:
>>
>> First, when adding a process to an existing container, in certain modes runc
>> would like to know that process's exit code. But, when joining a PID namespace,
>> it is advisable[1] to always double-fork after doing the setns(2) to reparent
>> the joining process to the init of the container (this causes the SIGCHLD to be
>> received by the container init). It would also be useful to be able to monitor
>> the exit code of the init process in a container without being its parent. At
>> the moment, cn_proc doesn't allow unprivileged users to use it (making it a
>> problem for user namespaces and "rootless containers"). In addition, it also
>> doesn't allow nested containers to use it, because it requires the process to be
>> in init_pid. As a result, runc cannot use cn_proc and relies on SIGCHLD (which
>> can only be used if we don't double-fork, or keep around a long-running process
>> which is something that runc also cannot do).
>
> As far as I know there are no technical issues that require a
> daemonizing double fork when injecting a process into a pid namespaces.
> A fork is required because the pid is changing and that requires another
> process.
From memory I believe there was some issue that we saw, but because we
couldn't collect exit codes we didn't look into it much further. I will
try to write up a sample program to explain what I think the issue is
(it's related to who gets SIGCHLD inside the container in the "attach"
case).
> Monitoring and acting on the monitored state without keeping around a
> single process to do the monitoring does not make sense to me. So I am
> just going to ignore that.
/me just realised you can't use SIGCHLD with double-fork, because that
implies the process isn't actually reparented to the container's init. I
was referring to the "middle" process in a double-fork here, but that
obviously doesn't make sense.
> So I don't think fixing cn_proc for this issue makes sense.
>
>> Secondly, there are/were some init systems that rely on cn_proc to manage
>> service state. From a "it would be neat" perspective, I think it would be quite
>> nice if such init systems could be used inside containers. But that requires
>> cn_proc to be able to be used as an unprivileged user and in a pid namespace
>> other than init_pid.
>
> Any pointers to these init systems? In general I agree. Given how much
> work it takes to go through a subsystem and ensure that it is safe for
> non-root users I am happy to see the work done, but I am not
> volunteering for the work when I have several I have as many tasks as I
> have on my plate right now.
I *believe* (though I can't quite read scheme code) that GNU Shepherd
(used to be called dmd) is the most recent example that uses cn_proc.
Upstart /used/ to use it before they switched to ptrace.
However, we've also seen some users that are trying to use programs that
make use of cn_proc inside containers[1]. So I don't think this is a
problem that's going to go away (not to mention that I'm fairly
convinced that cn_proc might be the only sane way to currently get
process exit events if you're not their parent).
>> The /proc/net/connectors thing is quite easily resolved (just make it the
>> connector driver perdev and make some small changes to make sure the interfaces
>> stay sane inside of a container's network namespace). I'm sure that we'll
>> probably have to make some changes to the registration API, so that a connector
>> can specify whether they want to be visible to non-init_net
>> namespaces.
>>
>> However, the cn_proc problem is a bit harder to resolve nicely and there are
>> quite a few interface questions that would need to be agreed upon. The basic
>> idea would be that a process can only get cn_proc events if it has
>> ptrace_may_access rights over said process (effectively a forced filter -- which
>> would ideally be done send-side but it looks like it might have to be done
>> receive-side). This should resolve possible concerns about an unprivileged
>> process being able to inspect (fairly granular) information about the host. And
>> obviously the pids, uids, and gids would all be translated according to the
>> receiving process's user namespaces (if it cannot be translated then the message
>> is not received). I guess that the translation would be done in the same way as
>> SCM_CREDENTIALS (and cgroup.procs files), which is that it's done on the receive
>> side not the send side.
>
> Hmm. We have several of these things such as bsd process accounting
> which appear to be working fine.
>
> The basic logic winds up being:
> for_each_receiver:
> compose_msg in receivers namespace
> send_msg.
>
> The tricky bit in my mind is dealing with receivers because of the
> connection with the network namespace.
>
> SCM_CREDENTIALS is an unfortunate case, that really should not be
> followed as a model. The major challenge there is not knowing
> the receiving socket, or the receiver. If I had been smarter
> when I coded that originally I would have forced everything into
> the namespace of the opener of the receiving socket. I may have to
> revisit that one again someday and see if there are improvements that
> can be made.
When you say "namespace of the opener of the receiving socket", does
that mean that if a process moves the fd to a different set of
namespaces that the mappings will still be in relation to the old
namespace? Or am I misunderstanding?
>> My reason for sending this email rather than just writing the patch is to see
>> whether anyone has any solid NACKs against the use-case or whether there is some
>> fundamental issue that I'm not seeing. If nobody objects, I'll be happy to work
>> on this.
>
> If you want a non-crazy (with respect to namespace involvement) model
> please look at kernel/acct.c:acc_process()
Will do, I guess you're referring to do_acc_process()?
> If there are use cases that people still care about that use the
> proc connector and want to run in a container it seems sensible to dig
> in and sort things out. I think I have been hoping it is little enough
> used we won't have to mess with making it work in namespaces.
There are a few other container-related bugs in it that need to be
resolved anyway (see the discussion in [1] -- it's clearly not a
security issue per-se but it is a correctness one). I'll try to work
through those in either case, but I imagine that the architecture
reworks necessary to fix those issues will make making it work for
unprivileged users quite trivial (excluding the part where we have to
verify that there's no security issues opened by it).
[1]: https://github.com/moby/moby/issues/30176
--
Aleksa Sarai
Snr. Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
^ permalink raw reply
* Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Dmitry Vyukov @ 2017-10-16 12:16 UTC (permalink / raw)
To: Kalle Valo
Cc: Stanislaw Gruszka, Andrey Konovalov, Helmut Schaa, linux-wireless,
netdev, LKML, Kostya Serebryany, syzkaller
In-Reply-To: <8760bfo09s.fsf@kamboji.qca.qualcomm.com>
On Mon, Oct 16, 2017 at 12:27 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
> Dmitry Vyukov <dvyukov@google.com> writes:
>
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>> Hi
>>>
>>> On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>>>> I've got the following report while fuzzing the kernel with syzkaller.
>>>>
>>>> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>>>>
>>>> I'm not sure whether this is a bug in the driver, or just a way to
>>>> report misbehaving device. In the latter case this shouldn't be a
>>>> WARN() call, since WARN() means bug in the kernel.
>>>
>>> This is about wrong EEPROM, which reported 3 tx streams on
>>> non 3 antenna device. I think WARN() is justified and thanks
>>> to the call trace I was actually able to to understand what
>>> happened.
>>>
>>> In general I do not think WARN() only means a kernel bug, it
>>> can be F/W or H/W bug too.
>>
>> Hi Stanislaw,
>>
>> Printing messages is fine. Printing stacks is fine. Just please make
>> them distinguishable from kernel bugs and don't kill the whole
>> possibility of automated Linux kernel testing. That's an important
>> capability.
>
> Not really following you. Are you saying that using WARN() prevents
> automated Linux kernel testing?
Absence of a way to understand when there is something wrong with
kernel (something to notify kernel developers about) is the problem.
^ permalink raw reply
* Re: usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Dmitry Vyukov @ 2017-10-16 12:19 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Andrey Konovalov, Helmut Schaa, Kalle Valo, linux-wireless,
netdev, LKML, Kostya Serebryany, syzkaller
In-Reply-To: <20171016094024.GD2553@redhat.com>
On Mon, Oct 16, 2017 at 11:40 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> Hi Dmitry
>
> On Sat, Oct 14, 2017 at 04:38:03PM +0200, Dmitry Vyukov wrote:
>> On Thu, Oct 12, 2017 at 9:25 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> > Hi
>> >
>> > On Mon, Oct 09, 2017 at 07:50:53PM +0200, Andrey Konovalov wrote:
>> >> I've got the following report while fuzzing the kernel with syzkaller.
>> >>
>> >> On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
>> >>
>> >> I'm not sure whether this is a bug in the driver, or just a way to
>> >> report misbehaving device. In the latter case this shouldn't be a
>> >> WARN() call, since WARN() means bug in the kernel.
>> >
>> > This is about wrong EEPROM, which reported 3 tx streams on
>> > non 3 antenna device. I think WARN() is justified and thanks
>> > to the call trace I was actually able to to understand what
>> > happened.
>> >
>> > In general I do not think WARN() only means a kernel bug, it
>> > can be F/W or H/W bug too.
>>
>> Hi Stanislaw,
>>
>> Printing messages is fine. Printing stacks is fine. Just please make
>> them distinguishable from kernel bugs and don't kill the whole
>> possibility of automated Linux kernel testing. That's an important
>> capability.
>
> We do not distinguish between bugs and other problems when WARN() is
> used in (wireless) drivers, what I think is correct, taking comment from
> include/asm-generic/bug.h :
>
> /*
> * WARN(), WARN_ON(), WARN_ON_ONCE, and so on can be used to report
> * significant issues that need prompt attention if they should ever
> * appear at runtime. Use the versions with printk format strings
> * to provide better diagnostics.
> */
>
> Historically we have BUG() to mark the bugs, but usage if it is not
> recommended as it can kill the system, so for anything that can
> be recovered in runtime - WARN() is recommended.
>
> Perhaps we can introduce another helper like PROBLEM() for marking
> situations when something is wrong, but it is not a bug. However I'm
> not even sure at what extent it can be used, since for many cases
> if not the most, driver author can not tell apriori if the problem
> is a bug in the driver or HW/FW misbehaviour (or maybe particular
> issue can happen because of both).
I will write a separate email to LKML.
Thanks
^ permalink raw reply
* Re: [PATCH net 5/6] rtnetlink: check DO_SETLINK_NOTIFY correctly in do_setlink
From: Nicolas Dichtel @ 2017-10-16 12:20 UTC (permalink / raw)
To: David Ahern, Xin Long, network dev; +Cc: davem, hannes
In-Reply-To: <f3e88287-e2b8-06a9-a139-7a528749ef9e@gmail.com>
Le 16/10/2017 à 03:17, David Ahern a écrit :
> [ cc'ed Nicolas ]
>
> On 10/15/17 4:13 AM, Xin Long wrote:
>> The check 'status & DO_SETLINK_NOTIFY' in do_setlink doesn't really
>> work after status & DO_SETLINK_MODIFIED, as:
>>
>> DO_SETLINK_MODIFIED 0x1
>> DO_SETLINK_NOTIFY 0x3
>>
>> Considering that notifications are suppposed to be sent only when
>> status have the flag DO_SETLINK_NOTIFY, the right check would be:
>>
>> (status & DO_SETLINK_NOTIFY) == DO_SETLINK_NOTIFY
>>
>> This would avoid lots of duplicated notifications when setting some
>> properties of a link.
>>
>> Fixes: ba9989069f4e ("rtnl/do_setlink(): notify when a netdev is modified")
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Good catch, thank you.
Acked-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
^ permalink raw reply
* Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus
From: Andrew Lunn @ 2017-10-16 12:32 UTC (permalink / raw)
To: Martin Hundebøll
Cc: David S . Miller, netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20171016104525.26810-1-mnhu@prevas.dk>
On Mon, Oct 16, 2017 at 12:45:25PM +0200, Martin Hundebøll wrote:
> When configuring a switch port to use an external phy, the phy is
> connected to external switch MII bus:
Hi Martin
So this is a 6390?
So this used to work. I have a 10G phy connected to the external MII
bus on a 6390. I wonder when this got broken? Supporting phy-handle is
old code, so when i added the external MII i don't think i needed to
change any generic code.
I will take a closer look.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus
From: Andrew Lunn @ 2017-10-16 12:40 UTC (permalink / raw)
To: Martin Hundebøll
Cc: David S . Miller, netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20171016104525.26810-1-mnhu@prevas.dk>
> /* internal MII */
> mdio {
> switch0phy1@1 {
> reg = <1>;
> };
> };
>
> /* external MII */
> mdio1 {
> switch0phy0: switch0phy0@0 {
> reg = <0>;
> };
Hi Martin
You are missing a compatible string here. The binding document says:
- mdio? : Container of PHYs and devices on the external MDIO
bus. The node must contains a compatible string of
"marvell,mv88e6xxx-mdio-external"
Andrew
^ permalink raw reply
* Re: [PATCH net] net/sched: cls_flower: Set egress_dev mark when calling into the HW driver
From: Jiri Pirko @ 2017-10-16 12:41 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David S. Miller, Jiri Pirko, netdev, mlxsw, Roi Dayan
In-Reply-To: <1508145588-29959-1-git-send-email-ogerlitz@mellanox.com>
Mon, Oct 16, 2017 at 11:19:48AM CEST, ogerlitz@mellanox.com wrote:
>Commit 7091d8c '(net/sched: cls_flower: Add offload support using egress
>Hardware device') made sure (when fl_hw_replace_filter is called) to put
>the egress_dev mark on persisent structure instance. Hence, following calls
>into the HW driver for stats and deletion will note it and act accordingly.
>
>With commit de4784ca030f this property is lost and hence when called,
>the HW driver failes to operate (stats, delete) on the offloaded flow.
>
>Fix it by setting the egress_dev flag whenever the ingress device is
>different from the hw device since this is exactly the condition under
>which we're calling into the HW driver through the egress port net-device.
>
>Fixes: de4784ca030f ('net: sched: get rid of struct tc_to_netdev')
>Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
>Signed-off-by: Roi Dayan <roid@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus
From: Martin Hundebøll @ 2017-10-16 12:48 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S . Miller, netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20171016124002.GE4255@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]
Hi Andrew,
On 2017-10-16 14:40, Andrew Lunn wrote:
>> /* internal MII */
>> mdio {
>> switch0phy1@1 {
>> reg = <1>;
>> };
>> };
>>
>> /* external MII */
>> mdio1 {
>> switch0phy0: switch0phy0@0 {
>> reg = <0>;
>> };
>
> Hi Martin
>
> You are missing a compatible string here. The binding document says:
>
> - mdio? : Container of PHYs and devices on the external MDIO
> bus. The node must contains a compatible string of
> "marvell,mv88e6xxx-mdio-external"
>
> Andrew
>
Yeah, I have it in my full dts file (attached snippet), but decided to
limit the commit-message version to keep it short(er). Should I update
the commit message to avoid confusing others?
The issue is really that dsa_slave_phy_connect() always uses the the
mdio bus associated with struct dsa_switch, even when the phy-handle
refers to a phy from another mdio bus.
Or am I missing something ?
// Martin
[-- Attachment #2: armada-388-gp.dts --]
[-- Type: audio/vnd.dts, Size: 2311 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus
From: Martin Hundebøll @ 2017-10-16 12:56 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S . Miller, netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20171016123233.GD4255@lunn.ch>
On 2017-10-16 14:32, Andrew Lunn wrote:
> On Mon, Oct 16, 2017 at 12:45:25PM +0200, Martin Hundebøll wrote:
>> When configuring a switch port to use an external phy, the phy is
>> connected to external switch MII bus:
>
> So this is a 6390?
6390X
> So this used to work. I have a 10G phy connected to the external MII
> bus on a 6390. I wonder when this got broken? Supporting phy-handle is
> old code, so when i added the external MII i don't think i needed to
> change any generic code.
I had debug printing verifying that the external phy got registered with
mdiobus_register_device(), and that dsa_slave_phy_connect() looked in
the wrong mdio_map[].
// Martin
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi
From: Kalle Valo @ 2017-10-16 12:58 UTC (permalink / raw)
To: icenowy-h8G6r0blFSE
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Arend van Spriel,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Maxime Ripard,
Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <dba5f095f9f25f0726ee3a2852e01b88-h8G6r0blFSE@public.gmane.org>
icenowy-h8G6r0blFSE@public.gmane.org writes:
>>>>> > > Like I asked already last time, AFAICS there is no upstream xr819
>>>>> > > wireless driver in drivers/net/wireless directory. Do we still
>>>> accept
>>>>> > > bindings like this for out-of-tree drivers?
>>>>> >
>>>>> > See esp8089.
>>>>> >
>>>>> > There's also no in-tree driver for it.
>>>>>
>>>>> The question is whether we should. The above might be a precedent,
>>>> but it
>>>>> may not necessarily be the way to go. The commit message for esp8089
>>>> seems
>>>>> to hint that there is intent to have an in-tree driver:
>>>>>
>>>>> """
>>>>> Note that at this point there only is an out of tree driver for
>>>> this
>>>>> hardware, there is no clear timeline / path for merging this.
>>>> Still
>>>>> I believe it would be good to specify the binding for this in
>>>> tree
>>>>> now, so that any future migration to an in tree driver will not
>>>> cause
>>>>> compatiblity issues.
>>>>>
>>>>> Cc: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>>> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>>> """
>>>>>
>>>>> Regardless the bindings are in principle independent of the kernel
>>>> and just
>>>>> describing hardware. I think there have been discussions to move the
>>>>> bindings to their own repository, but apparently it was decided
>>>> otherwise.
>>>>
>>>> Yeah, I guess especially how it could be merged with the cw1200
>>>> driver
>>>> would be very relevant to that commit log.
>>>
>>> The cw1200 driver seems to still have some legacy platform
>>> data. Maybe they should also be convert to DT.
>>> (Or maybe compatible = "allwinner,xr819" is enough, as
>>> xr819 is a specified variant of cw1200 family)
>>
>> Ah, so the upstream cw1200 driver supports xr819? Has anyone tested
>> that? Or does cw1200 more changes than just adding the DT support?
>
> The support of XR819 in CW1200 driver is far more difficult than I
> imagined -- the codedrop used in the mainlined CW1200 driver seems to
> be so old that it's before XR819 (which seems to be based on CW1160),
> and there's a large number of problems to adapt it to a modern CW1200
> variant.
>
> P.S. could you apply this device tree binding patch now?
As I haven't seen any consensus that applying bindings document for
out-of-tree drivers is ok so at least I'm not taking this. Though not
sure what DT maintainers are planning to do.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH net-next 00/10] korina cleanups/optimizations
From: David Laight @ 2017-10-16 12:59 UTC (permalink / raw)
To: 'Roman Yeryomin', netdev
In-Reply-To: <20171015162226.606-1-roman@advem.lv>
From: Roman Yeryomin
> Sent: 15 October 2017 17:22
> TX optimizations have led to ~15% performance increase (35->40Mbps)
> in local tx usecase (tested with iperf v3.2).
Indicate which patches give the improvement.
IIRC some just changed the source without changing what the code really did.
(Not a problem in itself.)
...
> net: korina: optimize tx/rx interrupt handlers
You'd probably get a noticeable improvement from caching the
value of the interrupt mask - instead of reading it from the hardware.
...
David
^ permalink raw reply
* Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus
From: Martin Hundebøll @ 2017-10-16 13:16 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S . Miller, netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20171016123233.GD4255@lunn.ch>
On 2017-10-16 14:32, Andrew Lunn wrote:
> So this used to work. I have a 10G phy connected to the external MII
> bus on a 6390. I wonder when this got broken? Supporting phy-handle is
> old code, so when i added the external MII i don't think i needed to
> change any generic code.
It could look like commit cd28a1a9baee7 ('net: dsa: fully divert PHY
reads/writes if requested') changed the of-case to use the mdio bus
associated with struct dsa_switch unconditionally.
// Martin
^ permalink raw reply
* [PATCH] xen-netfront, xen-netback: Use correct minimum MTU values
From: Mohammed Gamal @ 2017-10-16 13:20 UTC (permalink / raw)
To: netdev, xen-devel, paul.durrant, wei.liu2
Cc: linux-kernel, vkuznets, otubo, cavery, cheshi, Mohammed Gamal
RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
drivers use a minimum value of 0.
When set MTU to 0~67 with xen_net{front|back} driver, the network
will become unreachable immediately, the guest can no longer be pinged.
xen_net{front|back} should not allow the user to set this value which causes
network problems.
Reported-by: Chen Shi <cheshi@redhat.com>
Signed-off-by: Mohammed Gamal <mgamal@redhat.com>
---
drivers/net/xen-netback/interface.c | 2 +-
drivers/net/xen-netfront.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index ee8ed9da..4491ca5 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -486,7 +486,7 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
dev->tx_queue_len = XENVIF_QUEUE_LENGTH;
- dev->min_mtu = 0;
+ dev->min_mtu = ETH_MIN_MTU;
dev->max_mtu = ETH_MAX_MTU - VLAN_ETH_HLEN;
/*
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 523387e..8b8689c 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1316,7 +1316,7 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
netdev->features |= netdev->hw_features;
netdev->ethtool_ops = &xennet_ethtool_ops;
- netdev->min_mtu = 0;
+ netdev->min_mtu = ETH_MIN_MTU;
netdev->max_mtu = XEN_NETIF_MAX_TX_SIZE;
SET_NETDEV_DEV(netdev, &dev->dev);
--
1.8.3.1
^ permalink raw reply related
* RE: [net-next 6/9] e1000e: fix buffer overrun while the I219 is processing DMA transactions
From: David Laight @ 2017-10-16 13:27 UTC (permalink / raw)
To: 'Neftin, Sasha', 'Jeff Kirsher',
davem@davemloft.net
Cc: netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com
In-Reply-To: <2c60b0c2-b257-fa86-c1c8-c8aa1fd40908@intel.com>
From: Neftin, Sasha
> Sent: 16 October 2017 11:40
> On 10/11/2017 12:07, David Laight wrote:
> > From: Jeff Kirsher
> >> Sent: 10 October 2017 18:22
> >> Intel 100/200 Series Chipset platforms reduced the round-trip
> >> latency for the LAN Controller DMA accesses, causing in some high
> >> performance cases a buffer overrun while the I219 LAN Connected
> >> Device is processing the DMA transactions. I219LM and I219V devices
> >> can fall into unrecovered Tx hang under very stressfully UDP traffic
> >> and multiple reconnection of Ethernet cable. This Tx hang of the LAN
> >> Controller is only recovered if the system is rebooted. Slightly slow
> >> down DMA access by reducing the number of outstanding requests.
> >> This workaround could have an impact on TCP traffic performance
> >> on the platform. Disabling TSO eliminates performance loss for TCP
> >> traffic without a noticeable impact on CPU performance.
> >>
> >> Please, refer to I218/I219 specification update:
> >> https://www.intel.com/content/www/us/en/embedded/products/networking/
> >> ethernet-connection-i218-family-documentation.html
> >>
> >> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
> >> Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
> >> Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
> >> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> >> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> >> ---
> >> drivers/net/ethernet/intel/e1000e/netdev.c | 8 +++++---
> >> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> >> index ee9de3500331..14b096f3d1da 100644
> >> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> >> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> >> @@ -3021,8 +3021,8 @@ static void e1000_configure_tx(struct e1000_adapter *adapter)
> >>
> >> hw->mac.ops.config_collision_dist(hw);
> >>
> >> - /* SPT and CNP Si errata workaround to avoid data corruption */
> >> - if (hw->mac.type >= e1000_pch_spt) {
> >> + /* SPT and KBL Si errata workaround to avoid data corruption */
> >> + if (hw->mac.type == e1000_pch_spt) {
> >> u32 reg_val;
> >>
> >> reg_val = er32(IOSFPC);
> >> @@ -3030,7 +3030,9 @@ static void e1000_configure_tx(struct e1000_adapter *adapter)
> >> ew32(IOSFPC, reg_val);
> >>
> >> reg_val = er32(TARC(0));
> >> - reg_val |= E1000_TARC0_CB_MULTIQ_3_REQ;
> >> + /* SPT and KBL Si errata workaround to avoid Tx hang */
> >> + reg_val &= ~BIT(28);
> >> + reg_val |= BIT(29);
> > Shouldn't some more of the commit message about what this is doing
> > be in the comment?
> There is provided link on specification update:
> https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/i218-i219-ethernet-
> connection-spec-update.pdf?asset=9561.
> This is Intel's public release.
And sometime next week the marketing people will decide to reorganise the
web site and the link will become invalid.
> > And shouldn't the 28 and 28 be named constants?
> (28 and 29) - you can easy understand from code that same value has been
> changed from 3 to 2. There is no point add flag here I thought.
Oh, there is. The 'workaround is':
Slightly slow down DMA access by reducing the number of outstanding requests.
This workaround could have an impact on TCP traffic performance and could
reduce performance up to 5 to 15% (depending) on the platform.
Disabling TSO eliminates performance loss for TCP traffic without a
noticeable impact on CPU performance.
I wonder what tests they did to show that TSO doesn't save cpu cycles!
So my guess is that you are changing the number of outstanding PCIe reads
(or reads for tx buffers, or ???) from 3 to 2.
Lets read between the lines a little further
(since you are at Intel you can probably check this):
Assuming that TSO is 'Transmit Segmentation Offload' and that TSO packets
might be 64k, then reading 3 TSO packets might issue PCIe reads for 196k
bytes of data (under 4k for non-TSO).
If the internal buffer that this data is stored in isn't that big then
that internal buffer would overflow.
It might be that data is removed from this buffer as soon as the last
completion TLP arrives - but they can be interleaved with other
outstanding PCIe reads.
It all rather depends on the negotiated maximum TLP size and number
of tags.
Perhaps reducing the maximum TSO packet to 32k stops the overflow
as well...
David
^ permalink raw reply
* [PATCH] tcp: cdg: make struct tcp_cdg static
From: Colin King @ 2017-10-16 13:33 UTC (permalink / raw)
To: David S . Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The structure tcp_cdg is local to the source and
does not need to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'tcp_cdg' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/ipv4/tcp_cdg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_cdg.c b/net/ipv4/tcp_cdg.c
index 66ac69f7bd19..06fbe102a425 100644
--- a/net/ipv4/tcp_cdg.c
+++ b/net/ipv4/tcp_cdg.c
@@ -389,7 +389,7 @@ static void tcp_cdg_release(struct sock *sk)
kfree(ca->gradients);
}
-struct tcp_congestion_ops tcp_cdg __read_mostly = {
+static struct tcp_congestion_ops tcp_cdg __read_mostly = {
.cong_avoid = tcp_cdg_cong_avoid,
.cwnd_event = tcp_cdg_cwnd_event,
.pkts_acked = tcp_cdg_acked,
--
2.14.1
^ permalink raw reply related
* Re: Kernel Performance Tuning for High Volume SCTP traffic
From: Neil Horman @ 2017-10-16 13:34 UTC (permalink / raw)
To: Traiano Welcome
Cc: David Laight, linux-sctp@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <CAFKCRVKScoF+AkBtsgGiFogN3KQP704v8Us9-OABy2BS-w4EVA@mail.gmail.com>
On Sat, Oct 14, 2017 at 10:29:53PM +0800, Traiano Welcome wrote:
> I've upped the value of the following sctp and udp related parameters,
> in the hope that this would help:
>
> sysctl -w net.core.rmem_max=900000000
> sysctl -w net.core.wmem_max=900000000
>
> sysctl -w net.sctp.sctp_mem="2100000000 2100000000 2100000000"
> sysctl -w net.sctp.sctp_rmem="2100000000 2100000000 2100000000"
> sysctl -w net.sctp.sctp_wmem="2100000000 2100000000 2100000000"
>
> sysctl -w net.ipv4.udp_mem="5000000000 5000000000 5000000000"
> sysctl -w net.ipv4.udp_mem="10000000000 10000000000 10000000000"
>
> However, I'm still seeing rapidly incrementing rx discards reported on the NIC:
>
> :~# ethtool -S ens4f1 | egrep -i rx_discards
> [0]: rx_discards: 6390805462
> [1]: rx_discards: 6659315919
> [2]: rx_discards: 6542570026
> [3]: rx_discards: 6431513008
> [4]: rx_discards: 6436779078
> [5]: rx_discards: 6665897051
> [6]: rx_discards: 6167985560
> [7]: rx_discards: 11340068788
> rx_discards: 56634934892
>
If you're getting drops in the hardware and nothing in the higher layers is
overflowing, then your problem is likely due to one of two things:
1) The NIC is discarding frames for reasons orthogonal to provisioning. That is
to say you are getting a large number of frames in that are being purposely
discarded. Check the other stats for the nic in ethtool to try give you some
additional visibilty on what these frames might be.
2) You're not servicing the NIC fast enough to pull frames out prior to its
internal buffer overflowing. Check the interrupt mitigation and flow
director/ntuple settings to make sure that you're seeing proper spreading of
packets to per-cpu queues, that interrupt mitigation is preventing undue cpu
load, and that irqbalance is properly distributing that interrupt rate to all
cpus in the system
Neil
> Despite the fact that I've set the NIC ring buffer on the Netextreme
> interface to he maximum:
>
> :~# ethtool -g ens4f0
> Ring parameters for ens4f0:
> Pre-set maximums:
> RX: 4078
> RX Mini: 0
> RX Jumbo: 0
> TX: 4078
> Current hardware settings:
> RX: 4078
> RX Mini: 0
> RX Jumbo: 0
> TX: 4078
>
> I see no ip errors at the physical interface:
>
> ethtool -S ens4f0 | egrep phy_ip_err_discard| tail -1
> rx_phy_ip_err_discards: 0
>
>
> Could anyone suggest alternative approaches I might take to optimising
> the system's handling of SCTP traffic?
>
>
>
> On Sat, Oct 14, 2017 at 12:35 AM, David Laight <David.Laight@aculab.com> wrote:
> > From: Traiano Welcome
> >> Sent: 13 October 2017 17:04
> >> On Fri, Oct 13, 2017 at 11:56 PM, David Laight <David.Laight@aculab.com> wrote:
> >> > From: Traiano Welcome
> >> >
> >> > (copied to netdev)
> >> >> Sent: 13 October 2017 07:16
> >> >> To: linux-sctp@vger.kernel.org
> >> >> Subject: Kernel Performance Tuning for High Volume SCTP traffic
> >> >>
> >> >> Hi List
> >> >>
> >> >> I'm running a linux server processing high volumes of SCTP traffic and
> >> >> am seeing large numbers of packet overruns (ifconfig output).
> >> >
> >> > I'd guess that overruns indicate that the ethernet MAC is failing to
> >> > copy the receive frames into kernel memory.
> >> > It is probably running out of receive buffers, but might be
> >> > suffering from a lack of bus bandwidth.
> >> > MAC drivers usually discard receive frames if they can't get
> >> > a replacement buffer - so you shouldn't run out of rx buffers.
> >> >
> >> > This means the errors are probably below SCTP - so changing SCTP parameters
> >> > is unlikely to help.
> >>
> >> Does this mean that tuning UDP performance could help ? Or do you mean
> >> hardware (NIC) performance could be the issue?
> >
> > I'd certainly check UDP performance.
> >
> > David
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] dsa: slave: support phy devices on external MII bus
From: Andrew Lunn @ 2017-10-16 13:39 UTC (permalink / raw)
To: Martin Hundebøll
Cc: David S . Miller, netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <02997de6-1c8a-d69b-d19b-3a811288e8ed@prevas.dk>
On Mon, Oct 16, 2017 at 03:16:51PM +0200, Martin Hundebøll wrote:
> On 2017-10-16 14:32, Andrew Lunn wrote:
> >So this used to work. I have a 10G phy connected to the external MII
> >bus on a 6390. I wonder when this got broken? Supporting phy-handle is
> >old code, so when i added the external MII i don't think i needed to
> >change any generic code.
>
> It could look like commit cd28a1a9baee7 ('net: dsa: fully divert PHY
> reads/writes if requested') changed the of-case to use the mdio bus
> associated with struct dsa_switch unconditionally.
Hi Martin
I think ds->phys_mii_mask is playing a role here. I need to add some
debug prints to my setup and see what is happening with my external
10G PHY.
This phy code is just too complex :-(
Andrew
^ permalink raw reply
* [PATCH] sunrcp: make function _svc_create_xprt static
From: Colin King @ 2017-10-16 13:40 UTC (permalink / raw)
To: J . Bruce Fields, Jeff Layton, Trond Myklebust, Anna Schumaker,
David S . Miller, linux-nfs, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The function _svc_create_xprt is local to the source and
does not need to be in global scope, so make it static.
Cleans up sparse warning:
symbol '_svc_create_xprt' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/sunrpc/svc_xprt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index d16a8b423c20..18e87791350f 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -250,9 +250,9 @@ void svc_add_new_perm_xprt(struct svc_serv *serv, struct svc_xprt *new)
svc_xprt_received(new);
}
-int _svc_create_xprt(struct svc_serv *serv, const char *xprt_name,
- struct net *net, const int family,
- const unsigned short port, int flags)
+static int _svc_create_xprt(struct svc_serv *serv, const char *xprt_name,
+ struct net *net, const int family,
+ const unsigned short port, int flags)
{
struct svc_xprt_class *xcl;
--
2.14.1
^ permalink raw reply related
* [PATCH net-next 0/2] net: core: rcuify rtnl af_ops
From: Florian Westphal @ 2017-10-16 13:44 UTC (permalink / raw)
To: netdev
None of the rtnl af_ops callbacks sleep, so they can be called while
holding rcu read lock.
Switch handling of af_ops to rcu.
This would allow to later call af_ops functions without holding
the rtnl mutex anymore.
core/rtnetlink.c | 134 ++++++++++++++++++++++++++++++++++++-------------------
ipv4/devinet.c | 4 -
2 files changed, 90 insertions(+), 48 deletions(-)
^ 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