* Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better
From: Johannes Berg @ 2017-01-11 15:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-wireless, David S. Miller, Networking, linux-kernel
In-Reply-To: <CAK8P3a2mOT=BG=9yxJ1e-q__5FYq6dfF3t3bT1vqcgFaQAUjog@mail.gmail.com>
On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote:
> On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote:
> > > This works fine here because iwe->u.data.length is guaranteed to
> > > be
> > > NULL, and the memcpy doesn't actually have an effect.
> >
> > I think you mean 0, not NULL, but I can fix that when I apply it.
>
> Right, thanks!
Applied. Also fixed the typo in the subject :)
johannes
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 15:06 UTC (permalink / raw)
To: David Miller, alexandre.torgue
Cc: Joao.Pinto, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <20170111.095256.1057845755758556047.davem@davemloft.net>
Hello David,
Às 2:52 PM de 1/11/2017, David Miller escreveu:
> From: Alexandre Torgue <alexandre.torgue@st.com>
> Date: Wed, 11 Jan 2017 12:39:09 +0100
>
>> Let's see what David think about that but if there no risk of backward
>> compatibility with DT, I agree with the series.
>
> I really am generally against driver renames. The only potentially
> make new users happy, but can only negatively impact existing users.
>
> The new name is not terribly appropriate either, it is using the name
> of the manufacturer rather than referring to a chipset or a class or
> chipsets.
stmmac is in fact a bundle of Synopsys Ethernet IPs. We can go with Jie'
suggestion a include all the Ips it supports like "Synopsys 10M/100M/1G/eQOS
Ethernet Drivers".
>
> I don't see what the big deal is in leaving the name as 'stmmac' and
> in a way leaving it alone shows respect for the people who have worked
> on and cared for the stmmac driver for all of these years.
I have a huge respect for STMicroelectronics and above all respect for the
developers that work hard to put things working properly and care for it, and
that's why before starting developing I had a discussion with stmmac maintainers
in order to align with them. From me you can only expect collaboration, help and
dedication, since Linux is for common good right, or at least I believe so.
Another thing to point is that I wish that Alexandre and Peppe remain
maintainers since they are doing an excelent job.
The goal of this work is to improve code organization and future merge of other
Synopsys Ethernet IP driver that will be able to merge into this "synopsys
driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
stmmac.
Thanks.
Joao
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] phy: marvell: Add support for temperature sensor
From: Andrew Lunn @ 2017-01-11 15:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <1484096604-25033-2-git-send-email-andrew@lunn.ch>
> +static int marvell_hwmon_probe(struct phy_device *phydev,
> + const struct hwmon_chip_info *chip)
> +{
> + struct marvell_priv *priv = phydev->priv;
> + struct device *dev = &phydev->mdio.dev;
> + int err;
> +
> + err = marvell_hwmon_name(phydev);
> + if (err)
> + return err;
> +
> + priv->hwmon_dev = devm_hwmon_device_register_with_info(
> + dev, priv->hwmon_name, phydev, chip, NULL);
> +
> + if (IS_ERR(priv->hwmon_dev))
> + return PTR_ERR(priv->hwmon_dev);
> +
> + return 0;
> +}
0-day has pointed out this can be simplified to just
return PTR_ERR(priv->hwmon_dev);
I will submit a v2 in a couple of days, when others have had chance to
comment.
Andrew
^ permalink raw reply
* RE: [PATCH v2 8/8] crypto/testmgr: Allocate only the required output size for hash tests
From: David Laight @ 2017-01-11 15:13 UTC (permalink / raw)
To: 'Andy Lutomirski', Daniel Borkmann, Netdev, LKML,
Linux Crypto Mailing List
Cc: Jason A. Donenfeld, Hannes Frederic Sowa, Alexei Starovoitov,
Eric Dumazet, Eric Biggers, Tom Herbert, David S. Miller,
Ard Biesheuvel, Herbert Xu
In-Reply-To: <890f4bdb28a1cf72f6b802b220b35ebaf0f76bb9.1484090585.git.luto@kernel.org>
From: Andy Lutomirski
> Sent: 10 January 2017 23:25
> There are some hashes (e.g. sha224) that have some internal trickery
> to make sure that only the correct number of output bytes are
> generated. If something goes wrong, they could potentially overrun
> the output buffer.
>
> Make the test more robust by allocating only enough space for the
> correct output size so that memory debugging will catch the error if
> the output is overrun.
Might be better to test this by allocating an overlong buffer
and then explicitly checking that the output hasn't overrun
the allowed space.
If nothing else the error message will be clearer.
David
^ permalink raw reply
* Re: net: ti: cpsw-phy-sel: RGMII is not working on AM335x
From: Andrew Lunn @ 2017-01-11 15:14 UTC (permalink / raw)
To: Teresa Remmet
Cc: Alexandru Gagniuc, David S. Miller, Mugunthan V N,
Grygorii Strashko, linux-omap, netdev
In-Reply-To: <1484122463.3777.1.camel@phytec.de>
> So I wonder what is correct now? As for me the patch makes RGMII unusable.
> Has anyone an explanation?
Hi Teresa
In your device tree, what phy-mode do you have?
And does your hardware require an RGMII delay in order that it works?
Andrew
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Jason Baron @ 2017-01-11 15:14 UTC (permalink / raw)
To: Christoph Paasch; +Cc: netdev, Eric Dumazet
In-Reply-To: <20170111051708.GC23178@Chimay.local>
On 01/11/2017 12:17 AM, Christoph Paasch wrote:
> Hello Jason,
>
> (resending as Gmail sent out with HTML)
>
> On 05/01/17 - 16:33:28, Jason Baron wrote:
>> Using a Mac OSX box as a client connecting to a Linux server, we have found
>> that when certain applications (such as 'ab'), are abruptly terminated
>> (via ^C), a FIN is sent followed by a RST packet on tcp connections. The
>> FIN is accepted by the Linux stack but the RST is sent with the same
>> sequence number as the FIN, and Linux responds with a challenge ACK per
>> RFC 5961. The OSX client then does not reply with any RST as would be
>> expected on a closed socket.
>
> do you see this behavior consistently, even in a controlled environment?
>
> The problem seems rather to be that after the first RST, the NAT on the path
> has dropped its mapping and is thus dropping all other traffic. So, Linux's
> challenge-ack does not go through to the OSX-host to "re-synchronize" the
> state (which would allow OSX to send a RST with the updated sequence numbers).
>
> This is also documented in RFC5961:
>
> 9.3. Middleboxes That Drop the Challenge ACK
>
> It also needs to be noted that, some middleboxes (Firewalls/NATs)
> that don't have the fix recommended in the document, may drop the
> challenge ACK. This can happen because, the original RST segment
> that was in window had already cleared the flow state pertaining to
> the TCP connection in the middlebox. In such cases, the end hosts
> that have implemented the RST mitigation described in this document,
> will have the TCP connection left open. This is a corner case and
> can go away if the middlebox is conformant with the changes proposed
> in this document.
>
Yes, I've observed a couple of different ways that this can happen:
1) The case where Mac OSX does not send an RST in response to the
challenge ACK. I found that there is actually a rate limit to the number
of 'RSTs' that Mac OSX will send on a closed socket. Its
controlled by: 'net.inet.icmp.icmplim'. By default its set to 250, which
means it will send up to 250 'RSTs' on closed sockets per second. Thus,
I've confirmed that I can hit this limit by looking in the Mac OSX logs.
2) When I had the Mac OSX box connecting over a vpn to the linux server
I found that while the challenge ack sent by Linux did reach the Mac OSX
box, the RST that Mac OSX sent could get dropped somewhere in between.
That is I see it sent from the Mac OSX box but never see it received by
the Linux server. Thus, this is closer to the scenario you described above.
Also, as mentioned we've had this deployed in production where we've
seen this change make a real difference in capacity (due to freeing up
memory resources much more quickly). Since, I don't have dumps from the
client side I can't say exactly what the sequence of events is there.
Thanks,
-Jason
>
>
> Cheers,
> Christoph
>
>>
>> This results in sockets accumulating on the Linux server left mostly in
>> the CLOSE_WAIT state, although LAST_ACK and CLOSING are also possible.
>> This sequence of events can tie up a lot of resources on the Linux server
>> since there may be a lot of data in write buffers at the time of the RST.
>> Accepting a RST equal to rcv_nxt - 1, after we have already successfully
>> processed a FIN, has made a significant difference for us in practice, by
>> freeing up unneeded resources in a more expedient fashion.
>>
>> I also found a posting that the iOS client behaves in a similar manner here
>> (it will send a FIN followed by a RST for rcv_nxt - 1):
>> https://www.snellman.net/blog/archive/2016-02-01-tcp-rst/
>>
>> A packetdrill test demonstrating the behavior.
>>
>> // testing mac osx rst behavior
>>
>> // Establish a connection
>> 0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>> 0.000 bind(3, ..., ...) = 0
>> 0.000 listen(3, 1) = 0
>>
>> 0.100 < S 0:0(0) win 32768 <mss 1460,nop,wscale 10>
>> 0.100 > S. 0:0(0) ack 1 <mss 1460,nop,wscale 5>
>> 0.200 < . 1:1(0) ack 1 win 32768
>> 0.200 accept(3, ..., ...) = 4
>>
>> // Client closes the connection
>> 0.300 < F. 1:1(0) ack 1 win 32768
>>
>> // now send rst with same sequence
>> 0.300 < R. 1:1(0) ack 1 win 32768
>>
>> // make sure we are in TCP_CLOSE
>> 0.400 %{
>> assert tcpi_state == 7
>> }%
>>
>> Signed-off-by: Jason Baron <jbaron@akamai.com>
>> ---
>> net/ipv4/tcp_input.c | 23 ++++++++++++++++++++++-
>> 1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index ec6d84363024..373bea05c93b 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -5249,6 +5249,24 @@ static int tcp_copy_to_iovec(struct sock *sk, struct sk_buff *skb, int hlen)
>> return err;
>> }
>>
>> +/* Accept RST for rcv_nxt - 1 after a FIN.
>> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
>> + * FIN is sent followed by a RST packet. The RST is sent with the same
>> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
>> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
>> + * with a RST on the closed socket, hence accept this class of RSTs.
>> + */
>> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
>> +{
>> + struct tcp_sock *tp = tcp_sk(sk);
>> +
>> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
>> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
>> + (sk->sk_state == TCP_CLOSE_WAIT ||
>> + sk->sk_state == TCP_LAST_ACK ||
>> + sk->sk_state == TCP_CLOSING));
>> +}
>> +
>> /* Does PAWS and seqno based validation of an incoming segment, flags will
>> * play significant role here.
>> */
>> @@ -5287,6 +5305,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
>> LINUX_MIB_TCPACKSKIPPEDSEQ,
>> &tp->last_oow_ack_time))
>> tcp_send_dupack(sk, skb);
>> + } else if (tcp_reset_check(sk, skb)) {
>> + tcp_reset(sk);
>> }
>> goto discard;
>> }
>> @@ -5300,7 +5320,8 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
>> * else
>> * Send a challenge ACK
>> */
>> - if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt) {
>> + if (TCP_SKB_CB(skb)->seq == tp->rcv_nxt ||
>> + tcp_reset_check(sk, skb)) {
>> rst_seq_match = true;
>> } else if (tcp_is_sack(tp) && tp->rx_opt.num_sacks > 0) {
>> struct tcp_sack_block *sp = &tp->selective_acks[0];
>> --
>> 2.6.1
>>
^ permalink raw reply
* Re: 4.9.2 panic, __skb_flow_dissect, gro?
From: Ian Kumlien @ 2017-01-11 15:19 UTC (permalink / raw)
To: David Miller; +Cc: Denys Fedoryshchenko, Linux Kernel Network Developers
In-Reply-To: <20170110.200804.303728442314129894.davem@davemloft.net>
On Wed, Jan 11, 2017 at 2:08 AM, David Miller <davem@davemloft.net> wrote:
> From: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
> Date: Wed, 11 Jan 2017 01:49:34 +0200
>
>> It seems this patch solve issue. I hope it will go to stable asap,
>> because without it loaded routers crashing almost instantly on 4.9.
>
> I will submit this soon.
Btw, any special reason why that code is written like it is? Stack depth?
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: David Miller @ 2017-01-11 15:20 UTC (permalink / raw)
To: Joao.Pinto
Cc: alexandre.torgue, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <329b0d8c-4cda-7238-c229-d69ac251f26b@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Wed, 11 Jan 2017 15:06:55 +0000
> The goal of this work is to improve code organization and future merge of other
> Synopsys Ethernet IP driver that will be able to merge into this "synopsys
> driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
> stmmac.
Then I want to see an ACK from Alexandre and Peppe for this renaming
patch set.
^ permalink raw reply
* [PATCH v2] vxlan: Set ports in flow key when doing route lookups
From: Martynas Pumputis @ 2017-01-11 15:18 UTC (permalink / raw)
To: davem; +Cc: netdev, Martynas Pumputis
In-Reply-To: <20170110.211004.1712612611986550798.davem@davemloft.net>
Otherwise, a xfrm policy with sport/dport being set cannot be matched.
Signed-off-by: Martynas Pumputis <martynas@weave.works>
---
Changes in v2:
- Set the source port in the flow key.
drivers/net/vxlan.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index bb70dd5..ca7196c 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -1798,7 +1798,7 @@ static int vxlan_build_skb(struct sk_buff *skb, struct dst_entry *dst,
static struct rtable *vxlan_get_route(struct vxlan_dev *vxlan, struct net_device *dev,
struct vxlan_sock *sock4,
struct sk_buff *skb, int oif, u8 tos,
- __be32 daddr, __be32 *saddr,
+ __be32 daddr, __be32 *saddr, __be16 dport, __be16 sport,
struct dst_cache *dst_cache,
const struct ip_tunnel_info *info)
{
@@ -1824,6 +1824,8 @@ static struct rtable *vxlan_get_route(struct vxlan_dev *vxlan, struct net_device
fl4.flowi4_proto = IPPROTO_UDP;
fl4.daddr = daddr;
fl4.saddr = *saddr;
+ fl4.fl4_dport = dport;
+ fl4.fl4_sport = sport;
rt = ip_route_output_key(vxlan->net, &fl4);
if (likely(!IS_ERR(rt))) {
@@ -1851,6 +1853,7 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
__be32 label,
const struct in6_addr *daddr,
struct in6_addr *saddr,
+ __be16 dport, __be16 sport,
struct dst_cache *dst_cache,
const struct ip_tunnel_info *info)
{
@@ -1877,6 +1880,8 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan,
fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label);
fl6.flowi6_mark = skb->mark;
fl6.flowi6_proto = IPPROTO_UDP;
+ fl6.fl6_dport = dport;
+ fl6.fl6_sport = sport;
err = ipv6_stub->ipv6_dst_lookup(vxlan->net,
sock6->sock->sk,
@@ -2068,6 +2073,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
rdst ? rdst->remote_ifindex : 0, tos,
dst->sin.sin_addr.s_addr,
&src->sin.sin_addr.s_addr,
+ dst_port, src_port,
dst_cache, info);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
@@ -2104,6 +2110,7 @@ static void vxlan_xmit_one(struct sk_buff *skb, struct net_device *dev,
rdst ? rdst->remote_ifindex : 0, tos,
label, &dst->sin6.sin6_addr,
&src->sin6.sin6_addr,
+ dst_port, src_port,
dst_cache, info);
if (IS_ERR(ndst)) {
err = PTR_ERR(ndst);
@@ -2430,7 +2437,7 @@ static int vxlan_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
rt = vxlan_get_route(vxlan, dev, sock4, skb, 0, info->key.tos,
info->key.u.ipv4.dst,
- &info->key.u.ipv4.src, NULL, info);
+ &info->key.u.ipv4.src, dport, sport, NULL, info);
if (IS_ERR(rt))
return PTR_ERR(rt);
ip_rt_put(rt);
@@ -2441,7 +2448,7 @@ static int vxlan_fill_metadata_dst(struct net_device *dev, struct sk_buff *skb)
ndst = vxlan6_get_route(vxlan, dev, sock6, skb, 0, info->key.tos,
info->key.label, &info->key.u.ipv6.dst,
- &info->key.u.ipv6.src, NULL, info);
+ &info->key.u.ipv6.src, dport, sport, NULL, info);
if (IS_ERR(ndst))
return PTR_ERR(ndst);
dst_release(ndst);
--
2.10.2
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2017-01-11 15:22 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Fix rtlwifi crash, from Larry Finger.
2) Memory disclosure in appletalk ipddp routing code, from
Vlad Tsyrklevich.
3) r8152 can erroneously split an RX packet into multiple URBs if the
Rx FIFO is not empty when we suspend. Fix this by waiting for the
FIFO to empty before suspending. From Hayes Wang.
4) Two GRO fixes (enter slow path when not enough SKB tail room exists,
disable frag0 optimizations when there are IPV6 extension headers)
from Eric Dumazet and Herbert Xu.
5) A series of mlx5e bug fixes (do source udp port offloading for
tunnels properly, Ip fragment matching fixes, handling firmware
errors properly when installing TC rules, etc.) from Saeed
Mahameed, Or Gerlitz, Roi Dayan, Hadar Hen Zion, Gil Rockah, and
Daniel Jurgens.
6) Two VRF fixes from David Ahern (don't skip multipath selection for VRF
paths, disallow VRF to be configured with table ID 0).
Please pull, thanks a lot!
The following changes since commit c92f5bdc4b9ba509a93f9e386fbb1fa779d4b0d6:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-01-09 11:58:28 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 24c63bbc18e25d5d8439422aa5fd2d66390b88eb:
net: vrf: do not allow table id 0 (2017-01-11 10:04:01 -0500)
----------------------------------------------------------------
Alexander Alemayhu (1):
ipv6: fix typos
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Anna, Suman (1):
net: add the AF_QIPCRTR entries to family name tables
Arnd Bergmann (1):
cgroup: move CONFIG_SOCK_CGROUP_DATA to init/Kconfig
Colin Ian King (1):
sctp: Fix spelling mistake: "Atempt" -> "Attempt"
Daniel Jurgens (1):
net/mlx5: Only cancel recovery work when cleaning up device
David Ahern (2):
net: ipv4: Fix multipath selection with vrf
net: vrf: do not allow table id 0
David S. Miller (3):
Merge tag 'wireless-drivers-for-davem-2017-01-10' of git://git.kernel.org/.../kvalo/wireless-drivers
Merge branch 'r8152-fix-autosuspend'
Merge branch 'mlx5-fixes'
Eric Dumazet (3):
tcp: do not export tcp_peer_is_proven()
net: skb_flow_get_be16() can be static
gro: use min_t() in skb_gro_reset_offset()
Florian Fainelli (1):
net: dsa: Ensure validity of dst->ds[0]
Gil Rockah (1):
net/mlx5e: Remove WARN_ONCE from adaptive moderation code
Hadar Hen Zion (1):
net/mlx5e: Fix kbuild warnings for uninitialized parameters
Herbert Xu (2):
gro: Enter slow-path if there is no tailroom
gro: Disable frag0 optimization on IPv6 ext headers
Jean Delvare (1):
net: phy: Add Meson GXL PHY hardware dependency
Julian Wiedmann (1):
net/af_iucv: don't use paged skbs for TX on HiperSockets
Larry Finger (1):
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
Martin KaFai Lau (1):
mlx4: Return EOPNOTSUPP instead of ENOTSUPP
Or Gerlitz (6):
net/mlx5e: Properly handle offloading of source udp port for IP tunnels
net/mlx5e: Warn when rejecting offload attempts of IP tunnels
net/mlx5e: TC ipv4 tunnel encap offload error flow fixes
net/mlx5e: Properly get address type of encapsulation IP headers
net/mlx5e: Set inline mode requirements for matching on IP fragments
net/mlx5e: Properly handle FW errors while adding TC rules
Pavel Tikhomirov (1):
ipv4: make tcp_notsent_lowat sysctl knob behave as true unsigned int
Russell King (1):
net: phy: marvell: fix Marvell 88E1512 used in SGMII mode
Saeed Mahameed (1):
net/mlx5e: Un-register uplink representor on nic_disable
Stephen Boyd (1):
net: qrtr: Mark 'buf' as little endian
Tobias Klauser (1):
net: socket: Make unnecessarily global sockfs_setattr() static
Vlad Tsyrklevich (1):
net/appletalk: Fix kernel memory disclosure
Zefir Kurtisi (1):
phy state machine: failsafe leave invalid RUNNING state
hayeswang (2):
r8152: split rtl8152_suspend function
r8152: fix rx issue for runtime suspend
drivers/net/appletalk/ipddp.c | 2 +-
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 13 +++++------
drivers/net/ethernet/mellanox/mlx5/core/en_rx_am.c | 7 +-----
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------
drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 +++--
drivers/net/phy/Kconfig | 1 +
drivers/net/phy/marvell.c | 3 ++-
drivers/net/phy/phy.c | 9 ++++++++
drivers/net/usb/r8152.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++--------------
drivers/net/vrf.c | 4 ++++
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++++++++++++++++++++---------------
drivers/net/wireless/intersil/orinoco/mic.h | 3 ++-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 ++--
drivers/net/wireless/realtek/rtlwifi/usb.c | 1 +
include/linux/netdevice.h | 9 ++++++--
init/Kconfig | 4 ++++
net/Kconfig | 4 ----
net/core/dev.c | 4 +++-
net/core/flow_dissector.c | 4 ++--
net/core/sock.c | 6 ++---
net/dsa/dsa2.c | 11 +++++----
net/ipv4/fib_semantics.c | 9 ++++++--
net/ipv4/sysctl_net_ipv4.c | 2 +-
net/ipv4/tcp_metrics.c | 1 -
net/ipv6/ip6_offload.c | 1 +
net/ipv6/route.c | 4 ++--
net/iucv/af_iucv.c | 25 ++++++++++++---------
net/qrtr/qrtr.c | 4 ++--
net/sctp/outqueue.c | 2 +-
net/socket.c | 2 +-
31 files changed, 243 insertions(+), 121 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next 5/6] bnxt_en: Pass RoCE app priority to firmware.
From: David Miller @ 2017-01-11 15:46 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1484097159-21575-6-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Tue, 10 Jan 2017 20:12:38 -0500
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
> index 35a0d28..f2630cc 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.h
> @@ -36,6 +36,9 @@ struct bnxt_cos2bw_cfg {
>
> #define HWRM_STRUCT_DATA_SUBTYPE_HOST_OPERATIONAL 0x0300
>
> +#define ETH_P_ROCE 0x8915
There's also a similar define in the qedr infiniband driver, this doesn't
make much sense.
Please add this to if_ether.h, and reference it from there in the drivers.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] tcp: accept RST for rcv_nxt - 1 after receiving a FIN
From: Eric Dumazet @ 2017-01-11 15:48 UTC (permalink / raw)
To: Jason Baron; +Cc: netdev
In-Reply-To: <1483652008-20255-1-git-send-email-jbaron@akamai.com>
On Thu, 2017-01-05 at 16:33 -0500, Jason Baron wrote:
>
> +/* Accept RST for rcv_nxt - 1 after a FIN.
> + * When tcp connections are abruptly terminated from Mac OSX (via ^C), a
> + * FIN is sent followed by a RST packet. The RST is sent with the same
> + * sequence number as the FIN, and thus according to RFC 5961 a challenge
> + * ACK should be sent. However, Mac OSX does not reply to the challenge ACK
> + * with a RST on the closed socket, hence accept this class of RSTs.
> + */
> +static bool tcp_reset_check(struct sock *sk, struct sk_buff *skb)
const struct sock *sk, const struct sk_buff *skb
> +{
> + struct tcp_sock *tp = tcp_sk(sk);
> +
> + return unlikely((TCP_SKB_CB(skb)->seq == (tp->rcv_nxt - 1)) &&
> + (TCP_SKB_CB(skb)->end_seq == (tp->rcv_nxt - 1)) &&
Why is the test on end_seq needed ?
> + (sk->sk_state == TCP_CLOSE_WAIT ||
> + sk->sk_state == TCP_LAST_ACK ||
> + sk->sk_state == TCP_CLOSING));
> +}
Testing many states can be done more efficiently :
(1 << sk->sk_state) & (TCPF_CLOSE_WAIT | TCPF_LAST_ACK |
TCPF_CLOSING)
Thanks
^ permalink raw reply
* Re: [PATCH v2] net: netcp: correct netcp_get_stats function signature
From: David Miller @ 2017-01-11 15:48 UTC (permalink / raw)
To: j-keerthy
Cc: w-kwok2, m-karicheri2, netdev, linux-kernel, stephen, m-scherban
In-Reply-To: <1484105609-8647-1-git-send-email-j-keerthy@ti.com>
From: Keerthy <j-keerthy@ti.com>
Date: Wed, 11 Jan 2017 09:03:29 +0530
> Commit: bc1f44709cf2 - net: make ndo_get_stats64 a void function
> and
> Commit: 6a8162e99ef3 - net: netcp: store network statistics in 64 bits.
>
> The commit 6a8162e99ef3 adds ndo_get_stats64 function as per old
> signature which causes compilation error:
>
> drivers/net/ethernet/ti/netcp_core.c:1951:28: error:
> initialization from incompatible pointer type
> .ndo_get_stats64 = netcp_get_stats,
>
> Hence correct netcp_get_stats function signature as per
> the latest definition.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> Fixes: 6a8162e99ef344fc("net: netcp: store network statistics in 64 bits")
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: thunderx: Make hfunc variable const type in nicvf_set_rxfh()
From: David Miller @ 2017-01-11 15:51 UTC (permalink / raw)
To: rrichter; +Cc: sgoutham, rric, netdev
In-Reply-To: <20170111091702.6343-1-rrichter@cavium.com>
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Jan 2017 10:17:02 +0100
> @@ -635,7 +635,7 @@ static int nicvf_get_rxfh(struct net_device *dev, u32 *indir, u8 *hkey,
> }
>
> static int nicvf_set_rxfh(struct net_device *dev, const u32 *indir,
> - const u8 *hkey, u8 hfunc)
> + const u8 *hkey, const u8 hfunc)
Please do not change the indentation, it is currently correct.
^ permalink raw reply
* Re: [PATCH] bnxt_en: hide unused bnxt_get_max_func_{vnics,rss_ctxs} functions
From: David Miller @ 2017-01-11 15:51 UTC (permalink / raw)
To: arnd
Cc: michael.chan, prashant.sreedharan, sbaddipa, aduyck, netdev,
linux-kernel
In-Reply-To: <20170111143619.502495-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 11 Jan 2017 15:36:09 +0100
> There are lots of #ifdefs in this file, and a recent patch got one
> of them wrong, leading to a harmless warning in some randconfig
> builds:
>
> ethernet/broadcom/bnxt/bnxt.c:4956:21: error: 'bnxt_get_max_func_vnics' defined but not used [-Werror=unused-function]
> ethernet/broadcom/bnxt/bnxt.c:4947:21: error: 'bnxt_get_max_func_rss_ctxs' defined but not used [-Werror=unused-function]
>
> Ideally we'd just remove all of them and use 'if (IS_ENABLED())'
> checks instead, which don't have this problem, but for now, I'm
> adding one more #ifdef to shut up the new warning.
>
> Fixes: 8079e8f107bf ("bnxt_en: Refactor code that determines RFS capability.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Michael Chan has a fix for this coming my way.
^ permalink raw reply
* Re: net: ti: cpsw-phy-sel: RGMII is not working on AM335x
From: Teresa Remmet @ 2017-01-11 15:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandru Gagniuc, David S. Miller, Mugunthan V N,
Grygorii Strashko, linux-omap, netdev
In-Reply-To: <20170111151407.GW22820@lunn.ch>
Hello Andrew,
Am Mittwoch, den 11.01.2017, 16:14 +0100 schrieb Andrew Lunn:
> >
> > So I wonder what is correct now? As for me the patch makes RGMII
> > unusable.
> > Has anyone an explanation?
> Hi Teresa
>
> In your device tree, what phy-mode do you have?
>
> And does your hardware require an RGMII delay in order that it works?
my device tree node for the RGMII looks like this:
&cpsw_emac1 {
phy-handle = <&phy1>;
phy-mode = "rgmii";
dual_emac_res_vlan = <2>;
status = "okay";
};
&davinci_mdio {
phy1: ethernet-phy@1 {
reg = <2>;
/* Register 260 (104h) – RGMII Clock and Control Pad Skew */ rxc-skew-ps = <1400>;
rxdv-skew-ps = <0>;
txc-skew-ps = <1400>;
txen-skew-ps = <0>;
/* Register 261 (105h) – RGMII RX Data Pad Skew */
rxd3-skew-ps = <0>;
rxd2-skew-ps = <0>;
rxd1-skew-ps = <0>;
rxd0-skew-ps = <0>;
/* Register 262 (106h) – RGMII TX Data Pad Skew */
txd3-skew-ps = <0>;
txd2-skew-ps = <0>;
txd1-skew-ps = <0>;
txd0-skew-ps = <0>;
};
};
The phy we use is a KSZ9021. And yes we add delays to the
phy, as you can see. When looking to the dts documentation I probably
need to set the phy-mode to "rgmii-id" instead, as the phy is providing
the delays.
I make a quick test with that change and it is working. So this seems
to solve my problem. Thank you for the hint.
Regards,
Teresa
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/2] net/sched: cls_flower: Support matching ARP
From: David Miller @ 2017-01-11 16:04 UTC (permalink / raw)
To: simon.horman; +Cc: jiri, dinan.gunawardena, netdev, oss-drivers
In-Reply-To: <1484139943-18199-1-git-send-email-simon.horman@netronome.com>
From: Simon Horman <simon.horman@netronome.com>
Date: Wed, 11 Jan 2017 14:05:41 +0100
> Add support for support matching on ARP operation, and hardware and
> protocol addresses for Ethernet hardware and IPv4 protocol addresses.
>
> Changes since RFC:
> * None other than dropping RFC designation after positive feedback from Jiri
Series applied, thanks Simon.
^ permalink raw reply
* [PATCH net-next] sfc: efx_get_phys_port_id() can be static
From: Wei Yongjun @ 2017-01-11 16:16 UTC (permalink / raw)
To: Solarflare linux maintainers, Edward Cree, Bert Kenward
Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/net/ethernet/sfc/efx.c:2337:5: warning:
symbol 'efx_get_phys_port_id' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/sfc/efx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
index 543fa48..f2ec853 100644
--- a/drivers/net/ethernet/sfc/efx.c
+++ b/drivers/net/ethernet/sfc/efx.c
@@ -2334,8 +2334,8 @@ static int efx_set_features(struct net_device *net_dev, netdev_features_t data)
return 0;
}
-int efx_get_phys_port_id(struct net_device *net_dev,
- struct netdev_phys_item_id *ppid)
+static int efx_get_phys_port_id(struct net_device *net_dev,
+ struct netdev_phys_item_id *ppid)
{
struct efx_nic *efx = netdev_priv(net_dev);
^ permalink raw reply related
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 16:17 UTC (permalink / raw)
To: David Miller, Joao.Pinto
Cc: alexandre.torgue, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <20170111.102000.1291650495305959047.davem@davemloft.net>
Às 3:20 PM de 1/11/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@synopsys.com>
> Date: Wed, 11 Jan 2017 15:06:55 +0000
>
>> The goal of this work is to improve code organization and future merge of other
>> Synopsys Ethernet IP driver that will be able to merge into this "synopsys
>> driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
>> stmmac.
>
> Then I want to see an ACK from Alexandre and Peppe for this renaming
> patch set.
>
Of course!
Alexandre and Peppe do you want a file / function rename as well?
Thanks.
Joao
^ permalink raw reply
* Re: [PATCH v2 0/2] remove dwc_eth_qos and rename stmicro/stmmac
From: Joao Pinto @ 2017-01-11 16:19 UTC (permalink / raw)
To: David Miller, Joao.Pinto
Cc: alexandre.torgue, lars.persson, niklass, peppe.cavallaro, netdev
In-Reply-To: <20170111.102000.1291650495305959047.davem@davemloft.net>
Às 3:20 PM de 1/11/2017, David Miller escreveu:
> From: Joao Pinto <Joao.Pinto@synopsys.com>
> Date: Wed, 11 Jan 2017 15:06:55 +0000
>
>> The goal of this work is to improve code organization and future merge of other
>> Synopsys Ethernet IP driver that will be able to merge into this "synopsys
>> driver bundle". That is why I volunteered to merge the dwc qos axis' driver into
>> stmmac.
>
> Then I want to see an ACK from Alexandre and Peppe for this renaming
> patch set.
>
Just a side question. My commits are assuming my username instead of my name.
Did you ever had a similar issue? My gitconfig:
> [user]
> email = jpinto@synopsys.com
> name = Joao Pinto
> [format]
> signoff = true
> thread = true
> [sendemail]
> smtpEncryption = tls
> smtpServer = <SERVER>
> smtpUser = <SERVER_USER>
> confirm = auto
> [core]
> excludesfile = /path/.gitignore [pack]
> windowMemory = 2048m
> [diff]
> renames = copy
Thanks,
Joao
^ permalink raw reply
* Re: TCP using IPv4-mapped IPv6 address as source
From: Eric Dumazet @ 2017-01-11 16:20 UTC (permalink / raw)
To: Jonathan T. Leighton; +Cc: netdev, edumazet, Yuchung Cheng, Neal Cardwell
In-Reply-To: <87f4e2ec-22bf-2401-8401-57205f893289@udel.edu>
On Thu, 2017-01-05 at 16:25 -0500, Jonathan T. Leighton wrote:
> I've observed TCP using an IPv4-mapped IPv6 address as the source
> address, which I believe contradicts
> https://tools.ietf.org/html/rfc6890#page-14 (BCP 153). This occurs when
> an IPv6 TCP socket, bound to a local IPv4-mapped IPv6 address, attempts
> to connect to a remote IPv6 address. Presumable connect() should return
> EAFNOSUPPORT in this case. Please advise me if this is not to
> appropriate list to report this.
Hi Jonathan
I believe your concern makes sense.
Do you have a patch to address this issue ?
Thanks
^ permalink raw reply
* Re: [PATCH net-next 1/2] phy: marvell: Add support for temperature sensor
From: Sergei Shtylyov @ 2017-01-11 16:29 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Vivien Didelot, Florian Fainelli
In-Reply-To: <20170111150931.GV22820@lunn.ch>
Hello!
On 01/11/2017 06:09 PM, Andrew Lunn wrote:
>> +static int marvell_hwmon_probe(struct phy_device *phydev,
>> + const struct hwmon_chip_info *chip)
>> +{
>> + struct marvell_priv *priv = phydev->priv;
>> + struct device *dev = &phydev->mdio.dev;
>> + int err;
>> +
>> + err = marvell_hwmon_name(phydev);
>> + if (err)
>> + return err;
>> +
>> + priv->hwmon_dev = devm_hwmon_device_register_with_info(
>> + dev, priv->hwmon_name, phydev, chip, NULL);
>> +
>> + if (IS_ERR(priv->hwmon_dev))
>> + return PTR_ERR(priv->hwmon_dev);
>> +
>> + return 0;
>> +}
>
> 0-day has pointed out this can be simplified to just
>
> return PTR_ERR(priv->hwmon_dev);
PTR_ERR_OR_ZERO() maybe?
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] net: thunderx: Fix error return code in nicvf_open()
From: Wei Yongjun @ 2017-01-11 16:32 UTC (permalink / raw)
To: Sunil Goutham, Robert Richter; +Cc: Wei Yongjun, linux-arm-kernel, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 712c31853440 ("net: thunderx: Program LMAC credits based on MTU")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 273eafd..a25bb6e 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -1274,7 +1274,8 @@ int nicvf_open(struct net_device *netdev)
/* Configure receive side scaling and MTU */
if (!nic->sqs_mode) {
nicvf_rss_init(nic);
- if (nicvf_update_hw_max_frs(nic, netdev->mtu))
+ err = nicvf_update_hw_max_frs(nic, netdev->mtu);
+ if (err)
goto cleanup;
/* Clear percpu stats */
^ permalink raw reply related
* Re: [PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors
From: Tom Lendacky @ 2017-01-11 16:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-pci, Mauro Carvalho Chehab, netdev, linux-media
In-Reply-To: <20170111090357.GB7350@lst.de>
On 1/11/2017 3:03 AM, Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 12:40:10PM -0600, Tom Lendacky wrote:
>> On 1/9/2017 2:37 PM, Christoph Hellwig wrote:
>>> The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
>>> and pci_enable_msix_range interfaces. Switch it to use
>>> pci_irq_alloc_vectors instead.
>>
>> I was just working on switching over to this API with some additional
>> changes / simplification. I'm ok with using this patch so that you get
>> the API removal accomplished. Going through the PCI tree just means
>> it will probably be easier for me to hold off on the additional changes
>> I wanted to make until later.
>
> Hi Tom,
Hi Christoph,
>
> if you have a better patch I'd be more than happy to use that one instead,
> this one was intended as a stupid search and replace. The important
> part for me is to get the two conversions and the interface removal
> in together.
That sounds good, I'll send the patch to you in a separate email for use
in your series.
Thanks,
Tom
>
> E.g. I've alreayd wondered why the driver requires the exact vector
> number for MSI and a variable one for MSI-X, and there certainly is
> all kinds of opportunity for cosmetic cleanup.
>
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables
From: Lorenzo Colitti @ 2017-01-11 16:46 UTC (permalink / raw)
To: David Miller; +Cc: Andrey Jr. Melnikov, netdev@vger.kernel.org
In-Reply-To: <20170111.091139.1754139535517451753.davem@davemloft.net>
On Wed, Jan 11, 2017 at 11:11 PM, David Miller <davem@davemloft.net> wrote:
> I understand what you're saying, but if you look at how apps can be
> put into hierarchical control groups, and automatically bind to VRF's
> based upon where they are in that cgroup hierarchy, it matches your
> use case precisely.
I think whether an app is in bound to a certain VRF or not is not
directly related to this patch. What this patch does is provide a way
to ensure that routes learned via autoconf go into a specific routing
table, so that policy routing rules can select them.
Without this patch, and without VRFs, the routes for all networks and
all interfaces all go into the same routing table (main). That doesn't
work well on a multinetwork device. As David A. points out, with VRFs
this can be done - since each VRF has its own routing table, the
routes are isolated and ip rules can be applied to determine which
ones are used. However, I'm not convinced that VRFs are a great
solution to this problem. A couple of problems I see here are:
1. When an interface is created on the fly, the system must guarantee
that a VRF for it exists, and the interface is put into it, before it
comes up and receives an RA. This is not insurmountable - for example,
you can set net.conf.default.disable_ipv6 to 1, and set it to 0 on the
interface once it's in a VRF. Not sure this is feasible on a
mainstream distribution, but it could be done on something like
Android that's more tightly integrated.
2. I'm not sure it's possible to use routing policy to select between
interfaces in the same VRF. For example, if you have a carrier that
provides the user with the same IP address and similar connectivity on
both cellular data and a carrier-operated wifi network, and you put
those two in the same VRF, I don't see a way to say via routing policy
"prefer wifi over cellular", because the routes for both are in the
same table and AIUI the only discriminator between the two - the oif -
has to be set to the VRF ifindex. I suppose it might be possible to
alter the metrics of routes that were previously created by autoconf
but that sounds desperately hacky.
I suppose both of these could also be resolved by ensuring that each
interface is its own VRF at creation time. But if every VRF only
contains exactly one interface, the VRF construct doesn't really seem
useful.
That said, we've maintained this patch out of tree for a few years now
and we can continue to do so for a while longer. When the VRF code
rolls into enough SoC kernels we can make an attempt to use it and see
what issues we find.
^ 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