* [PATCH v2] net: fec: Add a fec_enet_clear_ethtool_stats() stub for CONFIG_M5272
From: Fabio Estevam @ 2017-06-10 13:23 UTC (permalink / raw)
To: davem; +Cc: fugang.duan, netdev, paul.gortmaker, andrew, Fabio Estevam
From: Fabio Estevam <fabio.estevam@nxp.com>
Commit 2b30842b23b9 ("net: fec: Clear and enable MIB counters on imx51")
introduced fec_enet_clear_ethtool_stats(), but missed to add a stub
for the CONFIG_M5272=y case, causing build failure for the
m5272c3_defconfig.
Add the missing empty stub to fix the build failure.
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
Changes since v1:
- I am resending it with Andrew's Reviewed-by. Originally I have mistyped
tha netdev mailing list address.
drivers/net/ethernet/freescale/fec_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 297fd19..a6e323f 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2379,6 +2379,10 @@ static void fec_enet_clear_ethtool_stats(struct net_device *dev)
static inline void fec_enet_update_ethtool_stats(struct net_device *dev)
{
}
+
+static inline void fec_enet_clear_ethtool_stats(struct net_device *dev)
+{
+}
#endif /* !defined(CONFIG_M5272) */
/* ITR clock source is enet system clock (clk_ahb).
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/1] net: reflect mark on tcp syn ack packets
From: Jamal Hadi Salim @ 2017-06-10 13:31 UTC (permalink / raw)
To: davem; +Cc: netdev, lorenzo, mrv, Jamal Hadi Salim, Jamal Hadi Salim
From: Jamal Hadi Salim <hadi@mojatatu.com>
SYN-ACK responses on a server in response to a SYN from a client
did not get the injected skb mark that was tagged on the SYN packet.
Fixes: 84f39b08d786 ("net: support marking accepting TCP sockets")
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
net/ipv4/ip_output.c | 3 ++-
net/ipv4/tcp_output.c | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 7a3fd25..a8fd5f0 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -173,7 +173,8 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const struct sock *sk,
}
skb->priority = sk->sk_priority;
- skb->mark = sk->sk_mark;
+ if (!skb->mark)
+ skb->mark = sk->sk_mark;
/* Send it out. */
return ip_local_out(net, skb->sk, skb);
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 9a9c395..8c3661a 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -3212,6 +3212,8 @@ struct sk_buff *tcp_make_synack(const struct sock *sk, struct dst_entry *dst,
tcp_ecn_make_synack(req, th);
th->source = htons(ireq->ir_num);
th->dest = ireq->ir_rmt_port;
+ if (sock_net(sk)->ipv4.sysctl_tcp_fwmark_accept)
+ skb->mark = ireq->ir_mark;
/* Setting of flags are superfluous here for callers (and ECE is
* not even correctly set)
*/
--
1.9.1
^ permalink raw reply related
* Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova
From: Majd Dibbiny @ 2017-06-10 14:11 UTC (permalink / raw)
To: Doug Ledford
Cc: Jason Gunthorpe, Saeed Mahameed, Ilan Tayari, Alexei Starovoitov,
David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jsorensen-b10kYP2dOMg@public.gmane.org, Andy Shevchenko,
linux-fpga-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alan Tull,
yi1.li-VuQAYsv1563Yd54FQh9/CA@public.gmane.org, Boris Pismenny
In-Reply-To: <1497047041.7171.234.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> On Jun 10, 2017, at 1:24 AM, Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
>> On Wed, 2017-06-07 at 13:21 -0600, Jason Gunthorpe wrote:
>>> On Wed, Jun 07, 2017 at 10:13:43PM +0300, Saeed Mahameed wrote:
>>>
>>> No !!
>>> I am just showing you that the ib_core eventually will end up
>>> calling
>>> mlx5_core to create a QP.
>>> so mlx5_core can create the QP it self since it is the one
>>> eventually
>>> creating QPs.
>>> we just call mlx5_core_create_qp directly.
>>
>> Which is building a RDMA ULP inside a driver without using the core
>> code :(
>
> Aren't the transmit/receive queues of the Ethernet netdevice on
> mlx4/mlx5 hardware QPs too? Those bypass the RDMA subsystem entirely.
> Just because something uses a QP on hardware that does *everything*
> via QPs doesn't necessarily mean it must go through the RDMA subsystem.
>
> Now, the fact that the content of the packets is basically a RoCE
> packet does make things a bit fuzzier, but if their packets are
> specially crafted RoCE packets that aren't really intended to be fully
> RoCE spec compliant (maybe they don't support all the options as normal
> RoCE QPs), then I can see hiding them from the larger RoCE portion of
> the RDMA stack.
>
>>>
>>>>
>>>> This keep getting more ugly :(
>>>>
>>>> What about security? What if user space sends some raw packets to
>>>> the
>>>> FPGA - can it reprogram the ISPEC settings or worse?
>>>>
>>>
>>> No such thing. This QP is only for internal driver/HW
>>> communications,
>>> as it is faster from the existing command interface.
>>> it is not meant to be exposed for any raw user space usages at all,
>>> without proper standard API adapter of course.
>>
>> I'm not asking about the QP, I'm asking what happens after the NIC
>> part. You use ROCE packets to control the FPGA. What prevents
>> userspace from forcibly constructing roce packets and sending them to
>> the FPGA. How does the FPGA know for certain the packet came from the
>> kernel QP and not someplace else.
>
> This is a valid concern.
>
>> This is especially true for mlx nics as there are many raw packet
>> bypass mechanisms available to userspace.
>
All of the Raw packet bypass mechanisms are restricted to CAP_NET_RAW, and thus malicious users can't simply open a RAW Packet QP and send it to the FPGA..
> Right. The question becomes: Does the firmware filter outgoing raw ETH
> QPs such that a nefarious user could not send a crafted RoCE packet
> that the bump on the wire would intercept and accept?
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG KeyID: B826A3330E572FDD
>
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Re: [PATCH net-next] ipv6: Initial skb->dev and skb->protocol in ip6_output
From: Eric Dumazet @ 2017-06-10 14:54 UTC (permalink / raw)
To: Chenbo Feng; +Cc: David Miller, netdev, lorenzo, edumazet, fengc
In-Reply-To: <3e187bb4-df36-1791-aa92-03a348b68b14@gmail.com>
On Fri, 2017-06-09 at 16:12 -0700, Chenbo Feng wrote:
>
> On 06/09/2017 12:39 PM, David Miller wrote:
> > From: Chenbo Feng <chenbofeng.kernel@gmail.com>
> > Date: Fri, 9 Jun 2017 12:13:57 -0700
> >
> >>
> >> On 06/09/2017 12:08 PM, David Miller wrote:
> >>> From: Chenbo Feng <chenbofeng.kernel@gmail.com>
> >>> Date: Fri, 9 Jun 2017 12:06:07 -0700
> >>>
> >>>> From: Chenbo Feng <fengc@google.com>
> >>>>
> >>>> Move the initialization of skb->dev and skb->protocol from
> >>>> ip6_finish_output2 to ip6_output. This can make the skb->dev and
> >>>> skb->protocol information avalaible to the CGROUP eBPF filter.
> >>>>
> >>>> Signed-off-by: Chenbo Feng <fengc@google.com>
> >>>> Acked-by: Eric Dumazet <edumazet@google.com>
> >>> Applied, thanks.
> >>>
> >>> This makes ipv6 consistent with ipv4.
> >>>
> >>> I am surprised this wasn't noticed, for example, in netfilter.
> >>> .
> >>>
> >> Hi David,
> >>
> >> This patch is still under working since it may have problem with
> >> ip_fragment() call, did you applied it already? Should I send a revert
> >> patch to you then?
> > A revert is necessary or a relative fixup.
> >
> > Thank you.
> >
> Hi David,
>
> The revert is uploaded here: http://patchwork.ozlabs.org/patch/774136/
>
> Thanks and sorry for the trouble caused
>
> Chenbo Feng
No worries !
It seems the revert is not needed, after further analysis.
One of the point I raised was this no longer needed chunk, that can be
added as a separate patch :
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 02cd44f0953900108701895108b2fdaa9f9980e5..0d6f3b6345de26c329ae1d6f25dde652a5452d4b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -869,7 +869,6 @@ int ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
if (skb->sk && dst_allfrag(skb_dst(skb)))
sk_nocaps_add(skb->sk, NETIF_F_GSO_MASK);
- skb->dev = skb_dst(skb)->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
err = -EMSGSIZE;
^ permalink raw reply related
* Re: [PATCH net-next] Revert "ipv6: Initial skb->dev and skb->protocol in ip6_output"
From: Eric Dumazet @ 2017-06-10 14:55 UTC (permalink / raw)
To: Chenbo Feng
Cc: netdev, David Miller, Lorenzo Colitti, Eric Dumazet, Chenbo Feng
In-Reply-To: <1497038162-10327-1-git-send-email-chenbofeng.kernel@gmail.com>
On Fri, 2017-06-09 at 12:56 -0700, Chenbo Feng wrote:
> From: Chenbo Feng <fengc@google.com>
>
> This reverts commit 97a7a37a7b7b("ipv6: Initial skb->dev and
> skb->protocol in ip6_output") since it does not handles the
> skb->dev assignment inside ip6_fragment() code path properly.
> Need to rework and upload again
We can avoid the revert I believe the patch is fine after analysis.
Please submit this followup, thanks ! :
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 02cd44f0953900108701895108b2fdaa9f9980e5..0d6f3b6345de26c329ae1d6f25dde652a5452d4b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -869,7 +869,6 @@ int ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
if (skb->sk && dst_allfrag(skb_dst(skb)))
sk_nocaps_add(skb->sk, NETIF_F_GSO_MASK);
- skb->dev = skb_dst(skb)->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
err = -EMSGSIZE;
^ permalink raw reply related
* Re: [PATCH net-next] ipv6: Initial skb->dev and skb->protocol in ip6_output
From: Eric Dumazet @ 2017-06-10 14:56 UTC (permalink / raw)
To: Bjørn Mork
Cc: Chenbo Feng, David Miller, netdev, lorenzo, edumazet, fengc
In-Reply-To: <87d1adge1i.fsf@miraculix.mork.no>
On Fri, 2017-06-09 at 21:24 +0200, Bjørn Mork wrote:
> Chenbo Feng <chenbofeng.kernel@gmail.com> writes:
>
> > This patch is still under working since it may have problem with
> > ip_fragment() call, did you applied it already? Should I send a revert
> > patch to you then?
>
> It does? I initially thought so too, but looking closer I believe the
> ip6_copy_metadata() calls in ip6_fragment() takes care of it.
Indeed, this should be fine.
^ permalink raw reply
* Re: ARM GLX Khadas VIM Pro - Ethernet detected as only 10Mbps and stalled after some traffic
From: Andrew Lunn @ 2017-06-10 15:27 UTC (permalink / raw)
To: crow; +Cc: netdev, linux-amlogic
In-Reply-To: <CAG_g8w40V_u7JnX+EuNvCLmB2dAzuk_TgMkkKT9pn-SLBRi1pA@mail.gmail.com>
> Also what Martin Blumenstingl wrote is following which is also crucial
> for fixing the issue:
> Amlogic has given their ethernet PHY driver some updates [2], it now
> includes wake-on-lan, and they now have an internal_phy_read_status
> which uses reset_internal_phy if there's a link and some error counter
> exceeds some magic value.
Hi Crow
You could probably just drop the Amlogic driver into mainline and see
if it works better. If that solves your problem, we can look at
merging the changes.
Andrew
^ permalink raw reply
* Re: [PATCH net] sctp: disable BH in sctp_for_each_endpoint
From: Marcelo Ricardo Leitner @ 2017-06-10 15:56 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Neil Horman
In-Reply-To: <fc2c69db46c2dc7c877a54fc0b0917d99d0b7f0c.1497077294.git.lucien.xin@gmail.com>
On Sat, Jun 10, 2017 at 02:48:14PM +0800, Xin Long wrote:
> Now sctp holds read_lock when foreach sctp_ep_hashtable without disabling
> BH. If CPU schedules to another thread A at this moment, the thread A may
> be trying to hold the write_lock with disabling BH.
>
> As BH is disabled and CPU cannot schedule back to the thread holding the
> read_lock, while the thread A keeps waiting for the read_lock. A dead
> lock would be triggered by this.
>
> This patch is to fix this dead lock by calling read_lock_bh instead to
> disable BH when holding the read_lock in sctp_for_each_endpoint.
>
> Fixes: 626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
> Reported-by: Xiumei Mu <xmu@redhat.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Similar is done for proc interface already (sctp_eps_seq_show).
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/socket.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index f16c8d9..30aa0a5 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4622,13 +4622,13 @@ int sctp_for_each_endpoint(int (*cb)(struct sctp_endpoint *, void *),
>
> for (head = sctp_ep_hashtable; hash < sctp_ep_hashsize;
> hash++, head++) {
> - read_lock(&head->lock);
> + read_lock_bh(&head->lock);
> sctp_for_each_hentry(epb, &head->chain) {
> err = cb(sctp_ep(epb), p);
> if (err)
> break;
> }
> - read_unlock(&head->lock);
> + read_unlock_bh(&head->lock);
> }
>
> return err;
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] sctp: fix recursive locking warning in sctp_do_peeloff
From: Marcelo Ricardo Leitner @ 2017-06-10 16:00 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Neil Horman, davem, Cong Wang
In-Reply-To: <a5f7dc6e508e016041f685179f1d99fc04541bdd.1497077816.git.lucien.xin@gmail.com>
On Sat, Jun 10, 2017 at 02:56:56PM +0800, Xin Long wrote:
> Dmitry got the following recursive locking report while running syzkaller
> fuzzer, the Call Trace:
> __dump_stack lib/dump_stack.c:16 [inline]
> dump_stack+0x2ee/0x3ef lib/dump_stack.c:52
> print_deadlock_bug kernel/locking/lockdep.c:1729 [inline]
> check_deadlock kernel/locking/lockdep.c:1773 [inline]
> validate_chain kernel/locking/lockdep.c:2251 [inline]
> __lock_acquire+0xef2/0x3430 kernel/locking/lockdep.c:3340
> lock_acquire+0x2a1/0x630 kernel/locking/lockdep.c:3755
> lock_sock_nested+0xcb/0x120 net/core/sock.c:2536
> lock_sock include/net/sock.h:1460 [inline]
> sctp_close+0xcd/0x9d0 net/sctp/socket.c:1497
> inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
> inet6_release+0x50/0x70 net/ipv6/af_inet6.c:432
> sock_release+0x8d/0x1e0 net/socket.c:597
> __sock_create+0x38b/0x870 net/socket.c:1226
> sock_create+0x7f/0xa0 net/socket.c:1237
> sctp_do_peeloff+0x1a2/0x440 net/sctp/socket.c:4879
> sctp_getsockopt_peeloff net/sctp/socket.c:4914 [inline]
> sctp_getsockopt+0x111a/0x67e0 net/sctp/socket.c:6628
> sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2690
> SYSC_getsockopt net/socket.c:1817 [inline]
> SyS_getsockopt+0x240/0x380 net/socket.c:1799
> entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> This warning is caused by the lock held by sctp_getsockopt() is on one
> socket, while the other lock that sctp_close() is getting later is on
> the newly created (which failed) socket during peeloff operation.
>
> This patch is to avoid this warning by use lock_sock with subclass
> SINGLE_DEPTH_NESTING as Wang Cong and Marcelo's suggestion.
>
> Reported-by: Dmitry Vyukov <dvyukov@google.com>
> Suggested-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Suggested-by: Cong Wang <xiyou.wangcong@gmail.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Thanks for following up on this.
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/socket.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 5f58dd0..32d5495 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -1494,7 +1494,7 @@ static void sctp_close(struct sock *sk, long timeout)
>
> pr_debug("%s: sk:%p, timeout:%ld\n", __func__, sk, timeout);
>
> - lock_sock(sk);
> + lock_sock_nested(sk, SINGLE_DEPTH_NESTING);
> sk->sk_shutdown = SHUTDOWN_MASK;
> sk->sk_state = SCTP_SS_CLOSING;
>
> @@ -1544,7 +1544,7 @@ static void sctp_close(struct sock *sk, long timeout)
> * held and that should be grabbed before socket lock.
> */
> spin_lock_bh(&net->sctp.addr_wq_lock);
> - bh_lock_sock(sk);
> + bh_lock_sock_nested(sk);
>
> /* Hold the sock, since sk_common_release() will put sock_put()
> * and we have just a little more cleanup.
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next] sctp: use read_lock_bh in sctp_eps_seq_show
From: Marcelo Ricardo Leitner @ 2017-06-10 16:02 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <f845585a99f0cb76659f4d5dae4f7d6fd5552224.1497078812.git.lucien.xin@gmail.com>
On Sat, Jun 10, 2017 at 03:13:32PM +0800, Xin Long wrote:
> This patch is to use read_lock_bh instead of local_bh_disable
> and read_lock in sctp_eps_seq_show.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/proc.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/sctp/proc.c b/net/sctp/proc.c
> index 5a27d0f..8e34db5 100644
> --- a/net/sctp/proc.c
> +++ b/net/sctp/proc.c
> @@ -218,8 +218,7 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
> return -ENOMEM;
>
> head = &sctp_ep_hashtable[hash];
> - local_bh_disable();
> - read_lock(&head->lock);
> + read_lock_bh(&head->lock);
> sctp_for_each_hentry(epb, &head->chain) {
> ep = sctp_ep(epb);
> sk = epb->sk;
> @@ -234,8 +233,7 @@ static int sctp_eps_seq_show(struct seq_file *seq, void *v)
> sctp_seq_dump_local_addrs(seq, epb);
> seq_printf(seq, "\n");
> }
> - read_unlock(&head->lock);
> - local_bh_enable();
> + read_unlock_bh(&head->lock);
>
> return 0;
> }
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 net-next] sctp: no need to check assoc id before calling sctp_assoc_set_id
From: Marcelo Ricardo Leitner @ 2017-06-10 16:03 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Neil Horman, davem
In-Reply-To: <ea556c7733c5bf63532ce35186e4bc7a519bf858.1497079632.git.lucien.xin@gmail.com>
On Sat, Jun 10, 2017 at 03:27:12PM +0800, Xin Long wrote:
> sctp_assoc_set_id does the assoc id check in the beginning when
> processing dupcookie, no need to do the same check before calling
> it.
>
> v1->v2:
> fix some typo errs Marcelo pointed in changelog.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/associola.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index 288c5e0..72b07dd 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -1181,12 +1181,8 @@ void sctp_assoc_update(struct sctp_association *asoc,
> if (sctp_state(asoc, COOKIE_WAIT))
> sctp_stream_update(&asoc->stream, &new->stream);
>
> - if (!asoc->assoc_id) {
> - /* get a new association id since we don't have one
> - * yet.
> - */
> - sctp_assoc_set_id(asoc, GFP_ATOMIC);
> - }
> + /* get a new assoc id if we don't have one yet. */
> + sctp_assoc_set_id(asoc, GFP_ATOMIC);
> }
>
> /* SCTP-AUTH: Save the peer parameters from the new associations
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net-next 8/9] net: hns3: Add support of debugfs interface to HNS3 driver
From: Andrew Lunn @ 2017-06-10 16:35 UTC (permalink / raw)
To: Mintz, Yuval
Cc: Salil Mehta, davem@davemloft.net, yisen.zhuang@huawei.com,
huangdaode@hisilicon.com, lipeng321@huawei.com,
mehta.salil.lnk@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxarm@huawei.com
In-Reply-To: <BY2PR0701MB2005750A49D78C63B4B4A6B18DCF0@BY2PR0701MB2005.namprd07.prod.outlook.com>
On Sat, Jun 10, 2017 at 12:51:57PM +0000, Mintz, Yuval wrote:
> > This adds the support of the debugfs interface to the driver for debugging
> > purposes.
>
> > +const struct hclge_support_cmd support_cmd[] = {
> > + {"send cmd", 8, hclge_dbg_send,
> > + "opcode flag data0 data1 data2 data3 data4 data5"},
> > + {"help", 4, hclge_dbg_usage, "no option"}, };
>
> Is there an actual description of what this does? Or is it simply a huge backdoor?
It looks like a huge backdoor to the chip.
It is O.K. to have such a patch internally for your own development
work, but it should not be submitted for mainline.
NACK
Andrew
^ permalink raw reply
* Re: [PATCH net-next 6/9] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC
From: Florian Fainelli @ 2017-06-10 19:04 UTC (permalink / raw)
To: Salil Mehta, davem
Cc: yisen.zhuang, huangdaode, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Andrew Lunn
In-Reply-To: <20170610034630.493852-7-salil.mehta@huawei.com>
Le 06/09/17 à 20:46, Salil Mehta a écrit :
> This patch adds the support of MDIO bus interface for HNS3 driver.
> Code provides various interfaces to start and stop the PHY layer
> and to read and write the MDIO bus or PHY.
>
> Signed-off-by: Daode Huang <huangdaode@hisilicon.com>
> Signed-off-by: lipeng <lipeng321@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> Signed-off-by: Yisen Zhuang <yisen.zhuang@huawei.com>
> ---
> .../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 310 +++++++++++++++++++++
> 1 file changed, 310 insertions(+)
> create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
> new file mode 100644
> index 0000000..c6812d2
> --- /dev/null
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c
> @@ -0,0 +1,310 @@
> +/*
> + * Copyright (c) 2016~2017 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/etherdevice.h>
> +#include <linux/kernel.h>
> +
> +#include "hclge_cmd.h"
> +#include "hclge_main.h"
> +
> +enum hclge_mdio_c22_op_seq {
> + HCLGE_MDIO_C22_WRITE = 1,
> + HCLGE_MDIO_C22_READ = 2
> +};
> +
> +enum hclge_mdio_c45_op_seq {
> + HCLGE_MDIO_C45_WRITE_ADDR = 0,
> + HCLGE_MDIO_C45_WRITE_DATA,
> + HCLGE_MDIO_C45_READ_INCREMENT,
> + HCLGE_MDIO_C45_READ
> +};
> +
> +#define HCLGE_MDIO_CTRL_START_BIT BIT(0)
> +#define HCLGE_MDIO_CTRL_ST_MSK GENMASK(2, 1)
> +#define HCLGE_MDIO_CTRL_ST_LSH 1
> +#define HCLGE_MDIO_IS_C22(c22) (((c22) << HCLGE_MDIO_CTRL_ST_LSH) & \
> + HCLGE_MDIO_CTRL_ST_MSK)
> +
> +#define HCLGE_MDIO_CTRL_OP_MSK GENMASK(4, 3)
> +#define HCLGE_MDIO_CTRL_OP_LSH 3
> +#define HCLGE_MDIO_CTRL_OP(access) \
> + (((access) << HCLGE_MDIO_CTRL_OP_LSH) & HCLGE_MDIO_CTRL_OP_MSK)
> +#define HCLGE_MDIO_CTRL_PRTAD_MSK GENMASK(4, 0)
> +#define HCLGE_MDIO_CTRL_DEVAD_MSK GENMASK(4, 0)
> +
> +#define HCLGE_MDIO_STA_VAL(val) ((val) & BIT(0))
> +
> +struct hclge_mdio_cfg_cmd {
> + u8 ctrl_bit;
> + u8 prtad; /* The external port address */
> + u8 devad; /* The external device address */
> + u8 rsvd;
> + __le16 addr_c45;/* Only valid for c45 */
> + __le16 data_wr;
> + __le16 data_rd;
> + __le16 sta;> +};
> +
> +static int hclge_mdio_write(struct mii_bus *bus, int phy_id, int regnum,
> + u16 data)
> +{
> + struct hclge_dev *hdev = (struct hclge_dev *)bus->priv;
> + struct hclge_mdio_cfg_cmd *mdio_cmd;
> + enum hclge_cmd_status status;
> + struct hclge_desc desc;
> + u8 is_c45, devad;
> + u16 reg;
> +
> + if (!bus)
> + return -EINVAL;
> +
> + is_c45 = !!(regnum & MII_ADDR_C45);
> + devad = ((regnum >> 16) & 0x1f);
> + reg = (u16)(regnum & 0xffff);
> +
> + hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_MDIO_CONFIG, false);
> +
> + mdio_cmd = (struct hclge_mdio_cfg_cmd *)desc.data;
> +
> + if (!is_c45) {
It would be more readable with positive logic: if (is_c45) { } else { }
> + /* C22 write reg and data */
> + mdio_cmd->ctrl_bit = HCLGE_MDIO_IS_C22(!is_c45);
> + mdio_cmd->ctrl_bit |= HCLGE_MDIO_CTRL_OP(HCLGE_MDIO_C22_WRITE);
> + mdio_cmd->ctrl_bit |= HCLGE_MDIO_CTRL_START_BIT;
> + mdio_cmd->data_wr = cpu_to_le16(data);
> + mdio_cmd->devad = devad & HCLGE_MDIO_CTRL_DEVAD_MSK;
> + mdio_cmd->prtad = phy_id & HCLGE_MDIO_CTRL_PRTAD_MSK;
> + } else {
> + /* Set phy addr */
> + mdio_cmd->ctrl_bit |= HCLGE_MDIO_CTRL_START_BIT;
> + mdio_cmd->addr_c45 = cpu_to_le16(reg);
> + mdio_cmd->data_wr = cpu_to_le16(data);
> + mdio_cmd->devad = devad & HCLGE_MDIO_CTRL_DEVAD_MSK;
> + mdio_cmd->prtad = phy_id & HCLGE_MDIO_CTRL_PRTAD_MSK;
> + }
There is some common initialization that you could probably extracted
out of the C22/C45 clause here.
> +
> + status = hclge_cmd_send(&hdev->hw, &desc, 1);
> + if (status) {
> + dev_err(&hdev->pdev->dev,
> + "mdio write fail when sending cmd, status is %d.\n",
> + status);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int hclge_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
> +{
> + struct hclge_dev *hdev = (struct hclge_dev *)bus->priv;
> + struct hclge_mdio_cfg_cmd *mdio_cmd;
> + enum hclge_cmd_status status;
> + struct hclge_desc desc;
> + u8 is_c45, devad;
> + u16 reg;
> +
> + if (!bus)
> + return -EINVAL;
> +
> + is_c45 = !!(regnum & MII_ADDR_C45);
> + devad = ((regnum >> 16) & GENMASK(4, 0));
> + reg = (u16)(regnum & GENMASK(15, 0));
> +
> + hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_MDIO_CONFIG, true);
> +
> + mdio_cmd = (struct hclge_mdio_cfg_cmd *)desc.data;
> +
> + dev_dbg(&bus->dev, "phy id=%d, is_c45=%d, devad=%d, reg=%#x!\n",
> + phy_id, is_c45, devad, reg);
> +
> + if (!is_c45) {
> + /* C22 read reg */
> + mdio_cmd->ctrl_bit = HCLGE_MDIO_IS_C22(!is_c45);
> + mdio_cmd->ctrl_bit |= HCLGE_MDIO_CTRL_OP(HCLGE_MDIO_C22_READ);
> + mdio_cmd->ctrl_bit |= HCLGE_MDIO_CTRL_START_BIT;
> + mdio_cmd->devad = reg & HCLGE_MDIO_CTRL_DEVAD_MSK;
> + mdio_cmd->prtad = phy_id & HCLGE_MDIO_CTRL_PRTAD_MSK;
> + } else {
> + /* C45 phy addr */
> + mdio_cmd->ctrl_bit |= HCLGE_MDIO_CTRL_START_BIT;
> +
> + mdio_cmd->addr_c45 = cpu_to_le16(reg);
> + mdio_cmd->devad = devad & HCLGE_MDIO_CTRL_DEVAD_MSK;
> + mdio_cmd->prtad = phy_id & HCLGE_MDIO_CTRL_PRTAD_MSK;
> + }
Same here, the last two assignments could be common with an appropriate
variable assignment before.
> +
> + /* Read out phy data */
> + status = hclge_cmd_send(&hdev->hw, &desc, 1);
> + if (status) {
> + dev_err(&hdev->pdev->dev,
> + "mdio read fail when get data, status is %d.\n",
> + status);
> + return -EIO;
> + }
> +
> + if (le16_to_cpu(HCLGE_MDIO_STA_VAL(mdio_cmd->sta))) {
> + dev_err(&hdev->pdev->dev, "mdio read data error\n");
> + return -ENOMEM;
> + }
> +
> + return le16_to_cpu(mdio_cmd->data_rd);
> +}
> +
> +int hclge_mac_mdio_config(struct hclge_dev *hdev)
> +{
> + struct hclge_mac *mac = &hdev->hw.mac;
> + struct mii_bus *mdio_bus;
> + struct net_device *ndev = &mac->ndev;
> + struct phy_device *phy;
> + bool is_c45;
> + int ret;
> +
> + if (hdev->hw.mac.phy_addr >= PHY_MAX_ADDR)
> + return 0;
> +
> + if (hdev->hw.mac.phy_if == PHY_INTERFACE_MODE_NA)
> + return 0;
> + else if (mac->phy_if == PHY_INTERFACE_MODE_SGMII)
> + is_c45 = 0;
> + else if (mac->phy_if == PHY_INTERFACE_MODE_XGMII)
> + is_c45 = 1;
> + else
> + return -ENODATA;
Can you consider using a switch () case statement here?
> +
> + SET_NETDEV_DEV(ndev, &hdev->pdev->dev);
> +
> + mdio_bus = devm_mdiobus_alloc(&hdev->pdev->dev);
> + if (!mdio_bus) {
> + ret = -ENOMEM;
> + goto err_miibus_alloc;
> + }
> +
> + mdio_bus->name = "hisilicon MII bus";
> + mdio_bus->read = hclge_mdio_read;
> + mdio_bus->write = hclge_mdio_write;
> + snprintf(mdio_bus->id, MII_BUS_ID_SIZE, "%s-%s", "mii",
> + dev_name(&hdev->pdev->dev));
> +
> + mdio_bus->parent = &hdev->pdev->dev;
> + mdio_bus->priv = hdev;
> + mdio_bus->phy_mask = ~0;
> + ret = mdiobus_register(mdio_bus);
> + if (ret) {
> + dev_err(mdio_bus->parent,
> + "Failed to register MDIO bus ret = %#x\n", ret);
> + goto err_mdio_register;
> + }
> +
> + phy = get_phy_device(mdio_bus, mac->phy_addr, is_c45);
> + if (!phy || IS_ERR(phy)) {
> + dev_err(mdio_bus->parent, "Failed to get phy device\n");
> + ret = -EIO;
> + goto err_mdio_register;
> + }
Hum why do you do this? mdiobus_register() will scan through your bus
provided that you set an appropriate phy_mask value (here you tell it
not to) and you already provide the PHY address to scan for
> +
> + phy->irq = mdio_bus->irq[mac->phy_addr];
> +
> + /* All data is now stored in the phy struct;
> + * register it
> + */
> + ret = phy_device_register(phy);
> + if (ret) {
> + ret = -ENODEV;
> + goto err_phy_register;
> + }
This also looks completely unecessary if you correctly set phy_mask. Can
you explain why you did that way?
> +
> + mac->phy_dev = phy;
> +
> + return 0;
> +
> +err_phy_register:
> + phy_device_free(phy);
> +err_mdio_register:
> + mdiobus_unregister(mdio_bus);
> + mdiobus_free(mdio_bus);
> +err_miibus_alloc:
> + return ret;
> +}
> +
> +static void hclge_mac_adjust_link(struct net_device *net_dev)
> +{
> + int duplex;
> + int speed;
> + struct hclge_mac *hw_mac;
> + struct hclge_hw *hw;
> + struct hclge_dev *hdev;
> +
> + if (!net_dev)
> + return;
> +
> + hw_mac = container_of(net_dev, struct hclge_mac, ndev);
> + hw = container_of(hw_mac, struct hclge_hw, mac);
> + hdev = hw->back;
> +
> + speed = hw_mac->phy_dev->speed;
> + duplex = hw_mac->phy_dev->duplex;
> +
> + /* update antoneg. */
> + hw_mac->autoneg = hw_mac->phy_dev->autoneg;
> +
> + if ((hw_mac->speed != speed) || (hw_mac->duplex != duplex))
> + (void)hclge_cfg_mac_speed_dup(hdev, speed, !!duplex);
> +}
> +
> +int hclge_mac_start_phy(struct hclge_dev *hdev)
> +{
> + struct hclge_mac *mac = &hdev->hw.mac;
> + struct phy_device *phy_dev = mac->phy_dev;
> + int ret;
> +
> + if (!phy_dev)
> + return 0;
> +
> + if (mac->phy_if != PHY_INTERFACE_MODE_XGMII) {
> + phy_dev->dev_flags = 0;
> +
> + ret = phy_connect_direct(&mac->ndev, phy_dev,
> + hclge_mac_adjust_link,
> + mac->phy_if);
> + phy_dev->supported = SUPPORTED_10baseT_Half |
> + SUPPORTED_10baseT_Full |
> + SUPPORTED_100baseT_Half |
> + SUPPORTED_100baseT_Full |
> + SUPPORTED_Autoneg |
> + SUPPORTED_1000baseT_Full;
> +
> + phy_dev->autoneg = false;
> + } else {
> + ret = phy_attach_direct(&mac->ndev, phy_dev, 0, mac->phy_if);
> + phy_dev->supported = SUPPORTED_10000baseR_FEC |
> + SUPPORTED_10000baseKR_Full;
> + }
Why is there a different PHYLIB call based on XGMII or not? Cannot you
always attach to the PHY and then start the PHY state machine instead of
doing a connect() or attach() here?
> + if (unlikely(ret))
> + return -ENODEV;
> +
> + phy_start(phy_dev);
> +
> + return 0;
> +}
> +
> +void hclge_mac_stop_phy(struct hclge_dev *hdev)
> +{
> + struct hclge_mac *mac = &hdev->hw.mac;
> + struct phy_device *phy_dev = mac->phy_dev;
> +
> + if (!phy_dev)
> + return;
> +
> + phy_stop(phy_dev);
> +
> + if (mac->phy_if != PHY_INTERFACE_MODE_XGMII)
> + phy_disconnect(phy_dev);
> + else
> + phy_detach(phy_dev);
You cannot detach or disconnect based on the PHY interface, that does
not really make sense as both are not symetrical.
--
Florian
^ permalink raw reply
* [PATCH v1] net: rfkill: gpio: Switch to devm_acpi_dev_add_driver_gpios()
From: Andy Shevchenko @ 2017-06-10 19:10 UTC (permalink / raw)
To: Johannes Berg, linux-wireless, David S. Miller, netdev; +Cc: Andy Shevchenko
Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify
error path and fix potentially wrong assingment if ->probe() fails.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
net/rfkill/rfkill-gpio.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 76c01cbd56e3..41bd496531d4 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -81,8 +81,7 @@ static int rfkill_gpio_acpi_probe(struct device *dev,
rfkill->type = (unsigned)id->driver_data;
- return acpi_dev_add_driver_gpios(ACPI_COMPANION(dev),
- acpi_rfkill_default_gpios);
+ return devm_acpi_dev_add_driver_gpios(dev, acpi_rfkill_default_gpios);
}
static int rfkill_gpio_probe(struct platform_device *pdev)
@@ -154,8 +153,6 @@ static int rfkill_gpio_remove(struct platform_device *pdev)
rfkill_unregister(rfkill->rfkill_dev);
rfkill_destroy(rfkill->rfkill_dev);
- acpi_dev_remove_driver_gpios(ACPI_COMPANION(&pdev->dev));
-
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] sh_eth: add support to change MTU
From: Sergei Shtylyov @ 2017-06-10 19:26 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: netdev, linux-renesas-soc
In-Reply-To: <20170609203658.GB17461@bigcity.dyn.berto.se>
Hello!
On 06/09/2017 11:36 PM, Niklas Söderlund wrote:
>> The hardware supports the MTU to be changed and the driver it self is
>> somewhat prepared to support this. This patch hooks up the callbacks to
>> be able to change the MTU from user-space.
>>
>> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> ---
[...]
>> @@ -3171,6 +3184,13 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
>> }
>> sh_eth_set_default_cpu_data(mdp->cd);
>>
>> + /* User's manua states max MTU should be 2048 but due to the
>
> s/manua/manual/
Looking at it for another time, I'd also reword the subject -- something
like "sh_eth: add support for changing MTU" or "sh_eth: add MTU change support".
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain
From: Arend van Spriel @ 2017-06-10 19:27 UTC (permalink / raw)
To: Andy Shevchenko, Peter S. Housel
Cc: Franky Lin, Hante Meuleman, Kalle Valo, Pieter-Paul Giesberts,
Christian Daudt, Florian Fainelli, Florian Westphal,
Martin Blumenstingl,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <CAHp75VcfK5V42vzsh=L+CnX2ZnF=8UORbOf+f2WfmcNH1DbAsw@mail.gmail.com>
On 03-06-17 17:36, Andy Shevchenko wrote:
> On Sat, Jun 3, 2017 at 1:29 AM, Peter S. Housel <housel@acm.org> wrote:
>> An earlier change to this function (3bdae810721b) fixed a leak in the
>> case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
>> glom_skb buffer, used for emulating a scattering read, is never used
>> or referenced after its contents are copied into the destination
>> buffers, and therefore always needs to be freed by the end of the
>> function.
[snip]
>> + skb_queue_walk(pktq, skb) {
>> + memcpy(skb->data, glom_skb->data, skb->len);
>> + skb_pull(glom_skb, skb->len);
>> + }
>> }
>
>> + brcmu_pkt_buf_free_skb(glom_skb);
>
> Can we just add this one line instead or I'm missing something?
I guess. We don't want to walk the packet queue if glom_skb is not
carrying data due to brcmf_sdiod_buffrw() failure.
So I would go with the patch below as brcmu_pkt_buf_free_skb() simply
ignores null pointer.
Regards,
Arend
---
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 5bc2ba2..3722f23 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -705,7 +705,7 @@ int brcmf_sdiod_recv_pkt(struct brcmf_sdio_dev
*sdiodev, struct sk_buff *pkt)
int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
struct sk_buff_head *pktq, uint totlen)
{
- struct sk_buff *glom_skb;
+ struct sk_buff *glom_skb = NULL;
struct sk_buff *skb;
u32 addr = sdiodev->sbwad;
int err = 0;
@@ -726,10 +726,8 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev
*sdiodev,
return -ENOMEM;
err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
glom_skb);
- if (err) {
- brcmu_pkt_buf_free_skb(glom_skb);
+ if (err)
goto done;
- }
skb_queue_walk(pktq, skb) {
memcpy(skb->data, glom_skb->data, skb->len);
@@ -740,6 +738,7 @@ int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev
*sdiodev,
pktq);
done:
+ brcmu_pkt_buf_free_skb(glom_skb);
return err;
}
^ permalink raw reply related
* [PATCH net-next] Remove the redundant skb->dev initialization in ip6_fragment
From: Chenbo Feng @ 2017-06-10 19:35 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Lorenzo Colitti, Eric Dumazet, Chenbo Feng
From: Chenbo Feng <fengc@google.com>
After moves the skb->dev and skb->protocol initialization into
ip6_output, setting the skb->dev inside ip6_fragment is unnecessary.
Fixes: 97a7a37a7b7b("ipv6: Initial skb->dev and skb->protocol in ip6_output")
Signed-off-by: Chenbo Feng <fengc@google.com>
---
net/ipv6/ip6_output.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 02cd44f..0d6f3b6 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -869,7 +869,6 @@ int ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
if (skb->sk && dst_allfrag(skb_dst(skb)))
sk_nocaps_add(skb->sk, NETIF_F_GSO_MASK);
- skb->dev = skb_dst(skb)->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
err = -EMSGSIZE;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next] Revert "ipv6: Initial skb->dev and skb->protocol in ip6_output"
From: Chenbo Feng @ 2017-06-10 19:36 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David Miller, Lorenzo Colitti, Eric Dumazet, Chenbo Feng
In-Reply-To: <1497106547.736.104.camel@edumazet-glaptop3.roam.corp.google.com>
On 06/10/2017 07:55 AM, Eric Dumazet wrote:
> On Fri, 2017-06-09 at 12:56 -0700, Chenbo Feng wrote:
>> From: Chenbo Feng <fengc@google.com>
>>
>> This reverts commit 97a7a37a7b7b("ipv6: Initial skb->dev and
>> skb->protocol in ip6_output") since it does not handles the
>> skb->dev assignment inside ip6_fragment() code path properly.
>> Need to rework and upload again
> We can avoid the revert I believe the patch is fine after analysis.
>
> Please submit this followup, thanks ! :
>
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 02cd44f0953900108701895108b2fdaa9f9980e5..0d6f3b6345de26c329ae1d6f25dde652a5452d4b 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -869,7 +869,6 @@ int ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
> if (skb->sk && dst_allfrag(skb_dst(skb)))
> sk_nocaps_add(skb->sk, NETIF_F_GSO_MASK);
>
> - skb->dev = skb_dst(skb)->dev;
> icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu);
> err = -EMSGSIZE;
>
>
>
>
Thanks for the help! Patch submitted here:
http://patchwork.ozlabs.org/patch/774260/
^ permalink raw reply
* Re: [PATCH v4.11 -stable] esp4: Fix udpencap for local TCP packets.
From: David Miller @ 2017-06-10 19:57 UTC (permalink / raw)
To: steffen.klassert; +Cc: netdev
In-Reply-To: <20170609093545.GS22049@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 9 Jun 2017 11:35:46 +0200
> Locally generated TCP packets are usually cloned, so we
> do skb_cow_data() on this packets. After that we need to
> reload the pointer to the esp header. On udpencap this
> header has an offset to skb_transport_header, so take this
> offset into account.
>
> This is a backport of:
> commit 0e78a87306a ("esp4: Fix udpencap for local TCP packets.")
>
> Fixes: 67d349ed603 ("net/esp4: Fix invalid esph pointer crash")
> Fixes: fca11ebde3f0 ("esp4: Reorganize esp_output")
> Reported-by: Don Bowman <db@donbowman.ca>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Queued up for -stable, thanks Steffen.
^ permalink raw reply
* Re: [PATCH net-next 1/2] netns: define extack error msg for nsis cmds
From: David Miller @ 2017-06-10 19:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, jhs
In-Reply-To: <1497012117-1344-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 9 Jun 2017 14:41:56 +0200
> It helps the user to identify errors.
>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied, but please in the future always provide a proper "[PATCH 0/N]
" header posting with a patch series.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 2/2] netns: fix error code when the nsid is already used
From: David Miller @ 2017-06-10 19:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, jhs
In-Reply-To: <1497012117-1344-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 9 Jun 2017 14:41:57 +0200
> When the user tries to assign a specific nsid, idr_alloc() is called with
> the range [nsid, nsid+1]. If this nsid is already used, idr_alloc() returns
> ENOSPC (No space left on device). In our case, it's better to return
> EEXIST to make it clear that the nsid is not available.
>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bonding: warn user when 802.3ad speed is unknown
From: David Miller @ 2017-06-10 20:01 UTC (permalink / raw)
To: nicolas.dichtel
Cc: netdev, j.vosburgh, vfalico, andy, thibaut.collet, linville
In-Reply-To: <1497015283-1729-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 9 Jun 2017 15:34:43 +0200
> Make it explicit in the log.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
I agree with others that we should rate limit this somehow given
the context in which it is invoked.
^ permalink raw reply
* Re: [PATCH net 0/2] bnx2x: Fix malicious VFs indication
From: David Miller @ 2017-06-10 20:03 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, mschmidt
In-Reply-To: <20170609141702.20688-1-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Fri, 9 Jun 2017 17:17:00 +0300
> It was discovered that for a VF there's a simple [yet uncommon] scenario
> which would cause device firmware to declare that VF as malicious -
> Add a vlan interface on top of a VF and disable txvlan offloading for
> that VF [causing VF to transmit packets where vlan is on payload].
>
> Patch #1 corrects driver transmission to prevent this issue.
> Patch #2 is a by-product correcting PF behavior once a VF is declared
> malicious.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: warn user when 802.3ad speed is unknown
From: David Miller @ 2017-06-10 20:07 UTC (permalink / raw)
To: nicolas.dichtel
Cc: andrew, netdev, j.vosburgh, vfalico, andy, thibaut.collet,
linville
In-Reply-To: <1497023888-1420-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 9 Jun 2017 17:58:08 +0200
> Goal is to advertise the user when ethtool speeds and 802.3ad speeds are
> desynchronized.
> When this case happens, the kernel needs to be patched.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied, thanks Nicolas.
^ permalink raw reply
* Re: [PATCH net-next] bpf: Remove duplicate tcp_filter hook in ipv6
From: David Miller @ 2017-06-10 20:08 UTC (permalink / raw)
To: chenbofeng.kernel; +Cc: netdev, lorenzo, edumazet, fengc
In-Reply-To: <1497035857-9927-1-git-send-email-chenbofeng.kernel@gmail.com>
From: Chenbo Feng <chenbofeng.kernel@gmail.com>
Date: Fri, 9 Jun 2017 12:17:37 -0700
> From: Chenbo Feng <fengc@google.com>
>
> There are two tcp_filter hooks in tcp_ipv6 ingress path currently.
> One is at tcp_v6_rcv and another is in tcp_v6_do_rcv. It seems the
> tcp_filter() call inside tcp_v6_do_rcv is redundent and some packet
> will be filtered twice in this situation. This will cause trouble
> when using eBPF filters to account traffic data.
>
> Signed-off-by: Chenbo Feng <fengc@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thank you.
^ 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