[PATCH net] MAINTAINERS: Update qlogic networking drivers

[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 
---

 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 
-M: dept-hsglinuxnic...@qlogic.com
+M: Rasesh Mody 
+M: Harish Patil 
+M: dept-gelinuxnic...@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 
+M: Yuval Mintz 
+M: Ariel Elior 
+M: everest-linux...@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 
+M: Rasesh Mody 
+M: Sudarsana Kalluru 
+M: dept-gelinuxnic...@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 
-M: Sony Chacko 
-M: Rajesh Borundia 
+M: Manish Chopra 
+M: Rahul Verma 
+M: dept-gelinuxnic...@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 
-M: Ron Mercer 
-M: linux-dri...@qlogic.com
+M: dept-gelinuxnic...@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-gelinuxnic...@qlogic.com
+M: Harish Patil 
+M: Manish Chopra 
+M: dept-gelinuxnic...@cavium.com
 L: netdev@vger.kernel.org
 S: Supported
 F: drivers/net/ethernet/qlogic/qlcnic/
 
 QLOGIC QLGE 10Gb ETHERNET DRIVER
-M: Harish Patil 
-M: Sudarsana Kalluru 
-M: dept-gelinuxnic...@qlogic.com
-M: linux-dri...@qlogic.com
+M: Harish Patil 
+M: Manish Chopra 
+M: dept-gelinuxnic...@cavium.com
 L: netdev@vger.kernel.org
 S: Supported
 F: drivers/net/ethernet/qlogic/qlge/
 
 QLOGIC QL4xxx ETHERNET DRIVER
-M: Yuval Mintz 
-M: Ariel Elior 
-M: everest-linux...@qlogic.com
+M: Yuval Mintz 
+M: Ariel Elior 
+M: everest-linux...@cavium.com
 L: netdev@vger.kernel.org
 S: Supported
 F: drivers/net/ethernet/qlogic/qed/
-- 
1.9.3

[PATCH net] netvsc: fix incorrect receive checksum offloading

[Stephen Hemminger]

From: Stephen Hemminger 

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 
---
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

Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net

[Shrijeet Mukherjee]

On Sun, Oct 23, 2016 at 9:38 AM, Stephen Hemminger
 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 ?

Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU

[Jarod Wilson]

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-de...@lists.sourceforge.net
> CC: Jarod Wilson 
> Signed-off-by: Stefan Richter 

Acked-by: Jarod Wilson 

-- 
Jarod Wilson
ja...@redhat.com

Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards

[Jarod Wilson]

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-de...@lists.sourceforge.net
> CC: Jarod Wilson 
> Signed-off-by: Stefan Richter 
> ---
>  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
ja...@redhat.com

Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"

[Jarod Wilson]

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
ja...@redhat.com

Re: [RFC PATCH 01/13] pinctrl: meson: Add GXL pinctrl definitions

[Linus Walleij]

On Fri, Oct 21, 2016 at 4:40 PM, Neil Armstrong  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 

Looks good to me. Tell me when I may apply it, it looks orthogonal
to the rest of the patches.

Yours,
Linus Walleij

[PATCH net] udp: fix IP_CHECKSUM handling

[Eric Dumazet]

From: Eric Dumazet 

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 
Cc: Sam Kumar 
Cc: Willem de Bruijn 
---
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), );
 }
@@ -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);

linux-next: manual merge of the net-next tree with the net tree

[Stephen Rothwell]

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..
--- 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,

Re: [PATCH net 1/1] net sched filters: fix notification of filter delete with proper handle

[Daniel Borkmann]

On 10/23/2016 05:35 PM, Jamal Hadi Salim wrote:

From: Jamal Hadi Salim 



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 
---
  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);

Re: pull request: bluetooth 2016-10-21

[David Miller]

From: Johan Hedberg 
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.

Re: [PATCH net-next] lwt: Remove unused len field

[David Miller]

From: Thomas Graf 
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 

Applied, thanks Thomas.

Re: [PATCH] ipv6: do not increment mac header when it's unset

[David Miller]

From: "Jason A. Donenfeld" 
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 

Applied, thanks.

Have fun playing with WireGuard.

Re: [PATCH net] net: fec: Call swap_buffer() prior to IP header alignment

[David Miller]

From: Fabio Estevam 
Date: Fri, 21 Oct 2016 09:34:29 -0200

