* [Odd commit author id merge via netdev]
From: santosh shilimkar @ 2016-04-01 17:51 UTC (permalink / raw)
To: netdev, David S. Miller
Hi Dave,
I noticed something odd while checking the recent
commits of mine in kernel.org tree made it via netdev.
Don't know if its patchwork tool doing this.
Usual author line in my git objects :
Author: Santosh Shilimkar <emaid-id>
But the commits going via your tree seems to be like below..
Author: email-id <email-id>
Few more examples of the commits end of the email. Can this
be fixed for future commits ? The git objects you pulled from
my tree directly have right author format where as ones which
are picked from patchworks seems to be odd.
Regards,
Santosh
commit ad6832f950d35df8c70b577993a24b31b34d88e4
Author: santosh.shilimkar@oracle.com <santosh.shilimkar@oracle.com>
commit 2cb2912d65633e751d3f8397377174501412aa47
Author: santosh.shilimkar@oracle.com <santosh.shilimkar@oracle.com>
commit db42753adb638b63572583162bb08ea193947309
Author: santosh.shilimkar@oracle.com <santosh.shilimkar@oracle.com>
[....]
commit 06766513232d1619ac84e87b1d839d3fcc23a540
Author: Santosh Shilimkar <santosh.shilimkar@oracle.com>
commit 41a4e9646229801624e38f7a1cc53033a0affdb1
Author: Santosh Shilimkar <santosh.shilimkar@oracle.com>
^ permalink raw reply
* Re: [PATCH 2/4] samples/bpf: Use llc in PATH, rather than a hardcoded value
From: Alexei Starovoitov @ 2016-04-01 17:56 UTC (permalink / raw)
To: Naveen N. Rao, Daniel Borkmann
Cc: linux-kernel, linuxppc-dev, netdev, David S . Miller
In-Reply-To: <20160401143751.GF17907@naverao1-tp.ibm.com>
On 4/1/16 7:37 AM, Naveen N. Rao wrote:
> On 2016/03/31 08:19PM, Daniel Borkmann wrote:
>> On 03/31/2016 07:46 PM, Alexei Starovoitov wrote:
>>> On 3/31/16 4:25 AM, Naveen N. Rao wrote:
>>>> clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
>>>> -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
>>>> - -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
>>>> + -O2 -emit-llvm -c $< -o -| llc -march=bpf -filetype=obj -o $@
>>>> clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
>>>> -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
>>>> - -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=asm -o $@.s
>>>> + -O2 -emit-llvm -c $< -o -| llc -march=bpf -filetype=asm -o $@.s
>>>
>>> that was a workaround when clang/llvm didn't have bpf support.
>>> Now clang 3.7 and 3.8 have bpf built-in, so make sense to remove
>>> manual calls to llc completely.
>>> Just use 'clang -target bpf -O2 -D... -c $< -o $@'
>>
>> +1, the clang part in that Makefile should also more correctly be called
>> with '-target bpf' as it turns out (despite llc with '-march=bpf' ...).
>> Better to use clang directly as suggested by Alexei.
>
> I'm likely missing something obvious, but I cannot get this to work.
> With this diff:
>
> $(obj)/%.o: $(src)/%.c
> clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
> -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
> - -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=obj -o $@
> - clang $(NOSTDINC_FLAGS) $(LINUXINCLUDE) $(EXTRA_CFLAGS) \
> - -D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
> - -O2 -emit-llvm -c $< -o -| $(LLC) -march=bpf -filetype=asm -o $@.s
> + -O2 -target bpf -c $< -o $@
>
> I see far too many errors thrown starting with:
> ./arch/x86/include/asm/arch_hweight.h:31:10: error: invalid output constraint '=a' in asm
> : "="REG_OUT (res)
ahh. yes. when processing kernel headers clang has to assume x86 style
inline asm, though all of these functions will be ignored.
I don't have a quick fix for this yet.
Let's go back to your original change $(LLC)->llc
^ permalink raw reply
* Re: [PATCH 4/4] samples/bpf: Enable powerpc support
From: Alexei Starovoitov @ 2016-04-01 17:58 UTC (permalink / raw)
To: Naveen N. Rao
Cc: linux-kernel, linuxppc-dev, netdev, David S . Miller,
Daniel Borkmann
In-Reply-To: <20160401144131.GG17907@naverao1-tp.ibm.com>
On 4/1/16 7:41 AM, Naveen N. Rao wrote:
> On 2016/03/31 10:52AM, Alexei Starovoitov wrote:
>> On 3/31/16 4:25 AM, Naveen N. Rao wrote:
>> ...
>>> +
>>> +#ifdef __powerpc__
>>> +#define BPF_KPROBE_READ_RET_IP(ip, ctx) { (ip) = (ctx)->link; }
>>> +#define BPF_KRETPROBE_READ_RET_IP(ip, ctx) BPF_KPROBE_READ_RET_IP(ip, ctx)
>>> +#else
>>> +#define BPF_KPROBE_READ_RET_IP(ip, ctx) \
>>> + bpf_probe_read(&(ip), sizeof(ip), (void *)PT_REGS_RET(ctx))
>>> +#define BPF_KRETPROBE_READ_RET_IP(ip, ctx) \
>>> + bpf_probe_read(&(ip), sizeof(ip), \
>>> + (void *)(PT_REGS_FP(ctx) + sizeof(ip)))
>>
>> makes sense, but please use ({ }) gcc extension instead of {} and
>> open call to make sure that macro body is scoped.
>
> To be sure I understand this right, do you mean something like this?
>
> +
> +#ifdef __powerpc__
> +#define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ (ip) = (ctx)->link; })
> +#define BPF_KRETPROBE_READ_RET_IP BPF_KPROBE_READ_RET_IP
> +#else
> +#define BPF_KPROBE_READ_RET_IP(ip, ctx) ({ \
> + bpf_probe_read(&(ip), sizeof(ip), (void *)PT_REGS_RET(ctx)); })
> +#define BPF_KRETPROBE_READ_RET_IP(ip, ctx) ({ \
> + bpf_probe_read(&(ip), sizeof(ip), \
> + (void *)(PT_REGS_FP(ctx) + sizeof(ip))); })
> +#endif
yes. Thanks!
^ permalink raw reply
* [net PATCH 0/2] Fixes for GRO and GRE tunnels
From: Alexander Duyck @ 2016-04-01 18:05 UTC (permalink / raw)
To: herbert, tom, jesse, alexander.duyck, edumazet, netdev, davem
This pair of patches addresses a few issues I have discovered over the last
week or so concerning GRO and GRE tunnels.
The first patch addresses an item I called out as an issue with FOU/GUE
encapsulating GRE, and I finally had a chance to test it and verify that
the code concerning it was broken so I took the opportunity to fix it so
that we cannot generate a FOU/GUE frame that is encapsulating a GRE tunnel
with checksum while requesting TSO/GSO for the frame.
The second patch actually addresses something I realized was an issue if we
feed a tunnel through GRO and back out through GSO. Specifically it was
possible for GRO to generate overlapping IPv4 ID ranges as the outer IP IDs
were being ignored for tunnels. Ignoring the IP IDs like this should only
be valid if the DF bit is set. This is normally the case for IPIP, SIT,
and GRE tunnels, but not so for UDP tunnels. In the case that the DF bit
is not set we store off the fact that there was a delta from what we were
expecting and when we hit the inner-most header we validate the value as to
avoid generating a frame which could lead to an IP ID collision on packets
that could eventually be fragmented. A side effect is that the inner-most
IP ID test is relaxed as well, but the worst case scenario is that we GRO a
frame with a throw-away ID sequence anyway so if anything segmenting such a
frame with the wrong IP IDs should have no negative effects.
---
Alexander Duyck (2):
GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU
ipv4/GRO: Make GRO conform to RFC 6864
include/linux/netdevice.h | 5 ++++-
net/core/dev.c | 2 ++
net/ipv4/af_inet.c | 23 ++++++++++++++++-------
net/ipv4/fou.c | 6 ++++++
net/ipv4/gre_offload.c | 8 ++++++++
net/ipv4/ip_gre.c | 13 ++++++++++---
net/ipv6/ip6_offload.c | 3 ---
7 files changed, 46 insertions(+), 14 deletions(-)
^ permalink raw reply
* [net PATCH 1/2] GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU
From: Alexander Duyck @ 2016-04-01 18:05 UTC (permalink / raw)
To: herbert, tom, jesse, alexander.duyck, edumazet, netdev, davem
In-Reply-To: <20160401175741.13882.24175.stgit@localhost.localdomain>
This patch fixes an issue I found in which we were dropping frames if we
had enabled checksums on GRE headers that were encapsulated by either FOU
or GUE. Without this patch I was barely able to get 1 Gb/s of throughput.
With this patch applied I am now at least getting around 6 Gb/s.
The issue is due to the fact that with FOU or GUE applied we do not provide
a transport offset pointing to the GRE header, nor do we offload it in
software as the GRE header is completely skipped by GSO and treated like a
VXLAN or GENEVE type header. As such we need to prevent the stack from
generating it and also prevent GRE from generating it via any interface we
create.
Fixes: c3483384ee511 ("gro: Allow tunnel stacking in the case of FOU/GUE")
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
include/linux/netdevice.h | 5 ++++-
net/core/dev.c | 1 +
net/ipv4/fou.c | 6 ++++++
net/ipv4/gre_offload.c | 8 ++++++++
net/ipv4/ip_gre.c | 13 ++++++++++---
5 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cb0d5d09c2e4..8395308a2445 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2120,7 +2120,10 @@ struct napi_gro_cb {
/* Used in foo-over-udp, set in udp[46]_gro_receive */
u8 is_ipv6:1;
- /* 7 bit hole */
+ /* Used in GRE, set in fou/gue_gro_receive */
+ u8 is_fou:1;
+
+ /* 6 bit hole */
/* used to support CHECKSUM_COMPLETE for tunneling protocols */
__wsum csum;
diff --git a/net/core/dev.c b/net/core/dev.c
index b9bcbe77d913..77a71cd68535 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4439,6 +4439,7 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
NAPI_GRO_CB(skb)->flush = 0;
NAPI_GRO_CB(skb)->free = 0;
NAPI_GRO_CB(skb)->encap_mark = 0;
+ NAPI_GRO_CB(skb)->is_fou = 0;
NAPI_GRO_CB(skb)->gro_remcsum_start = 0;
/* Setup for GRO checksum validation */
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 5a94aea280d3..a39068b4a4d9 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -203,6 +203,9 @@ static struct sk_buff **fou_gro_receive(struct sk_buff **head,
*/
NAPI_GRO_CB(skb)->encap_mark = 0;
+ /* Flag this frame as already having an outer encap header */
+ NAPI_GRO_CB(skb)->is_fou = 1;
+
rcu_read_lock();
offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
ops = rcu_dereference(offloads[proto]);
@@ -368,6 +371,9 @@ static struct sk_buff **gue_gro_receive(struct sk_buff **head,
*/
NAPI_GRO_CB(skb)->encap_mark = 0;
+ /* Flag this frame as already having an outer encap header */
+ NAPI_GRO_CB(skb)->is_fou = 1;
+
rcu_read_lock();
offloads = NAPI_GRO_CB(skb)->is_ipv6 ? inet6_offloads : inet_offloads;
ops = rcu_dereference(offloads[guehdr->proto_ctype]);
diff --git a/net/ipv4/gre_offload.c b/net/ipv4/gre_offload.c
index c47539d04b88..6a5bd4317866 100644
--- a/net/ipv4/gre_offload.c
+++ b/net/ipv4/gre_offload.c
@@ -150,6 +150,14 @@ static struct sk_buff **gre_gro_receive(struct sk_buff **head,
if ((greh->flags & ~(GRE_KEY|GRE_CSUM)) != 0)
goto out;
+ /* We can only support GRE_CSUM if we can track the location of
+ * the GRE header. In the case of FOU/GUE we cannot because the
+ * outer UDP header displaces the GRE header leaving us in a state
+ * of limbo.
+ */
+ if ((greh->flags & GRE_CSUM) && NAPI_GRO_CB(skb)->is_fou)
+ goto out;
+
type = greh->protocol;
rcu_read_lock();
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 31936d387cfd..af5d1f38217f 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -862,9 +862,16 @@ static void __gre_tunnel_init(struct net_device *dev)
dev->hw_features |= GRE_FEATURES;
if (!(tunnel->parms.o_flags & TUNNEL_SEQ)) {
- /* TCP offload with GRE SEQ is not supported. */
- dev->features |= NETIF_F_GSO_SOFTWARE;
- dev->hw_features |= NETIF_F_GSO_SOFTWARE;
+ /* TCP offload with GRE SEQ is not supported, nor
+ * can we support 2 levels of outer headers requiring
+ * an update.
+ */
+ if (!(tunnel->parms.o_flags & TUNNEL_CSUM) ||
+ (tunnel->encap.type == TUNNEL_ENCAP_NONE)) {
+ dev->features |= NETIF_F_GSO_SOFTWARE;
+ dev->hw_features |= NETIF_F_GSO_SOFTWARE;
+ }
+
/* Can use a lockless transmit, unless we generate
* output sequences
*/
^ permalink raw reply related
* [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Alexander Duyck @ 2016-04-01 18:05 UTC (permalink / raw)
To: herbert, tom, jesse, alexander.duyck, edumazet, netdev, davem
In-Reply-To: <20160401175741.13882.24175.stgit@localhost.localdomain>
RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other
than fragmentation and reassembly. Currently we are looking at this field
as a way of identifying what frames can be aggregated and which cannot for
GRO. While this is valid for frames that do not have DF set, it is invalid
to do so if the bit is set.
In addition we were generating IPv4 ID collisions when 2 or more flows were
interleaved over the same tunnel. To prevent that we store the result of
all IP ID checks via a "|=" instead of overwriting previous values.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
---
net/core/dev.c | 1 +
net/ipv4/af_inet.c | 23 ++++++++++++++++-------
net/ipv6/ip6_offload.c | 3 ---
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 77a71cd68535..3429632398a4 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4352,6 +4352,7 @@ static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
unsigned long diffs;
NAPI_GRO_CB(p)->flush = 0;
+ NAPI_GRO_CB(p)->flush_id = 0;
if (hash != skb_get_hash_raw(p)) {
NAPI_GRO_CB(p)->same_flow = 0;
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 9e481992dbae..7d8733393934 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1347,14 +1347,23 @@ static struct sk_buff **inet_gro_receive(struct sk_buff **head,
(iph->tos ^ iph2->tos) |
((iph->frag_off ^ iph2->frag_off) & htons(IP_DF));
- /* Save the IP ID check to be included later when we get to
- * the transport layer so only the inner most IP ID is checked.
- * This is because some GSO/TSO implementations do not
- * correctly increment the IP ID for the outer hdrs.
- */
- NAPI_GRO_CB(p)->flush_id =
- ((u16)(ntohs(iph2->id) + NAPI_GRO_CB(p)->count) ^ id);
NAPI_GRO_CB(p)->flush |= flush;
+
+ /* For non-atomic datagrams we need to save the IP ID offset
+ * to be included later. If the frame has the DF bit set
+ * we must ignore the IP ID value as per RFC 6864.
+ */
+ if (iph2->frag_off & htons(IP_DF))
+ continue;
+
+ /* We must save the offset as it is possible to have multiple
+ * flows using the same protocol and address pairs so we
+ * need to wait until we can validate this is part of the
+ * same flow with a 5-tuple or better to avoid unnecessary
+ * collisions between flows.
+ */
+ NAPI_GRO_CB(p)->flush_id |= ntohs(iph2->id) ^
+ (u16)(id - NAPI_GRO_CB(p)->count);
}
NAPI_GRO_CB(skb)->flush |= flush;
diff --git a/net/ipv6/ip6_offload.c b/net/ipv6/ip6_offload.c
index 82e9f3076028..9aa53f64dffd 100644
--- a/net/ipv6/ip6_offload.c
+++ b/net/ipv6/ip6_offload.c
@@ -238,9 +238,6 @@ static struct sk_buff **ipv6_gro_receive(struct sk_buff **head,
/* flush if Traffic Class fields are different */
NAPI_GRO_CB(p)->flush |= !!(first_word & htonl(0x0FF00000));
NAPI_GRO_CB(p)->flush |= flush;
-
- /* Clear flush_id, there's really no concept of ID in IPv6. */
- NAPI_GRO_CB(p)->flush_id = 0;
}
NAPI_GRO_CB(skb)->flush |= flush;
^ permalink raw reply related
* Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF
From: Alexei Starovoitov @ 2016-04-01 18:10 UTC (permalink / raw)
To: Naveen N. Rao, linux-kernel, linuxppc-dev
Cc: oss, Matt Evans, Michael Ellerman, Paul Mackerras,
David S. Miller, Ananth N Mavinakayanahalli, netdev,
Daniel Borkmann
In-Reply-To: <b58a289b51bbce73f8539290b721a5d461b7cebb.1459504224.git.naveen.n.rao@linux.vnet.ibm.com>
On 4/1/16 2:58 AM, Naveen N. Rao wrote:
> PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2.
>
> Enable with:
> echo 1 > /proc/sys/net/core/bpf_jit_enable
> or
> echo 2 > /proc/sys/net/core/bpf_jit_enable
>
> ... to see the generated JIT code. This can further be processed with
> tools/net/bpf_jit_disasm.
>
> With CONFIG_TEST_BPF=m and 'modprobe test_bpf':
> test_bpf: Summary: 291 PASSED, 0 FAILED, [234/283 JIT'ed]
>
> ... on both ppc64 BE and LE.
>
> The details of the approach are documented through various comments in
> the code, as are the TODOs. Some of the prominent TODOs include
> implementing BPF tail calls and skb loads.
>
> Cc: Matt Evans <matt@ozlabs.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 19 +-
> arch/powerpc/net/Makefile | 4 +
> arch/powerpc/net/bpf_jit.h | 66 ++-
> arch/powerpc/net/bpf_jit64.h | 58 +++
> arch/powerpc/net/bpf_jit_comp64.c | 828 ++++++++++++++++++++++++++++++++++
> 5 files changed, 973 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/net/bpf_jit64.h
> create mode 100644 arch/powerpc/net/bpf_jit_comp64.c
...
> -#ifdef CONFIG_PPC64
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
impressive stuff!
Everything nicely documented. Could you add few words for the above
condition as well ?
Or may be a new macro, since it occurs many times?
What are these _CALL_ELF == 2 and != 2 conditions mean? ppc ABIs ?
Will there ever be v3 ?
So far most of the bpf jits were going via net-next tree, but if
in this case no changes to the core is necessary then I guess it's fine
to do it via powerpc tree. What's your plan?
^ permalink raw reply
* Re: Question on rhashtable in worst-case scenario.
From: Ben Greear @ 2016-04-01 18:17 UTC (permalink / raw)
To: Herbert Xu, Johannes Berg
Cc: David Miller, linux-kernel, linux-wireless, netdev, tgraf
In-Reply-To: <20160401004627.GA9367@gondor.apana.org.au>
On 03/31/2016 05:46 PM, Herbert Xu wrote:
> On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote:
>>
>> Does removing this completely disable the "-EEXIST" error? I can't say
>> I fully understand the elasticity stuff in __rhashtable_insert_fast().
>
> What EEXIST error are you talking about? The only one that can be
> returned on insertion is if you're explicitly checking for dups
> which clearly can't be the case for you.
>
> If you're talking about the EEXIST error due to a rehash then it is
> completely hidden from you by rhashtable_insert_rehash.
>
> If you actually meant EBUSY then yes this should prevent it from
> occurring, unless your chain-length exceeds 2^32.
EEXIST was on removal, and was a symptom of the failure to insert, not
really a problem itself.
I reverted my revert (ie, back to rhashtable), added Johanne's patch
to check insertion (and added my on pr_err there).
I also added this:
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 38ef0be..c25b945 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -66,6 +66,7 @@
static const struct rhashtable_params sta_rht_params = {
.nelem_hint = 3, /* start small */
+ .insecure_elasticity = true, /* Disable chain-length checks. */
.automatic_shrinking = true,
.head_offset = offsetof(struct sta_info, hash_node),
.key_offset = offsetof(struct sta_info, addr),
Now, my test case seems to pass, though I did have one strange issue
before I put in the pr_err. I'm not sure if it was a hashtable issue
or something else..but I have lots of something-else going on in this system,
so I'd say that likely the patch above fixes rhashtable for my use case.
I will of course let you know if I run into more issues that appear
to be hashtable related!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* [PATCH] Marvell phy: add fiber status check for some components
From: Charles-Antoine Couret @ 2016-04-01 16:01 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: marvell.patch --]
[-- Type: text/x-patch, Size: 2543 bytes --]
>From a5a7a9828511ff6a522cf742109768207ff89929 Mon Sep 17 00:00:00 2001
From: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
Date: Fri, 1 Apr 2016 16:16:35 +0200
Subject: [PATCH] Marvell phy: add fiber status check for some components
This patch is not tested with all Marvell's phy. The new function was actived
only for tested phys.
Signed-off-by: Charles-Antoine Couret <charles-antoine.couret@nexvision.fr>
---
drivers/net/phy/marvell.c | 37 +++++++++++++++++++++++++++++++++++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index ab1d0fc..5ac186e 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -890,6 +890,39 @@ static int marvell_read_status(struct phy_device *phydev)
return 0;
}
+/* marvell_read_fiber_status
+ *
+ * Some Marvell's phys have two modes: fiber and copper.
+ * Both need status checked.
+ * Description:
+ * First, check the fiber link and status.
+ * If the fiber link is down, check the copper link and status which
+ * will be the default value if both link are down.
+ */
+static int marvell_read_fiber_status(struct phy_device *phydev)
+{
+ int err;
+
+ /* Check the fiber mode first */
+ err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_FIBER);
+ if (err < 0)
+ return err;
+
+ err = marvell_read_status(phydev);
+ if (err < 0)
+ return err;
+
+ if (phydev->link)
+ return 0;
+
+ /* If fiber link is down, check and save copper mode state */
+ err = phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_M1111_COPPER);
+ if (err < 0)
+ return err;
+
+ return marvell_read_status(phydev);
+}
+
static int marvell_aneg_done(struct phy_device *phydev)
{
int retval = phy_read(phydev, MII_M1011_PHY_STATUS);
@@ -1122,7 +1155,7 @@ static struct phy_driver marvell_drivers[] = {
.probe = marvell_probe,
.config_init = &m88e1111_config_init,
.config_aneg = &marvell_config_aneg,
- .read_status = &marvell_read_status,
+ .read_status = &marvell_read_fiber_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.resume = &genphy_resume,
@@ -1270,7 +1303,7 @@ static struct phy_driver marvell_drivers[] = {
.probe = marvell_probe,
.config_init = &marvell_config_init,
.config_aneg = &m88e1510_config_aneg,
- .read_status = &marvell_read_status,
+ .read_status = &marvell_read_fiber_status,
.ack_interrupt = &marvell_ack_interrupt,
.config_intr = &marvell_config_intr,
.did_interrupt = &m88e1121_did_interrupt,
--
2.5.5
^ permalink raw reply related
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: David Miller @ 2016-04-01 18:33 UTC (permalink / raw)
To: daniel
Cc: hannes, alexei.starovoitov, eric.dumazet, netdev, sasha.levin,
mkubecek
In-Reply-To: <56FE2CE3.9080805@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 01 Apr 2016 10:10:11 +0200
> Dave, do you need me to resubmit this one w/o changes:
> http://patchwork.ozlabs.org/patch/603903/ ?
I'll apply this and queue it up for -stable, thanks.
^ permalink raw reply
* Re: [RFC PATCH 6/6] ppc: ebpf/jit: Implement JIT compiler for extended BPF
From: Daniel Borkmann @ 2016-04-01 18:34 UTC (permalink / raw)
To: Alexei Starovoitov, Naveen N. Rao, linux-kernel, linuxppc-dev
Cc: oss, Matt Evans, Michael Ellerman, Paul Mackerras,
David S. Miller, Ananth N Mavinakayanahalli, netdev
In-Reply-To: <56FEB9AD.2080401@fb.com>
On 04/01/2016 08:10 PM, Alexei Starovoitov wrote:
> On 4/1/16 2:58 AM, Naveen N. Rao wrote:
>> PPC64 eBPF JIT compiler. Works for both ABIv1 and ABIv2.
>>
>> Enable with:
>> echo 1 > /proc/sys/net/core/bpf_jit_enable
>> or
>> echo 2 > /proc/sys/net/core/bpf_jit_enable
>>
>> ... to see the generated JIT code. This can further be processed with
>> tools/net/bpf_jit_disasm.
>>
>> With CONFIG_TEST_BPF=m and 'modprobe test_bpf':
>> test_bpf: Summary: 291 PASSED, 0 FAILED, [234/283 JIT'ed]
>>
>> ... on both ppc64 BE and LE.
>>
>> The details of the approach are documented through various comments in
>> the code, as are the TODOs. Some of the prominent TODOs include
>> implementing BPF tail calls and skb loads.
>>
>> Cc: Matt Evans <matt@ozlabs.org>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Alexei Starovoitov <ast@fb.com>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
>> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/include/asm/ppc-opcode.h | 19 +-
>> arch/powerpc/net/Makefile | 4 +
>> arch/powerpc/net/bpf_jit.h | 66 ++-
>> arch/powerpc/net/bpf_jit64.h | 58 +++
>> arch/powerpc/net/bpf_jit_comp64.c | 828 ++++++++++++++++++++++++++++++++++
>> 5 files changed, 973 insertions(+), 2 deletions(-)
>> create mode 100644 arch/powerpc/net/bpf_jit64.h
>> create mode 100644 arch/powerpc/net/bpf_jit_comp64.c
> ...
>> -#ifdef CONFIG_PPC64
>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF != 2)
>
> impressive stuff!
+1, awesome to see another one!
> Everything nicely documented. Could you add few words for the above
> condition as well ?
> Or may be a new macro, since it occurs many times?
> What are these _CALL_ELF == 2 and != 2 conditions mean? ppc ABIs ?
> Will there ever be v3 ?
Minor TODO would also be to convert to use bpf_jit_binary_alloc() and
bpf_jit_binary_free() API for the image, which is done by other eBPF
jits, too.
> So far most of the bpf jits were going via net-next tree, but if
> in this case no changes to the core is necessary then I guess it's fine
> to do it via powerpc tree. What's your plan?
>
^ permalink raw reply
* Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get
From: Daniel Borkmann @ 2016-04-01 18:36 UTC (permalink / raw)
To: David Miller
Cc: hannes, alexei.starovoitov, eric.dumazet, netdev, sasha.levin,
mkubecek
In-Reply-To: <20160401.143358.1963393066215816255.davem@davemloft.net>
On 04/01/2016 08:33 PM, David Miller wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
> Date: Fri, 01 Apr 2016 10:10:11 +0200
>
>> Dave, do you need me to resubmit this one w/o changes:
>> http://patchwork.ozlabs.org/patch/603903/ ?
>
> I'll apply this and queue it up for -stable, thanks.
Ok, thanks!
^ permalink raw reply
* Re: [PATCH] net: mvpp2: fix maybe-uninitialized warning
From: David Miller @ 2016-04-01 18:37 UTC (permalink / raw)
To: jszhang; +Cc: mw, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1459414883-6295-1-git-send-email-jszhang@marvell.com>
From: Jisheng Zhang <jszhang@marvell.com>
Date: Thu, 31 Mar 2016 17:01:23 +0800
> This is to fix the following maybe-uninitialized warning:
>
> drivers/net/ethernet/marvell/mvpp2.c:6007:18: warning: 'err' may be
> used uninitialized in this function [-Wmaybe-uninitialized]
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git) 0/3] stmmac MDIO and normal descr fixes
From: David Miller @ 2016-04-01 18:39 UTC (permalink / raw)
To: peppe.cavallaro
Cc: netdev, gabriel.fernandez, afaerber, fschaefer.oss, dinh.linux,
preid, rhgadsdon, linux-kernel
In-Reply-To: <1459494436-27386-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Fri, 1 Apr 2016 09:07:13 +0200
> This patch series is to fix the problems below and recently debugged
> in this mailing list:
>
> o to fix a problem for the HW where the normal descriptor
> o to fix the mdio registration according to the different
> platform configurations
>
> I am resending all the patches again: built on top of net.git repo.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] bridge: remove br_dev_set_multicast_list
From: David Miller @ 2016-04-01 18:43 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1459498570-30664-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 1 Apr 2016 16:16:10 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> remove br_dev_set_multicast_list which does nothing
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
This will break SIOCADDMULTI et al. on the bridge, see net/core/dev.c
which checks whether this ndo OP is NULL or not.
Please sufficiently grep the source tree on how an ndo operation is
used before making changes like this.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: mvpp2: use cache_line_size() to get cacheline size
From: David Miller @ 2016-04-01 18:43 UTC (permalink / raw)
To: jszhang; +Cc: mw, netdev, linux-kernel, linux-arm-kernel, thomas.petazzoni
In-Reply-To: <1459501865-7033-1-git-send-email-jszhang@marvell.com>
From: Jisheng Zhang <jszhang@marvell.com>
Date: Fri, 1 Apr 2016 17:11:05 +0800
> L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
> to determine the cacheline size in runtime.
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> Suggested-by: Marcin Wojtas <mw@semihalf.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: mvneta: use cache_line_size() to get cacheline size
From: David Miller @ 2016-04-01 18:44 UTC (permalink / raw)
To: jszhang; +Cc: mw, thomas.petazzoni, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1459501969-7083-1-git-send-email-jszhang@marvell.com>
From: Jisheng Zhang <jszhang@marvell.com>
Date: Fri, 1 Apr 2016 17:12:49 +0800
> L1_CACHE_BYTES may not be the real cacheline size, use cache_line_size
> to determine the cacheline size in runtime.
>
> Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
> Suggested-by: Marcin Wojtas <mw@semihalf.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] ipv6: rework the lock in addrconf_permanent_addr
From: David Miller @ 2016-04-01 18:44 UTC (permalink / raw)
To: roy.qing.li; +Cc: netdev
In-Reply-To: <1459502818-24939-1-git-send-email-roy.qing.li@gmail.com>
From: roy.qing.li@gmail.com
Date: Fri, 1 Apr 2016 17:26:58 +0800
> From: Li RongQing <roy.qing.li@gmail.com>
>
> 1. nothing of idev is changed, so read lock is enough
> 2. ifp is changed, so used ifp->lock or cmpxchg to protect it
>
> Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
You posted this patch twice and didn't post patch 2/2.
I'm tossing this from patchwork, please resubmit this
properly.
^ permalink raw reply
* Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Eric Dumazet @ 2016-04-01 18:49 UTC (permalink / raw)
To: Alexander Duyck
Cc: herbert, tom, jesse, alexander.duyck, edumazet, netdev, davem
In-Reply-To: <20160401180531.13882.44793.stgit@localhost.localdomain>
On Fri, 2016-04-01 at 11:05 -0700, Alexander Duyck wrote:
> RFC 6864 states that the IPv4 ID field MUST NOT be used for purposes other
> than fragmentation and reassembly. Currently we are looking at this field
> as a way of identifying what frames can be aggregated and which cannot for
> GRO. While this is valid for frames that do not have DF set, it is invalid
> to do so if the bit is set.
>
> In addition we were generating IPv4 ID collisions when 2 or more flows were
> interleaved over the same tunnel. To prevent that we store the result of
> all IP ID checks via a "|=" instead of overwriting previous values.
Note that for atomic datagrams (DF = 1), since fragmentation and
reassembly can not occur, maybe some people use ID field for other
purposes.
For example, TCP stack tracks per socket ID generation, even if it sends
DF=1 frames. Damn useful for tcpdump analysis and drop inference.
With your change, the resulting GRO packet would propagate the ID of
first frag. Most GSO/GSO engines will then provide a ID sequence, which
might not match original packets.
I do not particularly care, but it is worth mentioning that GRO+TSO
would not be idempotent anymore.
^ permalink raw reply
* Re: [PATCH net] vlan: pull on __vlan_insert_tag error path and fix csum correction
From: David Miller @ 2016-04-01 19:00 UTC (permalink / raw)
To: daniel; +Cc: jiri, alexei.starovoitov, jesse, tom, netdev
In-Reply-To: <244f8d5684800cc98545932aa6851bf73f7326e2.1459503053.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 1 Apr 2016 11:41:03 +0200
> Moreover, I noticed that when in the non-error path the __skb_pull()
> is done and the original offset to mac header was non-zero, we fixup
> from a wrong skb->data offset in the checksum complete processing.
>
> So the skb_postpush_rcsum() really needs to be done before __skb_pull()
> where skb->data still points to the mac header start.
Ugh, what a mess, are you sure any of this is right even after your
change? What happens (outside of the csum part) is this:
__skb_push(offset);
__vlan_insert_tag(); {
skb_push(VLAN_HLEN);
...
memmove(skb->data, skb->data + VLAN_HLEN, 2 * ETH_ALEN);
}
__skb_pull(offset);
If I understand this correctly, the last pull will therefore put
skb->data pointing at vlan_ethhdr->h_vlan_TCI of the new VLAN header
pushed by __vlan_insert_tag().
That is assuming skb->data began right after the original ethernet
header.
To me, that postpull csum currently is absolutely in the correct spot,
because it's acting upon the pull done by __vlan_insert_tag(), not the
one done here by skb_vlan_push().
Right?
Can you tell me how you tested this? Just curious...
^ permalink raw reply
* Re: [v7, 4/5] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Stephen Boyd @ 2016-04-01 19:03 UTC (permalink / raw)
To: Yangbo Lu, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mmc-u79uwXL29TY76Z2rM5mHXA
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, Zhao Qiang, Russell King,
Bhupesh Sharma, Santosh Shilimkar, Jochen Friedrich,
scott.wood-3arQi8VN3Tc, Rob Herring, Claudiu Manoil, Kumar Gala,
leoyang.li-3arQi8VN3Tc, xiaobo.xie-3arQi8VN3Tc
In-Reply-To: <1459480051-3701-5-git-send-email-yangbo.lu-3arQi8VN3Tc@public.gmane.org>
On 03/31/2016 08:07 PM, Yangbo Lu wrote:
> drivers/clk/clk-qoriq.c | 3 +--
>
For clk part:
Acked-by: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] net: mvneta: fix changing MTU when using per-cpu processing
From: David Miller @ 2016-04-01 19:18 UTC (permalink / raw)
To: mw
Cc: linux-kernel, linux-arm-kernel, netdev, linux,
sebastian.hesselbarth, andrew, jason, thomas.petazzoni,
gregory.clement, nadavh, alior, nitroshift, jaz
In-Reply-To: <1459516878-2802-1-git-send-email-mw@semihalf.com>
From: Marcin Wojtas <mw@semihalf.com>
Date: Fri, 1 Apr 2016 15:21:18 +0200
> After enabling per-cpu processing it appeared that under heavy load
> changing MTU can result in blocking all port's interrupts and transmitting
> data is not possible after the change.
>
> This commit fixes above issue by disabling percpu interrupts for the
> time, when TXQs and RXQs are reconfigured.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Applied, thanks.
When I reviewed this I was worried that this was yet another case where
the ndo op could be invoked in a potentially atomic or similar context,
whereby on_each_cpu() would be illegal to use.
But that appears to not be the case, and thus this change is just fine.
Thanks.
^ permalink raw reply
* Re: [net PATCH 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: David Miller @ 2016-04-01 19:24 UTC (permalink / raw)
To: eric.dumazet
Cc: aduyck, herbert, tom, jesse, alexander.duyck, edumazet, netdev
In-Reply-To: <1459536543.6473.289.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 01 Apr 2016 11:49:03 -0700
> For example, TCP stack tracks per socket ID generation, even if it
> sends DF=1 frames. Damn useful for tcpdump analysis and drop
> inference.
Thanks for mentioning this, I never considered this use case.
> With your change, the resulting GRO packet would propagate the ID of
> first frag. Most GSO/GSO engines will then provide a ID sequence,
> which might not match original packets.
>
> I do not particularly care, but it is worth mentioning that GRO+TSO
> would not be idempotent anymore.
Our eventual plan was to start emitting zero in the ID field for
outgoing TCP datagrams with DF set, since the issue that caused us to
generate incrementing IDs in the first place (buggy Microsoft SLHC
compression) we decided is not relevant and important enough to
accommodate any more.
So outside of your TCP behavior analysis case, there isn't a
compelling argument to keeping that code around any more, rather than
just put zero in the ID field.
I suppose we could keep the counter code around and allow it to be
enabled using a sysctl or socket option, but how strongly do you
really feel about this?
^ permalink raw reply
* [RFC v3 -next 0/2] virtio-net: Advised MTU feature
From: Aaron Conole @ 2016-04-01 19:32 UTC (permalink / raw)
To: netdev, Michael S. Tsirkin, virtualization, linux-kernel,
Paolo Abeni, Sergei Shtylyov, Pankaj Gupta
The following series adds the ability for a hypervisor to set an MTU on the
guest during feature negotiation phase. This is useful for VM orchestration
when, for instance, tunneling is involved and the MTU of the various systems
should be homogenous.
The first patch adds the feature bit as described in the proposed VIRTIO spec
addition found at
https://lists.oasis-open.org/archives/virtio-dev/201603/msg00001.html
The second patch adds a user of the bit, and a warning when the guest changes
the MTU from the hypervisor advised MTU. Future patches may add more thorough
error handling.
v2:
* Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni
* Additional test before printing a warning
v3:
* Removed the warning when changing MTU (which simplified the code)
Aaron Conole (2):
virtio: Start feature MTU support
virtio_net: Read the advised MTU
drivers/net/virtio_net.c | 8 ++++++++
include/uapi/linux/virtio_net.h | 3 +++
2 files changed, 11 insertions(+)
--
2.5.5
^ permalink raw reply
* [RFC v3 -net 1/2] virtio: Start feature MTU support
From: Aaron Conole @ 2016-04-01 19:32 UTC (permalink / raw)
To: netdev, Michael S. Tsirkin, virtualization, linux-kernel,
Paolo Abeni, Sergei Shtylyov, Pankaj Gupta
In-Reply-To: <1459539136-13948-1-git-send-email-aconole@redhat.com>
This commit adds the feature bit and associated mtu device entry for the
virtio network device. Future commits will make use of these bits to support
negotiated MTU.
Signed-off-by: Aaron Conole <aconole@bytheb.org>
---
v2,v3:
* No change
include/uapi/linux/virtio_net.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
index ec32293..41a6a01 100644
--- a/include/uapi/linux/virtio_net.h
+++ b/include/uapi/linux/virtio_net.h
@@ -55,6 +55,7 @@
#define VIRTIO_NET_F_MQ 22 /* Device supports Receive Flow
* Steering */
#define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
+#define VIRTIO_NET_F_MTU 25 /* Device supports Default MTU Negotiation */
#ifndef VIRTIO_NET_NO_LEGACY
#define VIRTIO_NET_F_GSO 6 /* Host handles pkts w/ any GSO type */
@@ -73,6 +74,8 @@ struct virtio_net_config {
* Legal values are between 1 and 0x8000
*/
__u16 max_virtqueue_pairs;
+ /* Default maximum transmit unit advice */
+ __u16 mtu;
} __attribute__((packed));
/*
--
2.5.5
^ permalink raw reply related
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