* Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit
From: Xin Long @ 2016-10-24 6:30 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner, Vlad Yasevich,
Daniel Borkmann, David Miller, linux-sctp@vger.kernel.org,
Michael Tuexen, Eric Dumazet, Brenda Butler, gabor
In-Reply-To: <2fa21505-59c2-fb8b-6e89-11fccc953d25@mojatatu.com>
[1]
>> This patch doesn't ignore all the ENOMEN cases, only after msg is
>> enqueued in out queue/send queue, in the lower layer, when alloc
>> new skb and copy data from old skb, if it fails to alloc new skb, sctp
>> will ignore this ENOMEM, as this msg will be taken care by retransmit
>> mechanism, it's reasonable and also safe, user can't feel that.
>>
>
> Yes, that part i got.
>
[2]
>> But for the cases before enqueue, like in sctp_sendmsg,
>> sctp_datamsg_from_user may return ENOMEM, this err will return
>> back to user, and can't be ignored.
>>
>
> The hard part is distinguishing between the above case and real
> failure.
> I am assuming in the case above user is _not_ required to send
> again. But in the general case they are required to send again.
> Correct?
in case [1], user can't see the ENOMEM, ENOMEM is more like
a internal err.
in case [2], user will got the ENOMEM, they should resend this msg,
It's the the general case mentioned-above
>
>> So I don't really think we should change something in manpage, what
>> do you think ? maybe a little explanation there is also nice, :)
>
>
> Yes, that would help. In particular it should be clear what user space
> is expected to do. While this is about sctp - I am assuming equivalent
> behavior for all callers of sendxxx() regardless of protocol.
here sctp's behavior is actually same with tcp's, in tcp, tcp_transmit_skb
also may fail to alloc skb, but it doesn't return any err to user, just like
sctp_packet_transmit. That's why I don't think we should change something
in manpage, as here sctp is consistent with tcp now.
make sense ?
^ permalink raw reply
* [PATCH net] MAINTAINERS: Update qlogic networking drivers
From: Yuval Mintz @ 2016-10-24 5:48 UTC (permalink / raw)
To: davem, netdev
Cc: ameen.rahman, Ariel.Elior, harish.patil, rasesh.mody,
Manish.Chopra, Sudarsana.Kalluru, rahul.verma, Yuval Mintz
Following Cavium's acquisition of qlogic we need to update all the qlogic
drivers maintainer's entries to point to our new e-mail addresses,
as well as update some of the driver's maintainers as those are no longer
working for Cavium.
I would like to thank Sony Chacko and Rajesh Borundia for their support
and development of our various networking drivers.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
MAINTAINERS | 41 ++++++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fc66f0a..af299a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2543,15 +2543,18 @@ S: Supported
F: drivers/net/ethernet/broadcom/genet/
BROADCOM BNX2 GIGABIT ETHERNET DRIVER
-M: Sony Chacko <sony.chacko@qlogic.com>
-M: Dept-HSGLinuxNICDev@qlogic.com
+M: Rasesh Mody <rasesh.mody@cavium.com>
+M: Harish Patil <harish.patil@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/broadcom/bnx2.*
F: drivers/net/ethernet/broadcom/bnx2_*
BROADCOM BNX2X 10 GIGABIT ETHERNET DRIVER
-M: Ariel Elior <ariel.elior@qlogic.com>
+M: Yuval Mintz <Yuval.Mintz@cavium.com>
+M: Ariel Elior <ariel.elior@cavium.com>
+M: everest-linux-l2@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/broadcom/bnx2x/
@@ -2758,7 +2761,9 @@ S: Supported
F: drivers/scsi/bfa/
BROCADE BNA 10 GIGABIT ETHERNET DRIVER
-M: Rasesh Mody <rasesh.mody@qlogic.com>
+M: Rasesh Mody <rasesh.mody@cavium.com>
+M: Sudarsana Kalluru <sudarsana.kalluru@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/brocade/bna/
@@ -8492,11 +8497,10 @@ F: Documentation/devicetree/bindings/net/wireless/
F: drivers/net/wireless/
NETXEN (1/10) GbE SUPPORT
-M: Manish Chopra <manish.chopra@qlogic.com>
-M: Sony Chacko <sony.chacko@qlogic.com>
-M: Rajesh Borundia <rajesh.borundia@qlogic.com>
+M: Manish Chopra <manish.chopra@cavium.com>
+M: Rahul Verma <rahul.verma@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
-W: http://www.qlogic.com
S: Supported
F: drivers/net/ethernet/qlogic/netxen/
@@ -9873,33 +9877,32 @@ F: Documentation/scsi/LICENSE.qla4xxx
F: drivers/scsi/qla4xxx/
QLOGIC QLA3XXX NETWORK DRIVER
-M: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
-M: Ron Mercer <ron.mercer@qlogic.com>
-M: linux-driver@qlogic.com
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: Documentation/networking/LICENSE.qla3xxx
F: drivers/net/ethernet/qlogic/qla3xxx.*
QLOGIC QLCNIC (1/10)Gb ETHERNET DRIVER
-M: Dept-GELinuxNICDev@qlogic.com
+M: Harish Patil <harish.patil@cavium.com>
+M: Manish Chopra <manish.chopra@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qlcnic/
QLOGIC QLGE 10Gb ETHERNET DRIVER
-M: Harish Patil <harish.patil@qlogic.com>
-M: Sudarsana Kalluru <sudarsana.kalluru@qlogic.com>
-M: Dept-GELinuxNICDev@qlogic.com
-M: linux-driver@qlogic.com
+M: Harish Patil <harish.patil@cavium.com>
+M: Manish Chopra <manish.chopra@cavium.com>
+M: Dept-GELinuxNICDev@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qlge/
QLOGIC QL4xxx ETHERNET DRIVER
-M: Yuval Mintz <Yuval.Mintz@qlogic.com>
-M: Ariel Elior <Ariel.Elior@qlogic.com>
-M: everest-linux-l2@qlogic.com
+M: Yuval Mintz <Yuval.Mintz@cavium.com>
+M: Ariel Elior <Ariel.Elior@cavium.com>
+M: everest-linux-l2@cavium.com
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/ethernet/qlogic/qed/
--
1.9.3
^ permalink raw reply related
* [PATCH net] netvsc: fix incorrect receive checksum offloading
From: Stephen Hemminger @ 2016-10-24 4:32 UTC (permalink / raw)
To: David Miller, KY Srinivasan, Haiyang Zhang; +Cc: netdev
From: Stephen Hemminger <sthemmin@microsoft.com>
The Hyper-V netvsc driver was looking at the incorrect status bits
in the checksum info. It was setting the receive checksum unnecessary
flag based on the IP header checksum being correct. The checksum
flag is skb is about TCP and UDP checksum status. Because of this
bug, any packet received with bad TCP checksum would be passed
up the stack and to the application causing data corruption.
The problem is reproducible via netcat and netem.
This had a side effect of not doing receive checksum offload
on IPv6. The driver was also also always doing checksum offload
independent of the checksum setting done via ethtool.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
Please apply to -stable as well!
drivers/net/hyperv/netvsc_drv.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 5d6e75a..c71d966 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -607,15 +607,18 @@ static struct sk_buff *netvsc_alloc_recv_skb(struct net_device *net,
packet->total_data_buflen);
skb->protocol = eth_type_trans(skb, net);
- if (csum_info) {
- /* We only look at the IP checksum here.
- * Should we be dropping the packet if checksum
- * failed? How do we deal with other checksums - TCP/UDP?
- */
- if (csum_info->receive.ip_checksum_succeeded)
+
+ /* skb is already created with CHECKSUM_NONE */
+ skb_checksum_none_assert(skb);
+
+ /*
+ * In Linux, the IP checksum is always checked.
+ * Do L4 checksum offload if enabled and present.
+ */
+ if (csum_info && (net->features & NETIF_F_RXCSUM)) {
+ if (csum_info->receive.tcp_checksum_succeeded ||
+ csum_info->receive.udp_checksum_succeeded)
skb->ip_summed = CHECKSUM_UNNECESSARY;
- else
- skb->ip_summed = CHECKSUM_NONE;
}
if (vlan_tci & VLAN_TAG_PRESENT)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Shrijeet Mukherjee @ 2016-10-24 1:51 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Shrijeet Mukherjee, mst, Tom Herbert, Netdev, Roopa Prabhu,
Nikolay Aleksandrov
In-Reply-To: <20161023093808.161535f3@xeon-e3>
On Sun, Oct 23, 2016 at 9:38 AM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Overall, I am glad to see XDP support more widely available. Minor stuff
> in implementation.
>
>>
>> +/* this function is not called from the receive_buf path directly as
>> + * we want to use the page model for rx merge buffer and big buffers
>> + * and not use the fast path for driving skb's around
>> + */
>> +static inline u32 do_xdp_prog(struct virtnet_info *vi,
>> + struct receive_queue *rq,
>> + void *buf, int offset, int len)
>> +{
>
> Do not mark non-trivial static functions as inline. The compiler will
> do it anyway if it thinks it is appropriate.
>
> +static int virtnet_xdp_query(struct net_device *dev)
>
> Use bool here.
>
Ack on the bool.
the inline was my feeble attempt to minimize the overhead in the
"normal" path as currently I need a rcu deref followed by a
conditional. Wanted to ensure that we don't incur a call stack
overhead as well. But I will trust the compiler :)
> @@ -366,13 +420,22 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
hdr_len;
>
> This parts of the patch is white space creep. I.e other edits you did
> that stayed around.
Will clean up, thought I did .. but something must have come through.
>
> Do you have any performance numbers? Does the receive into pages hurt
> the non XDP performance?
>
No perf yet, on my limited env (laptop) I see higher packet drop rates
using the xdp_drop example, which is no surprise .. but I did not
change anything to recv into pages and instead opted to not support
the skb direct recv at all. And the other two modes were receiving
into pages and then forming skb's which is what I skipped if anything
other than XDP_PASS was returned.
The main goal of this patch was to start that discussion. My v2 patch
rejects the ndo op if neither of rx_mergeable or big_buffers are set.
Does that sound like a good tradeoff ? Don't know enough about who
turns these features off and why.
I can say that virtualbox always has the device features enabled .. so
seems like a good tradeoff ?
^ permalink raw reply
* Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU
From: Jarod Wilson @ 2016-10-24 1:50 UTC (permalink / raw)
To: Stefan Richter; +Cc: David S. Miller, netdev, linux1394-devel, linux-kernel
In-Reply-To: <20161023162903.4166a35d@kant>
On Sun, Oct 23, 2016 at 04:29:03PM +0200, Stefan Richter wrote:
> Commit b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> mistakenly introduced an upper limit for firewire-net's MTU based on the
> local link layer controller's reception capability. Revert this. Neither
> RFC 2734 nor our implementation impose any particular upper limit.
>
> Actually, to be on the safe side and to make the code explicit, set
> ETH_MAX_MTU = 65535 as upper limit now.
>
> (I replaced sizeof(struct rfc2734_header) by the equivalent
> RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
>
> Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Jarod Wilson <jarod@redhat.com>
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards
From: Jarod Wilson @ 2016-10-24 1:50 UTC (permalink / raw)
To: Stefan Richter; +Cc: David S. Miller, netdev, linux1394-devel, linux-kernel
In-Reply-To: <20161023163056.6bc38610@kant>
On Sun, Oct 23, 2016 at 04:30:56PM +0200, Stefan Richter wrote:
> firewire-net, like the older eth1394 driver, reduced the initial MTU to
> less than 1500 octets if the local link layer controller's asynchronous
> packet reception limit was lower.
>
> This is bogus, since this reception limit does not have anything to do
> with the transmission limit. Neither did this reduction affect the TX
> path positively, nor could it prevent link fragmentation at the RX path.
>
> Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
> of 1024 - 16 = 1008. RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
> which would result in an initial MTU of 512 - 16 = 496. On such cards,
> IPv6 could only be employed if the MTU was manually increased to 1280 or
> more, i.e. IPv6 would not work without intervention from userland.
>
> We now always initialize the MTU to 1500, which is the default according
> to RFC 2734 and RFC 3146.
>
> On a VIA VT6316 based CardBus card which was affected by this, changing
> the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
> RX remains unaffected.
>
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
> ---
> drivers/firewire/net.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
> index 99379542b263..03715e7d9d92 100644
> --- a/drivers/firewire/net.c
> +++ b/drivers/firewire/net.c
> @@ -1463,13 +1463,7 @@ static int fwnet_probe(struct fw_unit *unit,
> goto out;
> dev->local_fifo = dev->handler.offset;
>
> - /*
> - * Use the RFC 2734 default 1500 octets or the maximum payload
> - * as initial MTU
> - */
> - net->mtu = min(1500U,
> - (1U << (card->max_receive + 1))
> - - RFC2374_FRAG_HDR_SIZE - IEEE1394_GASP_HDR_SIZE);
> + net->mtu = 1500U;
Should be able to do just net->mtu = ETH_DATA_LEN;
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"
From: Jarod Wilson @ 2016-10-24 1:48 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: netdev, davem, b.a.t.m.a.n, linux-kernel
In-Reply-To: <2358358.cV5hCSMD7y@sven-edge>
On Sun, Oct 23, 2016 at 09:17:50AM +0200, Sven Eckelmann wrote:
> On Samstag, 22. Oktober 2016 21:08:26 CEST Jarod Wilson wrote:
> [...]
> > You're going to
> > need more than just this revert though, since batman-adv calls
> > ether_setup, which will set min_mtu = 68, max_mtu = 1500, unless
> > batadv_hardif_min_mtu() always returns something 1500 or less.
>
> It does only returns 1500 or less at the moment.
>
> return min_t(int, min_mtu - batadv_max_header_len(), ETH_DATA_LEN);
>
> > Actually,
> > looking at that, you could omit the mtu < 68 bit from
> > batadv_interface_change_mtu() too, since that'll already get done in the
> > core, but I have no clue what you need for max_mtu.
>
> I would like to get this revert through net-next.git before anything else.
Looks like that should work fine then.
--
Jarod Wilson
jarod@redhat.com
^ permalink raw reply
* Re: [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions
From: Linus Walleij @ 2016-10-24 1:03 UTC (permalink / raw)
To: Neil Armstrong
Cc: Kevin Hilman, Carlo Caione,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Amlogic Meson...,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1477060838-14164-2-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Add support for the Amlogic Meson GXL SoC, this is a partially complete
> definition only based on the Amlogic Vendor tree.
>
> This definition differs a lot from the GXBB and needs a separate entry.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Looks good to me. Tell me when I may apply it, it looks orthogonal
to the rest of the patches.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] udp: fix IP_CHECKSUM handling
From: Eric Dumazet @ 2016-10-24 1:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sam Kumar, Willem de Bruijn, Tom Herbert
From: Eric Dumazet <edumazet@google.com>
First bug was added in commit ad6f939ab193 ("ip: Add offset parameter to
ip_cmsg_recv") : Tom missed that ipv4 udp messages could be received on
AF_INET6 socket. ip_cmsg_recv(msg, skb) should have been replaced by
ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr));
Then commit e6afc8ace6dd ("udp: remove headers from UDP packets before
queueing") forgot to adjust the offsets now UDP headers are pulled
before skb are put in receive queue.
Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv")
Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sam Kumar <samanthakumar@google.com>
Cc: Willem de Bruijn <willemb@google.com>
---
Tom, I would appreciate your feedback on this patch, I presume
you have tests to verify IP_CHECKSUM feature ? Thanks !
include/net/ip.h | 4 ++--
net/ipv4/ip_sockglue.c | 11 ++++++-----
net/ipv4/udp.c | 2 +-
net/ipv6/udp.c | 3 ++-
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index c9d07988911e..5413883ac47f 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -578,7 +578,7 @@ int ip_options_rcv_srr(struct sk_buff *skb);
*/
void ipv4_pktinfo_prepare(const struct sock *sk, struct sk_buff *skb);
-void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb, int offset);
+void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb, int tlen, int offset);
int ip_cmsg_send(struct sock *sk, struct msghdr *msg,
struct ipcm_cookie *ipc, bool allow_ipv6);
int ip_setsockopt(struct sock *sk, int level, int optname, char __user *optval,
@@ -600,7 +600,7 @@ void ip_local_error(struct sock *sk, int err, __be32 daddr, __be16 dport,
static inline void ip_cmsg_recv(struct msghdr *msg, struct sk_buff *skb)
{
- ip_cmsg_recv_offset(msg, skb, 0);
+ ip_cmsg_recv_offset(msg, skb, 0, 0);
}
bool icmp_global_allow(void);
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index af4919792b6a..b8a2d63d1fb8 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -98,7 +98,7 @@ static void ip_cmsg_recv_retopts(struct msghdr *msg, struct sk_buff *skb)
}
static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb,
- int offset)
+ int tlen, int offset)
{
__wsum csum = skb->csum;
@@ -106,8 +106,9 @@ static void ip_cmsg_recv_checksum(struct msghdr *msg, struct sk_buff *skb,
return;
if (offset != 0)
- csum = csum_sub(csum, csum_partial(skb_transport_header(skb),
- offset, 0));
+ csum = csum_sub(csum,
+ csum_partial(skb_transport_header(skb) + tlen,
+ offset, 0));
put_cmsg(msg, SOL_IP, IP_CHECKSUM, sizeof(__wsum), &csum);
}
@@ -153,7 +154,7 @@ static void ip_cmsg_recv_dstaddr(struct msghdr *msg, struct sk_buff *skb)
}
void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb,
- int offset)
+ int tlen, int offset)
{
struct inet_sock *inet = inet_sk(skb->sk);
unsigned int flags = inet->cmsg_flags;
@@ -216,7 +217,7 @@ void ip_cmsg_recv_offset(struct msghdr *msg, struct sk_buff *skb,
}
if (flags & IP_CMSG_CHECKSUM)
- ip_cmsg_recv_checksum(msg, skb, offset);
+ ip_cmsg_recv_checksum(msg, skb, tlen, offset);
}
EXPORT_SYMBOL(ip_cmsg_recv_offset);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 311613e413cb..d123d68f4d1d 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1322,7 +1322,7 @@ int udp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len, int noblock,
*addr_len = sizeof(*sin);
}
if (inet->cmsg_flags)
- ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr) + off);
+ ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr), off);
err = copied;
if (flags & MSG_TRUNC)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 9aa7c1c7a9ce..b2ef061e6836 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -427,7 +427,8 @@ int udpv6_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
if (is_udp4) {
if (inet->cmsg_flags)
- ip_cmsg_recv(msg, skb);
+ ip_cmsg_recv_offset(msg, skb,
+ sizeof(struct udphdr), off);
} else {
if (np->rxopt.all)
ip6_datagram_recv_specific_ctl(sk, msg, skb);
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2016-10-23 23:34 UTC (permalink / raw)
To: David Miller, Networking
Cc: linux-next, linux-kernel, Eric Dumazet, Paolo Abeni
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
include/net/udp.h
between commit:
286c72deabaa ("udp: must lock the socket in udp_disconnect()")
from the net tree and commit:
f970bd9e3a06 ("udp: implement memory accounting helpers")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc include/net/udp.h
index 4948790d393d,18f1e6b91927..000000000000
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@@ -258,7 -261,7 +261,8 @@@ void udp_flush_pending_frames(struct so
void udp4_hwcsum(struct sk_buff *skb, __be32 src, __be32 dst);
int udp_rcv(struct sk_buff *skb);
int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ int udp_init_sock(struct sock *sk);
+int __udp_disconnect(struct sock *sk, int flags);
int udp_disconnect(struct sock *sk, int flags);
unsigned int udp_poll(struct file *file, struct socket *sock, poll_table *wait);
struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
^ permalink raw reply
* Re: [PATCH net 1/1] net sched filters: fix notification of filter delete with proper handle
From: Daniel Borkmann @ 2016-10-23 22:30 UTC (permalink / raw)
To: Jamal Hadi Salim, davem; +Cc: netdev, xiyou.wangcong, eric.dumazet
In-Reply-To: <1477236912-5789-1-git-send-email-jhs@emojatatu.com>
On 10/23/2016 05:35 PM, Jamal Hadi Salim wrote:
> From: Jamal Hadi Salim <jhs@mojatatu.com>
>
An actual commit message would be good especially if it's a fix
for -net tree plus stable. Thanks.
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> ---
> net/sched/cls_api.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 2ee29a3..2b2a797 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -345,7 +345,8 @@ static int tc_ctl_tfilter(struct sk_buff *skb, struct nlmsghdr *n)
> if (err == 0) {
> struct tcf_proto *next = rtnl_dereference(tp->next);
>
> - tfilter_notify(net, skb, n, tp, fh,
> + tfilter_notify(net, skb, n, tp,
> + t->tcm_handle,
> RTM_DELTFILTER, false);
> if (tcf_destroy(tp, false))
> RCU_INIT_POINTER(*back, next);
>
^ permalink raw reply
* Re: pull request: bluetooth 2016-10-21
From: David Miller @ 2016-10-23 21:52 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20161021144053.GA14245@x1c.dominarus.com>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Fri, 21 Oct 2016 17:40:53 +0300
> Here are some more Bluetooth fixes for the 4.9 kernel:
>
> - Fix to btwilink driver probe function return value
> - Power management fix to hci_bcm
> - Fix to encoding name in scan response data
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thanks Johan.
^ permalink raw reply
* Re: [PATCH net-next] lwt: Remove unused len field
From: David Miller @ 2016-10-23 21:45 UTC (permalink / raw)
To: tgraf; +Cc: tom, roopa, netdev
In-Reply-To: <fb52764c89fa8c11ec832bd4ddf7595b6a673ce1.1477058913.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Fri, 21 Oct 2016 16:10:22 +0200
> The field is initialized by ILA and MPLS but never used. Remove it.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
Applied, thanks Thomas.
^ permalink raw reply
* Re: [PATCH] net: sctp, forbid negative length
From: David Miller @ 2016-10-23 21:44 UTC (permalink / raw)
To: jslaby; +Cc: vyasevich, linux-kernel, nhorman, linux-sctp, netdev
In-Reply-To: <20161021121324.13942-1-jslaby@suse.cz>
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 21 Oct 2016 14:13:24 +0200
> Most of getsockopt handlers in net/sctp/socket.c check len against
> sizeof some structure like:
> if (len < sizeof(int))
> return -EINVAL;
>
> On the first look, the check seems to be correct. But since len is int
> and sizeof returns size_t, int gets promoted to unsigned size_t too. So
> the test returns false for negative lengths. Yes, (-1 < sizeof(long)) is
> false.
>
> Fix this in sctp by explicitly checking len < 0 before any getsockopt
> handler is called.
>
> Note that sctp_getsockopt_events already handled the negative case.
> Since we added the < 0 check elsewhere, this one can be removed.
>
> If not checked, this is the result:
...
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] net: fec: Call swap_buffer() prior to IP header alignment
From: David Miller @ 2016-10-23 21:42 UTC (permalink / raw)
To: festevam
Cc: fugang.duan, henri.roosen, eric, kernel, rmk, netdev,
fabio.estevam
In-Reply-To: <1477049669-25101-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 21 Oct 2016 09:34:29 -0200
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit 3ac72b7b63d5 ("net: fec: align IP header in hardware") breaks
> networking on mx28.
>
> There is an erratum on mx28 (ENGR121613 - ENET big endian mode
> not compatible with ARM little endian) that requires an additional
> byte-swap operation to workaround this problem.
>
> So call swap_buffer() prior to performing the IP header alignment
> to restore network functionality on mx28.
>
> Fixes: 3ac72b7b63d5 ("net: fec: align IP header in hardware")
> Reported-and-tested-by: Henri Roosen <henri.roosen@ginzinger.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/1] driver: tun: Forbid to set IFF_TUN and IFF_TAP at the same time
From: David Miller @ 2016-10-23 21:40 UTC (permalink / raw)
To: fgao; +Cc: jasowang, edumazet, pabeni, netdev, gfree.wind
In-Reply-To: <1477047735-26003-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
Date: Fri, 21 Oct 2016 19:02:15 +0800
> From: Gao Feng <fgao@ikuai8.com>
>
> Current tun driver permits the ifr_flags is set with IFF_TUN and
> IFF_TAP at the same time. But actually there is only IFF_TUN flag
> works. And it does not make sense these two flags are set, so add
> this check.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
We've allowed this for too long to start failing on it now, sorry.
^ permalink raw reply
* Re: [PATCH] ipv6: do not increment mac header when it's unset
From: David Miller @ 2016-10-23 21:40 UTC (permalink / raw)
To: Jason
Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel, pageexec,
re.emese
In-Reply-To: <20161021092825.28085-1-Jason@zx2c4.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Fri, 21 Oct 2016 18:28:25 +0900
> Otherwise we'll overflow the integer. This occurs when layer 3 tunneled
> packets are handed off to the IPv6 layer.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Applied, thanks.
Have fun playing with WireGuard.
^ permalink raw reply
* Re: [PATCH net 1/1] bnx2x: Use the correct divisor value for PHC clock readings.
From: David Miller @ 2016-10-23 21:35 UTC (permalink / raw)
To: Sony.Chacko; +Cc: netdev, Ariel.Elior, Yuval.Mintz, sudarsana.kalluru
In-Reply-To: <1477030157-30700-1-git-send-email-Sony.Chacko@cavium.com>
From: <Sony.Chacko@cavium.com>
Date: Fri, 21 Oct 2016 02:09:17 -0400
> From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
>
> Time Sync (PTP) implementation uses the divisor/shift value for converting
> the clock ticks to nanoseconds. Driver currently defines shift value as 1,
> this results in the nanoseconds value to be calculated as half the actual
> value. Hence the user application fails to synchronize the device clock
> value with the PTP master device clock. Need to use the 'shift' value of 0.
>
> Signed-off-by: Sony.Chacko <Sony.Chacko@cavium.com>
> Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: allow to kill a task which waits net_mutex in copy_new_ns
From: David Miller @ 2016-10-23 21:34 UTC (permalink / raw)
To: avagin-GEFAQzZX7r8dnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477017943-18786-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
From: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Date: Thu, 20 Oct 2016 19:45:43 -0700
> From: Andrey Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
>
> net_mutex can be locked for a long time. It may be because many
> namespaces are being destroyed or many processes decide to create
> a network namespace.
>
> Both these operations are heavy, so it is better to have an ability to
> kill a process which is waiting net_mutex.
>
> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames
From: David Miller @ 2016-10-23 21:31 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: jhs, netdev, jiri, eric.dumazet, stephen
In-Reply-To: <1476998288-13341-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Fri, 21 Oct 2016 00:18:08 +0300
> META_COLLECTOR int_vlan_tag() assumes that if the accel tag (vlan_tci)
> is zero, then no vlan accel tag is present.
>
> This is incorrect for zero VID vlan accel packets, making the following
> match fail:
> tc filter add ... basic match 'meta(vlan mask 0xfff eq 0)' ...
>
> Apparently 'int_vlan_tag' was implemented prior VLAN_TAG_PRESENT was
> introduced in 05423b2 "vlan: allow null VLAN ID to be used"
> (and at time introduced, the 'vlan_tx_tag_get' call in em_meta was not
> adapted).
>
> Fix, testing skb_vlan_tag_present instead of testing skb_vlan_tag_get's
> value.
>
> Fixes: 05423b2413 ("vlan: allow null VLAN ID to be used")
> Fixes: 1a31f2042e ("netsched: Allow meta match on vlan tag on receive")
>
> Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next 0/6] mlxsw: Driver update
From: David Miller @ 2016-10-23 21:22 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1477058843-9981-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 21 Oct 2016 16:07:17 +0200
> Mostly cosmetics and small resource values management rewrite.
Series applied, thanks Jiri.
^ permalink raw reply
* Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit
From: Jamal Hadi Salim @ 2016-10-23 19:52 UTC (permalink / raw)
To: Xin Long
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner, Vlad Yasevich,
Daniel Borkmann, David Miller, linux-sctp@vger.kernel.org,
Michael Tuexen, Eric Dumazet, Brenda Butler, gabor
In-Reply-To: <CADvbK_ci-aaX6-mgXTgR0mJm9ww7+48DmXH+m5R+-0PyMDH16g@mail.gmail.com>
On 16-10-23 02:20 PM, Xin Long wrote:
> This patch doesn't ignore all the ENOMEN cases, only after msg is
> enqueued in out queue/send queue, in the lower layer, when alloc
> new skb and copy data from old skb, if it fails to alloc new skb, sctp
> will ignore this ENOMEM, as this msg will be taken care by retransmit
> mechanism, it's reasonable and also safe, user can't feel that.
>
Yes, that part i got.
> But for the cases before enqueue, like in sctp_sendmsg,
> sctp_datamsg_from_user may return ENOMEM, this err will return
> back to user, and can't be ignored.
>
The hard part is distinguishing between the above case and real
failure.
I am assuming in the case above user is _not_ required to send
again. But in the general case they are required to send again.
Correct?
> So I don't really think we should change something in manpage, what
> do you think ? maybe a little explanation there is also nice, :)
Yes, that would help. In particular it should be clear what user space
is expected to do. While this is about sctp - I am assuming equivalent
behavior for all callers of sendxxx() regardless of protocol.
cheers,
jamal
^ permalink raw reply
* Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit
From: Xin Long @ 2016-10-23 18:20 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: netdev@vger.kernel.org, Marcelo Ricardo Leitner, Vlad Yasevich,
Daniel Borkmann, David Miller, linux-sctp@vger.kernel.org,
Michael Tuexen, Eric Dumazet, Brenda Butler, gabor
In-Reply-To: <daecd6b5-47cf-c5de-90f5-445e0038dfce@mojatatu.com>
> I think the specific use case this patch addresses
> seems to have bitten us in an older kernel sctp (3.11?).
> A send() on a loaded network box caused the skb to
> alloc in what appears to be this code path and fail (problem
> is intermittent, so not 100% sure). errno seen was ENOMEM.
> Unfortunately the manpage for sendxxx sucks.
> It says "no memory available".
> [We'll fix the manpage if there is an appropriate answer].
>
> Two questions:
> a) Seems like we can safely ignore ENOMEM in user space
> at least for this use case. i.e the kernel will retry and
> eventually send this message. Is there any other scenario
> where we have to worry about ENOMEM showing up in user space?
>
> b) What is the general view of what sendXXX reaction oughta
> be from user space in presence of ENOMEM?
>
This patch doesn't ignore all the ENOMEN cases, only after msg is
enqueued in out queue/send queue, in the lower layer, when alloc
new skb and copy data from old skb, if it fails to alloc new skb, sctp
will ignore this ENOMEM, as this msg will be taken care by retransmit
mechanism, it's reasonable and also safe, user can't feel that.
But for the cases before enqueue, like in sctp_sendmsg,
sctp_datamsg_from_user may return ENOMEM, this err will return
back to user, and can't be ignored.
So I don't really think we should change something in manpage, what
do you think ? maybe a little explanation there is also nice, :)
^ permalink raw reply
* [PATCH net] sctp: fix the panic caused by route update
From: Xin Long @ 2016-10-23 17:01 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: davem, Marcelo Ricardo Leitner, Vlad Yasevich, daniel
Commit 7303a1475008 ("sctp: identify chunks that need to be fragmented
at IP level") made the chunk be fragmented at IP level in the next round
if it's size exceed PMTU.
But there still is another case, PMTU can be updated if transport's dst
expires and transport's pmtu_pending is set in sctp_packet_transmit. If
the new PMTU is less than the chunk, the same issue with that commit can
be triggered.
So we should drop this packet and let it retransmit in another round
where it would be fragmented at IP level.
This patch is to fix it by checking the chunk size after PMTU may be
updated and dropping this packet if it's size exceed PMTU.
Fixes: 90017accff61 ("sctp: Add GSO support")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/sctp/output.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 2a5c189..6cb0df8 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -418,6 +418,7 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
__u8 has_data = 0;
int gso = 0;
int pktcount = 0;
+ int auth_len = 0;
struct dst_entry *dst;
unsigned char *auth = NULL; /* pointer to auth in skb data */
@@ -510,7 +511,12 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t gfp)
list_for_each_entry(chunk, &packet->chunk_list, list) {
int padded = SCTP_PAD4(chunk->skb->len);
- if (pkt_size + padded > tp->pathmtu)
+ if (chunk == packet->auth)
+ auth_len = padded;
+ else if (auth_len + padded + packet->overhead >
+ tp->pathmtu)
+ goto nomem;
+ else if (pkt_size + padded > tp->pathmtu)
break;
pkt_size += padded;
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Stephen Hemminger @ 2016-10-23 16:38 UTC (permalink / raw)
To: Shrijeet Mukherjee; +Cc: mst, tom, netdev, shm, roopa, nikolay
In-Reply-To: <1477109243-29520-1-git-send-email-shrijeet@gmail.com>
Overall, I am glad to see XDP support more widely available. Minor stuff
in implementation.
>
> +/* this function is not called from the receive_buf path directly as
> + * we want to use the page model for rx merge buffer and big buffers
> + * and not use the fast path for driving skb's around
> + */
> +static inline u32 do_xdp_prog(struct virtnet_info *vi,
> + struct receive_queue *rq,
> + void *buf, int offset, int len)
> +{
Do not mark non-trivial static functions as inline. The compiler will
do it anyway if it thinks it is appropriate.
+static int virtnet_xdp_query(struct net_device *dev)
Use bool here.
@@ -366,13 +420,22 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
...
if (unlikely(!curr_skb))
goto err_skb;
+
while (--num_buf) {
int num_skb_frags;
@@ -1878,7 +2000,6 @@ static int virtnet_probe(struct virtio_device *vdev)
if (virtnet_change_mtu(dev, mtu))
__virtio_clear_bit(vdev, VIRTIO_NET_F_MTU);
}
-
if (vi->any_header_sg)
dev->needed_headroom = vi->hdr_len;
This parts of the patch is white space creep. I.e other edits you did
that stayed around.
Do you have any performance numbers? Does the receive into pages hurt
the non XDP performance?
^ 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