> From: Fabio Estevam 
> 
> 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 
> Signed-off-by: Fabio Estevam 

Applied, thank you.

Re: [PATCH v2 net-next 1/1] driver: tun: Forbid to set IFF_TUN and IFF_TAP at the same time

[David Miller]

From: f...@ikuai8.com
Date: Fri, 21 Oct 2016 19:02:15 +0800

> From: Gao Feng 
> 
> 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 

We've allowed this for too long to start failing on it now, sorry.

Re: [PATCH] net: sctp, forbid negative length

[David Miller]

From: Jiri Slaby 
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 

Applied and queued up for -stable, thanks.

Re: [PATCH net 1/1] bnx2x: Use the correct divisor value for PHC clock readings.

[David Miller]

From: 
Date: Fri, 21 Oct 2016 02:09:17 -0400

> From: Sudarsana Reddy Kalluru 
> 
> 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 
> Signed-off-by: Sudarsana Reddy Kalluru 
> Signed-off-by: Yuval Mintz 

Applied, thanks.

Re: [PATCH net-next] net: allow to kill a task which waits net_mutex in copy_new_ns

[David Miller]

From: Andrei Vagin 
Date: Thu, 20 Oct 2016 19:45:43 -0700

> From: Andrey Vagin 
> 
> 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" 
> Cc: Eric W. Biederman 
> Signed-off-by: Andrei Vagin 

Applied, thanks.

Re: [PATCH net-next] net/sched: em_meta: Fix 'meta vlan' to correctly recognize zero VID frames

[David Miller]

From: Shmulik Ladkani 
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 

Applied, thanks.

Re: [patch net-next 0/6] mlxsw: Driver update

[David Miller]

From: Jiri Pirko 
Date: Fri, 21 Oct 2016 16:07:17 +0200

> Mostly cosmetics and small resource values management rewrite.

Series applied, thanks Jiri.

[PATCH net-next] flow_dissector: fix vlan tag handling

[Arnd Bergmann]

gcc warns about an uninitialized pointer dereference in the vlan
priority handling:

net/core/flow_dissector.c: In function '__skb_flow_dissect':
net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

As pointed out by Jiri Pirko, the variable is never actually used
without being initialized first as the only way it end up uninitialized
is with skb_vlan_tag_present(skb)==true, and that means it does not
get accessed.

However, the warning hints at some related issues that I'm addressing
here:

- the second check for the vlan tag is different from the first one
  that tests the skb for being NULL first, causing both the warning
  and a possible NULL pointer dereference that was not entirely fixed.
- The same patch that introduced the NULL pointer check dropped an
  earlier optimization that skipped the repeated check of the
  protocol type
- The local '_vlan' variable is referenced through the 'vlan' pointer
  but the variable has gone out of scope by the time that it is
  accessed, causing undefined behavior as the stack may have been
  overwritten.

Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
in a local variable allows the compiler to further optimize the
later check. With those changes, the warning also disappears.

Fixes: 3805a938a6c2 ("flow_dissector: Check skb for VLAN only if skb 
specified.")
Signed-off-by: Arnd Bergmann 
---

diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 44e6ba9d3a6b..17be1b66cc41 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -246,13 +246,10 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
case htons(ETH_P_8021AD):
case htons(ETH_P_8021Q): {
const struct vlan_hdr *vlan;
+   struct vlan_hdr _vlan;
+   bool vlan_tag_present = (skb && skb_vlan_tag_present(skb));
 
-   if (skb && skb_vlan_tag_present(skb))
-   proto = skb->protocol;
-
-   if (eth_type_vlan(proto)) {
-   struct vlan_hdr _vlan;
-
+   if (!vlan_tag_present || eth_type_vlan(skb->protocol)) {
vlan = __skb_header_pointer(skb, nhoff, sizeof(_vlan),
data, hlen, &_vlan);
if (!vlan)
@@ -270,7 +267,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
 
FLOW_DISSECTOR_KEY_VLAN,
 target_container);
 
-   if (skb_vlan_tag_present(skb)) {
+   if (vlan_tag_present) {
key_vlan->vlan_id = skb_vlan_tag_get_id(skb);
key_vlan->vlan_priority =
(skb_vlan_tag_get_prio(skb) >> 
VLAN_PRIO_SHIFT);

Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit

[Jamal Hadi Salim]

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

Re: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit

[Xin Long]

> 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, :)

[PATCH net] sctp: fix the panic caused by route update

[Xin Long]

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 
---
 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, >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

Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net

[Stephen Hemminger]

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?

[PATCH net] doc: update docbook annotations for socket and skb

[Stephen Hemminger]

From: Stephen Hemminger 

The skbuff and sock structure both had missing parameter annotation
values.

Signed-off-by: Stephen Hemminger 
---
 include/linux/skbuff.h | 1 +
 include/net/sock.h | 4 +++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 601258f..32810f2 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -936,6 +936,7 @@ struct sk_buff_fclones {
 
 /**
  * skb_fclone_busy - check if fclone is busy
+ * @sk: socket
  * @skb: buffer
  *
  * Returns true if skb is a fast clone, and its clone is not freed.
diff --git a/include/net/sock.h b/include/net/sock.h
index ebf75db..73c6b00 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -252,6 +252,7 @@ struct sock_common {
   *@sk_pacing_rate: Pacing rate (if supported by transport/packet 
scheduler)
   *@sk_max_pacing_rate: Maximum pacing rate (%SO_MAX_PACING_RATE)
   *@sk_sndbuf: size of send buffer in bytes
+  *@sk_padding: unused element for alignment
   *@sk_no_check_tx: %SO_NO_CHECK setting, set checksum in TX packets
   *@sk_no_check_rx: allow zero checksum in RX packets
   *@sk_route_caps: route capabilities (e.g. %NETIF_F_TSO)
@@ -302,7 +303,8 @@ struct sock_common {
   *@sk_backlog_rcv: callback to process the backlog
   *@sk_destruct: called at sock freeing time, i.e. when all refcnt == 0
   *@sk_reuseport_cb: reuseport group container
- */
+  *@sk_rcu: used during RCU grace period
+  */
 struct sock {
/*
 * Now struct inet_timewait_sock also uses sock_common, so please just
-- 
2.9.3

Re: [PATCH -next] net: dsa: mv88e6xxx: use setup_timer to simplify the code

[Andrew Lunn]

On Sat, Oct 22, 2016 at 02:28:00PM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Use setup_timer function instead of initializing timer with the function
> and data fields.
> 
> Signed-off-by: Wei Yongjun 

Reviewed-by: Andrew Lunn 

Andrew

Re: [PATCH net-next 1/9] alx: refactor descriptor allocation

[David Miller]

From: Tobias Regnery 
Date: Fri, 21 Oct 2016 12:49:44 +0200

> + txq->tpd = alx->descmem.virt + offset;
> + txq->tpd_dma = alx->descmem.dma + offset;

If all the crazy casting isn't necessary here...

> + rxq->rrd = (void *)((u8 *)alx->descmem.virt + offset);
> + rxq->rrd_dma = alx->descmem.dma + offset;
> + offset += sizeof(struct alx_rrd) * alx->rx_ringsz;
> +
> + rxq->rfd = (void *)((u8 *)alx->descmem.virt + offset);
> + rxq->rfd_dma = alx->descmem.dma + offset;
> + offset += sizeof(struct alx_rfd) * alx->rx_ringsz;

Then it certainly isn't necessary here either.

Void pointer arithmatic is very clearly defined as operating on byte
quantities, so the cast is not necessary for the arithmetic nor the
final pointer type.

[patch net-next] devlink: Prevent port_type_set() callback when it's not needed

[Jiri Pirko]

From: Elad Raz 

When a port_type_set() is been called and the new port type set is the same
as the old one, just return success.

Signed-off-by: Elad Raz 
Signed-off-by: Jiri Pirko 
---
 net/core/devlink.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/devlink.c b/net/core/devlink.c
index 1b50630..d2fd736 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -608,6 +608,8 @@ static int devlink_port_type_set(struct devlink *devlink,
if (devlink->ops && devlink->ops->port_type_set) {
if (port_type == DEVLINK_PORT_TYPE_NOTSET)
return -EINVAL;
+   if (port_type == devlink_port->type)
+   return 0;
err = devlink->ops->port_type_set(devlink_port, port_type);
if (err)
return err;
-- 
2.5.5

[PATCH net 1/1] net sched filters: fix notification of filter delete with proper handle

[Jamal Hadi Salim]

From: Jamal Hadi Salim 

Signed-off-by: Jamal Hadi Salim 
---
 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);
-- 
1.9.1

Fwd: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not return ENOMEM err back in sctp_packet_transmit

[Jamal Hadi Salim]

Sorry - I didnt mean to remove the mailing lists.
Please reply to this email instead.

cheers,
jamal

 Forwarded Message 
Subject: send/sendmsg ENOMEM errors WAS(Re: [PATCH net 6/6] sctp: not 
return ENOMEM err back in sctp_packet_transmit

Date: Sun, 23 Oct 2016 11:03:36 -0400
From: Jamal Hadi Salim 
To: Xin Long 
CC: Marcelo Ricardo Leitner , Vlad Yasevich 
, dan...@iogearbox.net, ga...@mojatatu.com, Brenda 
Butler , David Miller , 
linux-s...@vger.kernel.org , Michael Tuexen 
, Eric Dumazet 




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?

cheers,
jamal

On 16-09-08 05:44 AM, Xin Long wrote:

As David and Marcelo's suggestion, ENOMEM err shouldn't return back to
user in transmit path. Instead, sctp's retransmit would take care of
the chunks that fail to send because of ENOMEM.

This patch is only to do some release job when alloc_skb fails, not to
return ENOMEM back any more.

Besides, it also cleans up sctp_packet_transmit's err path, and fixes
some issues in err path:

 - It didn't free the head skb in nomem: path.
 - No need to check nskb in no_route: path.
 - It should goto err: path if alloc_skb fails for head.
 - Not all the NOMEMs should free nskb.

Signed-off-by: Xin Long 
---
 net/sctp/output.c | 47 ++-
 1 file changed, 22 insertions(+), 25 deletions(-)

diff --git a/net/sctp/output.c b/net/sctp/output.c
index 1934933..8f490ff 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -442,14 +442,14 @@ int sctp_packet_transmit(struct sctp_packet *packet, 
gfp_t gfp)
 * time. Application may notice this error.
 */
pr_err_once("Trying to GSO but underlying device doesn't 
support it.");
-   goto nomem;
+   goto err;
}
} else {
pkt_size = packet->size;
}
head = alloc_skb(pkt_size + MAX_HEADER, gfp);
if (!head)
-   goto nomem;
+   goto err;
if (gso) {
NAPI_GRO_CB(head)->last = head;
skb_shinfo(head)->gso_type = sk->sk_gso_type;
@@ -470,8 +470,12 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t 
gfp)
}
}
dst = dst_clone(tp->dst);
-   if (!dst)
-   goto no_route;
+   if (!dst) {
+   if (asoc)
+   IP_INC_STATS(sock_net(asoc->base.sk),
+IPSTATS_MIB_OUTNOROUTES);
+   goto nodst;
+   }
skb_dst_set(head, dst);

/* Build the SCTP header.  */
@@ -622,8 +626,10 @@ int sctp_packet_transmit(struct sctp_packet *packet, gfp_t 
gfp)
if (!gso)
break;

-   if (skb_gro_receive(, nskb))
+   if (skb_gro_receive(, nskb)) {
+   kfree_skb(nskb);
goto nomem;
+   }
nskb = NULL;
if (WARN_ON_ONCE(skb_shinfo(head)->gso_segs >=
 sk->sk_gso_max_segs))
@@ -717,18 +723,13 @@ int sctp_packet_transmit(struct sctp_packet *packet, 
gfp_t gfp)
}
head->ignore_df = packet->ipfragok;
tp->af_specific->sctp_xmit(head, tp);
+   goto out;

-out:
-   sctp_packet_reset(packet);
-   return err;
-no_route:
-   kfree_skb(head);
-   if (nskb != head)
-   kfree_skb(nskb);
-
-   if (asoc)
-   IP_INC_STATS(sock_net(asoc->base.sk), IPSTATS_MIB_OUTNOROUTES);
+nomem:
+   if (packet->auth && list_empty(>auth->list))
+   sctp_chunk_free(packet->auth);

+nodst:
/* FIXME: Returning the 'err' will effect all the associations
 * associated with a socket, although only one of the paths of the
 * association is unreachable.
@@ -737,22 +738,18 @@ no_route:
 * required.
 */
 /* err = -EHOSTUNREACH; */
-err:
-   /* Control chunks are unreliable so just drop 

Re: [PATCH net] sched, cls: don't dump kernel addr into tc monitors on delete event

[Jamal Hadi Salim]

On 16-10-18 07:14 PM, Cong Wang wrote:

On Tue, Oct 18, 2016 at 2:21 PM, Jamal Hadi Salim  wrote:

I was sitting on this patch I was going to send ;->
Does this resolve it?


Your patch makes more sense to me. Maybe we can remove the
event != RTM_DELTFILTER special case too?



We cant entirely get rid of that. Events other than
deletion require that a dump follows.
Probably what you mean is:
We could remove extra line inside "if (RTM_DELTFILTER != event)"
which does "tcm->tcm_handle = 0;"
It would be more reasonable to actually audit the callers of
tcf_fill_node() and make sure they pass the correct fh.

In any case, can we make that a followup - because this is a bug
fix?
I will send it and you could still comment if you dont find that
sufficient.

cheers,
jamal

[PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards

[Stefan Richter]

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-de...@lists.sourceforge.net
CC: Jarod Wilson 
Signed-off-by: Stefan Richter 
---
 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;
net->min_mtu = ETH_MIN_MTU;
net->max_mtu = ETH_MAX_MTU;
 
-- 
Stefan Richter
-==- =-=- =-===
http://arcgraph.de/sr/

[PATCH net-next 1/2] firewire: net: fix maximum possible MTU

[Stefan Richter]

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-de...@lists.sourceforge.net
CC: Jarod Wilson 
Signed-off-by: Stefan Richter 
---
 drivers/firewire/net.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/firewire/net.c b/drivers/firewire/net.c
index 8430222151fc..99379542b263 100644
--- a/drivers/firewire/net.c
+++ b/drivers/firewire/net.c
@@ -1467,10 +1467,11 @@ static int fwnet_probe(struct fw_unit *unit,
 * Use the RFC 2734 default 1500 octets or the maximum payload
 * as initial MTU
 */
-   net->max_mtu = (1 << (card->max_receive + 1))
-  - sizeof(struct rfc2734_header) - IEEE1394_GASP_HDR_SIZE;
-   net->mtu = min(1500U, net->max_mtu);
+   net->mtu = min(1500U,
+  (1U << (card->max_receive + 1))
+  - RFC2374_FRAG_HDR_SIZE - IEEE1394_GASP_HDR_SIZE);
net->min_mtu = ETH_MIN_MTU;
+   net->max_mtu = ETH_MAX_MTU;
 
/* Set our hardware address while we're at it */
ha = (union fwnet_hwaddr *)net->dev_addr;
-- 
Stefan Richter
-==- =-=- =-===
http://arcgraph.de/sr/

Re: [RFC 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.

[Rangankar, Manish]

On 19/10/16 3:32 PM, "Johannes Thumshirn"  wrote:

>On Wed, Oct 19, 2016 at 01:01:10AM -0400, manish.rangan...@cavium.com
>wrote:
>> From: Manish Rangankar 
>> 
>> The QLogic FastLinQ Driver for iSCSI (qedi) is the iSCSI specific module
>> for 41000 Series Converged Network Adapters by QLogic.
>> 
>> This patch consists of following changes:
>>   - MAINTAINERS Makefile and Kconfig changes for qedi,
>>   - PCI driver registration,
>>   - iSCSI host level initialization,
>>   - Debugfs and log level infrastructure.
>> 
>> Signed-off-by: Nilesh Javali 
>> Signed-off-by: Adheer Chandravanshi 
>> Signed-off-by: Chad Dupuis 
>> Signed-off-by: Saurav Kashyap 
>> Signed-off-by: Arun Easi 
>> Signed-off-by: Manish Rangankar 
>> ---
>
>[...]
>
>> +/* MSI-X fastpath handler code */
>> +static irqreturn_t qedi_msix_handler(int irq, void *dev_id)
>> +{
>> +struct qedi_fastpath *fp = dev_id;
>> +struct qedi_ctx *qedi = fp->qedi;
>> +bool wake_io_thread = true;
>> +
>> +qed_sb_ack(fp->sb_info, IGU_INT_DISABLE, 0);
>> +
>> +process_again:
>> +wake_io_thread = qedi_process_completions(fp);
>> +if (wake_io_thread) {
>> +QEDI_INFO(>dbg_ctx, QEDI_LOG_DISC,
>> +  "process already running\n");
>> +}
>> +
>> +if (qedi_fp_has_work(fp) == 0)
>> +qed_sb_update_sb_idx(fp->sb_info);
>> +
>> +/* Check for more work */
>> +rmb();
>> +
>> +if (qedi_fp_has_work(fp) == 0)
>> +qed_sb_ack(fp->sb_info, IGU_INT_ENABLE, 1);
>> +else
>> +goto process_again;
>> +
>> +return IRQ_HANDLED;
>> +}
>
>You might want to consider workqueues here.

If there is no serious objection with current per-cpu threads
implementation
then we will like to do workqueue changes just after first submission.
This is because, 
for this change we have go through complete validation cycle on our part.


Thanks,
Manish R.

Re: [PATCH v4 01/10] ethernet: add sun8i-emac driver

[Rami Rosen]

Hi Corentin,


Trivial comment: rx_saf_fai and rx_daf_fail are not used. This implies that also
rx_saf_error and rx_daf_error should be removed:

> +static const char const estats_str[][ETH_GSTRING_LEN] = {
...
> +   "rx_header_error",
> +   "rx_overflow_error",
> +   "rx_saf_error",
> +   "rx_daf_error",
> +   "rx_buf_error",
...

> +
> +struct sun8i_emac_stats {
> +   u64 rx_payload_error;
...
> +   u64 rx_overflow_error;
> +   u64 rx_saf_fail;
> +   u64 rx_daf_fail;

> +   u64 tx_used_desc;
> +   u64 napi_schedule;
> +   u64 napi_underflow;
> +};
> +

Trivial: typo, should be: can transfer

> +/* The datasheet said that each descriptor can transfers up to 4096bytes
> + * But latter, a register documentation reduce that value to 2048

Regards,
Rami Rosen

Re: [PATCH v4 01/10] ethernet: add sun8i-emac driver

[LABBE Corentin]

On Fri, Oct 07, 2016 at 08:02:39AM -0700, Joe Perches wrote:
> On Fri, 2016-10-07 at 10:25 +0200, Corentin Labbe wrote:
> > This patch add support for sun8i-emac ethernet MAC hardware.
> > It could be found in Allwinner H3/A83T/A64 SoCs.
> 
> trivial notes:
> 
> > diff --git a/drivers/net/ethernet/allwinner/sun8i-emac.c 
> > b/drivers/net/ethernet/allwinner/sun8i-emac.c
> []
> > +static const char const estats_str[][ETH_GSTRING_LEN] = {
> 
> one too many const
> 
> > +/* MAGIC value for knowing if a descriptor is available or not */
> > +#define DCLEAN cpu_to_le32(BIT(16) | BIT(14) | BIT(12) | BIT(10) | BIT(9))
> 
> Aren't there #defines for these bits?
> 
> > +static void sun8i_emac_flow_ctrl(struct sun8i_emac_priv *priv, int duplex,
> > +int fc)
> > +{
> > +   u32 flow = 0;
> > +
> > +   flow = readl(priv->base + EMAC_RX_CTL0);
> > +   if (fc & EMAC_FLOW_RX)
> > +   flow |= BIT(16);
> > +   else
> > +   flow &= ~BIT(16);
> > +   writel(flow, priv->base + EMAC_RX_CTL0);
> > +
> > +   flow = readl(priv->base + EMAC_TX_FLOW_CTL);
> > +   if (fc & EMAC_FLOW_TX)
> > +   flow |= BIT(0);
> > +   else
> > +   flow &= ~BIT(0);
> 
> more magic bits that could be #defines
> 
> > +static int sun8i_emac_rx_from_ddesc(struct net_device *ndev, int i)
> > +{
> > []
> > +   /* the checksum or length of received frame's payload is wrong*/
> > +   if (dstatus & BIT(0)) {
> []
> > +   if (dstatus & BIT(1)) {
> []
> > +   if ((dstatus & BIT(3))) {
> 
> etc...

Thanks for the review, I will fix all thoses issue.

Regards
Corentin Labbe

Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"

[Sven Eckelmann]

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.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v7] net: ip, diag -- Add diag interface for raw sockets

[Cyrill Gorcunov]

On Sat, Oct 22, 2016 at 06:55:27PM -0400, David Miller wrote:
> From: Cyrill Gorcunov 
> Date: Fri, 21 Oct 2016 13:03:44 +0300
> 
> > In criu we are actively using diag interface to collect sockets
> > present in the system when dumping applications. And while for
> > unix, tcp, udp[lite], packet, netlink it works as expected,
> > the raw sockets do not have. Thus add it.
> 
> Applied, thanks.

Thanks to all for extensive comments and review!