* Re: [PATCH net] ipv6: sr: fix scheduling in RCU when creating seg6 lwtunnel state
From: David Lebrun @ 2018-03-20 17:11 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: David Lebrun, Roopa Prabhu
In-Reply-To: <be3808c5-e860-c4b8-b87a-3d9582b03795@gmail.com>
On 20/03/18 15:07, Eric Dumazet wrote:
> This is not the proper fix.
>
> Control path holds RTNL and can sleeep if needed.
>
> RCU should be avoided in lwtunnel_build_state()
>
+Roopa
In lwtunnel_build_state(), the RCU protects the lwtunnel_encap_ops "ops"
which is rcu-dereferenced. Moreover, the lwtunnel_state_alloc()
function, which is used in all build_state functions, also uses
GFP_ATOMIC, so this seemed a proper fix, or at least proper mitigation.
Do you suggest that the lwtunnel_encap_ops can be protected in a
different way, not requiring RCU ?
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Ben Greear @ 2018-03-20 17:07 UTC (permalink / raw)
To: Liran Alon, Eric W. Biederman
Cc: shmulik.ladkani, netdev, mrv, daniel, davem, linux-kernel,
yuval.shaia, idan.brown
In-Reply-To: <5AB13A86.9010607@ORACLE.COM>
On 03/20/2018 09:44 AM, Liran Alon wrote:
>
>
> On 20/03/18 18:24, ebiederm@xmission.com wrote:
>>
>> I don't believe the current behavior is a bug.
>>
>> I looked through the history. Basically skb_scrub_packet
>> started out as the scrubbing needed for crossing network
>> namespaces.
>>
>> Then tunnels which needed 90% of the functionality started
>> calling it, with the xnet flag added. Because the tunnels
>> needed to preserve their historic behavior.
>>
>> Then dev_forward_skb started calling skb_scrub_packet.
>>
>> A veth pair is supposed to give the same behavior as a cross-over
>> cable plugged into two local nics. A cross over cable won't
>> preserve things like the skb mark. So I don't see why anyone would
>> expect a veth pair to preserve the mark.
>
> I disagree with this argument.
>
> I think that a skb crossing netns is what simulates a real packet crossing physical computers. Following your argument, why would skb->mark should be preserved
> when crossing netdevs on same netns via routing? But this does today preserve skb->mark.
>
> Therefore, I do think that skb->mark should conceptually only be scrubbed when crossing netns. Regardless of the netdev used to cross it.
It should be scrubbed in VETH as well. That is one way to make virtual routers. Possibly
the newer VRF features will give another better way to do it, but you should not break
things that used to work.
Now, if you want to add a new feature that allows one to configure the kernel (or VETH) for
a new behavior, then that might be something to consider.
>> Right now I don't see the point of handling packets that don't cross
>> network namespace boundaries specially, other than to preserve backwards
>> compatibility.
Well, backwards compat is a big deal all by itself!
Thanks,
Ben
>>
>> Eric
>>
>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH v3 net] net/ipv6: Handle onlink flag with multipath routes
From: David Ahern @ 2018-03-20 17:06 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
For multipath routes the ONLINK flag can be specified per nexthop in
rtnh_flags or globally in rtm_flags. Update ip6_route_multipath_add
to consider the ONLINK setting coming from rtnh_flags. Each loop over
nexthops the config for the sibling route is initialized to the global
config and then per nexthop settings overlayed. The flag is 'or'ed into
fib6_config to handle the ONLINK flag coming from either rtm_flags or
rtnh_flags.
Fixes: fc1e64e1092f ("net/ipv6: Add support for onlink flag")
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v3
- no change; resend because patchworks shows v2 as superseded
v2
- updated commit message to reflect flag can be global or per-nexthop
and both need to be handled
net/ipv6/route.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index b3c1137ad0b8..b0d5c64e1978 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4112,6 +4112,7 @@ static int ip6_route_multipath_add(struct fib6_config *cfg,
r_cfg.fc_encap_type = nla_get_u16(nla);
}
+ r_cfg.fc_flags |= (rtnh->rtnh_flags & RTNH_F_ONLINK);
rt = ip6_route_info_create(&r_cfg, extack);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
--
2.11.0
^ permalink raw reply related
* [PATCH net-next] fib_rules: rename FRA_PROTOCOL to FRA_ORIGINATOR
From: Nicolas Dichtel @ 2018-03-20 17:04 UTC (permalink / raw)
To: davem; +Cc: netdev, Nicolas Dichtel, Donald Sharp
As the comment said, this attribute defines the originator of the rule,
it's not really a (network) protocol.
Let's rename it accordingly to avoid confusion (difference between
FRA_PROTOCOL and FRA_IP_PROTO was not obvious).
CC: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
FRA_PROTOCOL exists only in net-next for now, thus it's still possible to
rename it.
drivers/net/vrf.c | 4 ++--
include/net/fib_rules.h | 4 ++--
include/uapi/linux/fib_rules.h | 2 +-
net/core/fib_rules.c | 14 +++++++-------
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index c6be49d3a9eb..8f559b74404d 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -1146,7 +1146,7 @@ static inline size_t vrf_fib_rule_nl_size(void)
sz = NLMSG_ALIGN(sizeof(struct fib_rule_hdr));
sz += nla_total_size(sizeof(u8)); /* FRA_L3MDEV */
sz += nla_total_size(sizeof(u32)); /* FRA_PRIORITY */
- sz += nla_total_size(sizeof(u8)); /* FRA_PROTOCOL */
+ sz += nla_total_size(sizeof(u8)); /* FRA_ORIGINATOR */
return sz;
}
@@ -1177,7 +1177,7 @@ static int vrf_fib_rule(const struct net_device *dev, __u8 family, bool add_it)
frh->family = family;
frh->action = FR_ACT_TO_TBL;
- if (nla_put_u8(skb, FRA_PROTOCOL, RTPROT_KERNEL))
+ if (nla_put_u8(skb, FRA_ORIGINATOR, RTPROT_KERNEL))
goto nla_put_failure;
if (nla_put_u8(skb, FRA_L3MDEV, 1))
diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
index e5cfcfc7dd93..8ff89beea845 100644
--- a/include/net/fib_rules.h
+++ b/include/net/fib_rules.h
@@ -26,7 +26,7 @@ struct fib_rule {
u32 table;
u8 action;
u8 l3mdev;
- u8 proto;
+ u8 originator;
u8 ip_proto;
u32 target;
__be64 tun_id;
@@ -113,7 +113,7 @@ struct fib_rule_notifier_info {
[FRA_GOTO] = { .type = NLA_U32 }, \
[FRA_L3MDEV] = { .type = NLA_U8 }, \
[FRA_UID_RANGE] = { .len = sizeof(struct fib_rule_uid_range) }, \
- [FRA_PROTOCOL] = { .type = NLA_U8 }, \
+ [FRA_ORIGINATOR] = { .type = NLA_U8 }, \
[FRA_IP_PROTO] = { .type = NLA_U8 }, \
[FRA_SPORT_RANGE] = { .len = sizeof(struct fib_rule_port_range) }, \
[FRA_DPORT_RANGE] = { .len = sizeof(struct fib_rule_port_range) }
diff --git a/include/uapi/linux/fib_rules.h b/include/uapi/linux/fib_rules.h
index 232df14e1287..6bb950a9144b 100644
--- a/include/uapi/linux/fib_rules.h
+++ b/include/uapi/linux/fib_rules.h
@@ -63,7 +63,7 @@ enum {
FRA_PAD,
FRA_L3MDEV, /* iif or oif is l3mdev goto its table */
FRA_UID_RANGE, /* UID range */
- FRA_PROTOCOL, /* Originator of the rule */
+ FRA_ORIGINATOR, /* Originator of the rule */
FRA_IP_PROTO, /* ip proto */
FRA_SPORT_RANGE, /* sport */
FRA_DPORT_RANGE, /* dport */
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index f6f04fc0f629..c81dc0600dc4 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -55,7 +55,7 @@ int fib_default_rule_add(struct fib_rules_ops *ops,
r->pref = pref;
r->table = table;
r->flags = flags;
- r->proto = RTPROT_KERNEL;
+ r->originator = RTPROT_KERNEL;
r->fr_net = ops->fro_net;
r->uid_range = fib_kuid_range_unset;
@@ -505,8 +505,8 @@ int fib_nl_newrule(struct sk_buff *skb, struct nlmsghdr *nlh,
rule->pref = tb[FRA_PRIORITY] ? nla_get_u32(tb[FRA_PRIORITY])
: fib_default_rule_pref(ops);
- rule->proto = tb[FRA_PROTOCOL] ?
- nla_get_u8(tb[FRA_PROTOCOL]) : RTPROT_UNSPEC;
+ rule->originator = tb[FRA_ORIGINATOR] ?
+ nla_get_u8(tb[FRA_ORIGINATOR]) : RTPROT_UNSPEC;
if (tb[FRA_IIFNAME]) {
struct net_device *dev;
@@ -736,8 +736,8 @@ int fib_nl_delrule(struct sk_buff *skb, struct nlmsghdr *nlh,
}
list_for_each_entry(rule, &ops->rules_list, list) {
- if (tb[FRA_PROTOCOL] &&
- (rule->proto != nla_get_u8(tb[FRA_PROTOCOL])))
+ if (tb[FRA_ORIGINATOR] &&
+ (rule->originator != nla_get_u8(tb[FRA_ORIGINATOR])))
continue;
if (frh->action && (frh->action != rule->action))
@@ -870,7 +870,7 @@ static inline size_t fib_rule_nlmsg_size(struct fib_rules_ops *ops,
+ nla_total_size(4) /* FRA_FWMASK */
+ nla_total_size_64bit(8) /* FRA_TUN_ID */
+ nla_total_size(sizeof(struct fib_kuid_range))
- + nla_total_size(1) /* FRA_PROTOCOL */
+ + nla_total_size(1) /* FRA_ORIGINATOR */
+ nla_total_size(1) /* FRA_IP_PROTO */
+ nla_total_size(sizeof(struct fib_rule_port_range)) /* FRA_SPORT_RANGE */
+ nla_total_size(sizeof(struct fib_rule_port_range)); /* FRA_DPORT_RANGE */
@@ -904,7 +904,7 @@ static int fib_nl_fill_rule(struct sk_buff *skb, struct fib_rule *rule,
frh->action = rule->action;
frh->flags = rule->flags;
- if (nla_put_u8(skb, FRA_PROTOCOL, rule->proto))
+ if (nla_put_u8(skb, FRA_ORIGINATOR, rule->originator))
goto nla_put_failure;
if (rule->action == FR_ACT_GOTO &&
--
2.15.1
^ permalink raw reply related
* [PATCH v3 net-next] selftests: Add multipath tests for onlink flag
From: David Ahern @ 2018-03-20 17:04 UTC (permalink / raw)
To: netdev; +Cc: David Ahern
Add multipath tests for onlink flag: one test with onlink added to
both nexthops, then tests with onlink added to only 1 nexthop.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
v3
- no change; resend because of patchworks shows v2 as superseded
v2
- add ipv6 test for onlink flag set globally as well as per-nexthop
tools/testing/selftests/net/fib-onlink-tests.sh | 98 ++++++++++++++++++++++++-
1 file changed, 95 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/net/fib-onlink-tests.sh b/tools/testing/selftests/net/fib-onlink-tests.sh
index 06b1d7cc12cc..3991ad1a368d 100755
--- a/tools/testing/selftests/net/fib-onlink-tests.sh
+++ b/tools/testing/selftests/net/fib-onlink-tests.sh
@@ -56,7 +56,8 @@ TEST_NET6[2]=2001:db8:102
# connected gateway
CONGW[1]=169.254.1.254
-CONGW[2]=169.254.5.254
+CONGW[2]=169.254.3.254
+CONGW[3]=169.254.5.254
# recursive gateway
RECGW4[1]=169.254.11.254
@@ -232,6 +233,23 @@ run_ip()
log_test $? ${exp_rc} "${desc}"
}
+run_ip_mpath()
+{
+ local table="$1"
+ local prefix="$2"
+ local nh1="$3"
+ local nh2="$4"
+ local exp_rc="$5"
+ local desc="$6"
+
+ # dev arg may be empty
+ [ -n "${dev}" ] && dev="dev ${dev}"
+
+ run_cmd ip ro add table "${table}" "${prefix}"/32 \
+ nexthop via ${nh1} nexthop via ${nh2}
+ log_test $? ${exp_rc} "${desc}"
+}
+
valid_onlink_ipv4()
{
# - unicast connected, unicast recursive
@@ -243,13 +261,37 @@ valid_onlink_ipv4()
log_subsection "VRF ${VRF}"
- run_ip ${VRF_TABLE} ${TEST_NET4[2]}.1 ${CONGW[2]} ${NETIFS[p5]} 0 "unicast connected"
+ run_ip ${VRF_TABLE} ${TEST_NET4[2]}.1 ${CONGW[3]} ${NETIFS[p5]} 0 "unicast connected"
run_ip ${VRF_TABLE} ${TEST_NET4[2]}.2 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive"
log_subsection "VRF device, PBR table"
- run_ip ${PBR_TABLE} ${TEST_NET4[2]}.3 ${CONGW[2]} ${NETIFS[p5]} 0 "unicast connected"
+ run_ip ${PBR_TABLE} ${TEST_NET4[2]}.3 ${CONGW[3]} ${NETIFS[p5]} 0 "unicast connected"
run_ip ${PBR_TABLE} ${TEST_NET4[2]}.4 ${RECGW4[2]} ${NETIFS[p5]} 0 "unicast recursive"
+
+ # multipath version
+ #
+ log_subsection "default VRF - main table - multipath"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.5 \
+ "${CONGW[1]} dev ${NETIFS[p1]} onlink" \
+ "${CONGW[2]} dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.6 \
+ "${RECGW4[1]} dev ${NETIFS[p1]} onlink" \
+ "${RECGW4[2]} dev ${NETIFS[p3]} onlink" \
+ 0 "unicast recursive - multipath"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.7 \
+ "${CONGW[1]} dev ${NETIFS[p1]}" \
+ "${CONGW[2]} dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath onlink first only"
+
+ run_ip_mpath 254 ${TEST_NET4[1]}.8 \
+ "${CONGW[1]} dev ${NETIFS[p1]} onlink" \
+ "${CONGW[2]} dev ${NETIFS[p3]}" \
+ 0 "unicast connected - multipath onlink second only"
}
invalid_onlink_ipv4()
@@ -289,6 +331,21 @@ run_ip6()
log_test $? ${exp_rc} "${desc}"
}
+run_ip6_mpath()
+{
+ local table="$1"
+ local prefix="$2"
+ local opts="$3"
+ local nh1="$4"
+ local nh2="$5"
+ local exp_rc="$6"
+ local desc="$7"
+
+ run_cmd ip -6 ro add table "${table}" "${prefix}"/128 "${opts}" \
+ nexthop via ${nh1} nexthop via ${nh2}
+ log_test $? ${exp_rc} "${desc}"
+}
+
valid_onlink_ipv6()
{
# - unicast connected, unicast recursive, v4-mapped
@@ -310,6 +367,40 @@ valid_onlink_ipv6()
run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::4 ${V6ADDRS[p5]/::*}::64 ${NETIFS[p5]} 0 "unicast connected"
run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::5 ${RECGW6[2]} ${NETIFS[p5]} 0 "unicast recursive"
run_ip6 ${PBR_TABLE} ${TEST_NET6[2]}::6 ::ffff:${TEST_NET4IN6[2]} ${NETIFS[p5]} 0 "v4-mapped"
+
+ # multipath version
+ #
+ log_subsection "default VRF - main table - multipath"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::4 "onlink" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]}" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]}" \
+ 0 "unicast connected - multipath onlink"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::5 "onlink" \
+ "${RECGW6[1]} dev ${NETIFS[p1]}" \
+ "${RECGW6[2]} dev ${NETIFS[p3]}" \
+ 0 "unicast recursive - multipath onlink"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::6 "onlink" \
+ "::ffff:${TEST_NET4IN6[1]} dev ${NETIFS[p1]}" \
+ "::ffff:${TEST_NET4IN6[2]} dev ${NETIFS[p3]}" \
+ 0 "v4-mapped - multipath onlink"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::7 "" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]} onlink" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath onlink both nexthops"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::8 "" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]} onlink" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]}" \
+ 0 "unicast connected - multipath onlink first only"
+
+ run_ip6_mpath 254 ${TEST_NET6[1]}::9 "" \
+ "${V6ADDRS[p1]/::*}::64 dev ${NETIFS[p1]}" \
+ "${V6ADDRS[p3]/::*}::64 dev ${NETIFS[p3]} onlink" \
+ 0 "unicast connected - multipath onlink second only"
}
invalid_onlink_ipv6()
@@ -355,6 +446,7 @@ run_onlink_tests()
log_section "IPv6 onlink"
log_subsection "Valid onlink commands"
valid_onlink_ipv6
+ log_subsection "Invalid onlink commands"
invalid_onlink_ipv6
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] test_bpf: Fix testing with CONFIG_BPF_JIT_ALWAYS_ON=y on other arches
From: Thadeu Lima de Souza Cascardo @ 2018-03-20 17:00 UTC (permalink / raw)
To: Yonghong Song; +Cc: netdev, linux-kernel, Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <4a497245-1864-3036-074e-107134e4b9b5@fb.com>
On Tue, Mar 20, 2018 at 09:05:15AM -0700, Yonghong Song wrote:
>
>
> On 3/20/18 5:58 AM, Thadeu Lima de Souza Cascardo wrote:
> > Function bpf_fill_maxinsns11 is designed to not be able to be JITed on
> > x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and
> > commit 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when
> > CONFIG_BPF_JIT_ALWAYS_ON=y") makes sure that failure is detected on that
> > case.
> >
> > However, it does not fail on other architectures, which have a different
> > JIT compiler design. So, test_bpf has started to fail to load on those.
>
> Here, you mentioned that it did not fail on other architectures. Have you
> verified all of them or just looked through the algorithm.
>From our testing, I know at least I get an UNEXPECTED_PASS on arm64, arm, s390x
and ppc64le. i386 doesn't have JIT, so it doesn't have
CONFIG_BPF_JIT_ALWAYS_ON=y.
>
> Could you give a little bit details about other architectures are okay while
> x86 is not? Maybe, x86 JIT can be improved some how?
As the comment on that functions says:
/* Hits 70 passes on x86_64, so cannot get JITed there. */
And looking at x86_64 JIT compiler, you will notice it's looping trying to
minimize the size of the code, limited to 10 passes. If it does not converge,
it goes back to the non-JIT code.
That's not the case on powerpc or arm, that do not do multiple passes. sparc
seem to do 3 passes, but does not seem to go back to non-JIT code.
Cascardo.
>
> Thanks!
>
> >
> > After this fix, test_bpf loads fine on both x86_64 and ppc64el.
> >
> > Fixes: 09584b406742 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y")
> > Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
> > ---
> > lib/test_bpf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> > index 2efb213716faa..3e9335493fe49 100644
> > --- a/lib/test_bpf.c
> > +++ b/lib/test_bpf.c
> > @@ -5467,7 +5467,7 @@ static struct bpf_test tests[] = {
> > {
> > "BPF_MAXINSNS: Jump, gap, jump, ...",
> > { },
> > -#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> > +#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_X86)
> > CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
> > #else
> > CLASSIC | FLAG_NO_DATA,
> >
^ permalink raw reply
* Re: tg3 crashes under high load, when using 100Mbits
From: Kai-Heng Feng @ 2018-03-20 16:57 UTC (permalink / raw)
To: Satish Baddipadige
Cc: Siva Reddy Kallam, Prashant Sreedharan, Michael Chan,
Linux Netdev List, Linux Kernel Mailing List, Stanley Hsiao,
Tim Chen
In-Reply-To: <CA+oDAx908Dpn93-c4ogS5F1XZJri9GC_WaFR8wuDKO47kygB5w@mail.gmail.com>
Satish Baddipadige <satish.baddipadige@broadcom.com> wrote:
> On Thu, Feb 15, 2018 at 7:37 PM, Siva Reddy Kallam
> <siva.kallam@broadcom.com> wrote:
>> On Mon, Feb 12, 2018 at 10:59 AM, Siva Reddy Kallam
>> <siva.kallam@broadcom.com> wrote:
>>> On Fri, Feb 9, 2018 at 10:41 AM, Kai Heng Feng
>>> <kai.heng.feng@canonical.com> wrote:
>>>> Hi Broadcom folks,
>>>>
>>>> We are now enabling a new platform with tg3 nic, unfortunately we
>>>> observed
>>>> the bug [1] that dated back to 2015.
>>>> I tried commit 4419bb1cedcd ("tg3: Add workaround to restrict 5762
>>>> MRRS to
>>>> 2048”) but it does’t work.
>>>>
>>>> Do you have any idea how to solve the issue?
>>>>
>>>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447664
>>>>
>>>> Kai-Heng
>>> Thank you for reporting. We will check and update you.
>> With link aware mode, the clock speed could be slow and boot code does not
>> complete within the expected time with lower link speeds. Need to override
>> and the clock in driver. We are checking the feasibility of adding
>> this in driver or firmware.
>
> Hi Kai-Heng,
>
> Can you please test the attached patch?
I built a kernel and asked affected users to try.
Thanks for your work.
Kai-Heng
>
> Thanks,
> Satish
> <tg3_5762_clock_override.patch>
^ permalink raw reply
* Re: [PATCH net-next nfs 6/6] net: Convert rxrpc_net_ops
From: David Howells @ 2018-03-20 16:49 UTC (permalink / raw)
To: Kirill Tkhai
Cc: dhowells, davem, trond.myklebust, anna.schumaker, bfields,
jlayton, keescook, dwindsor, ishkamiel, elena.reshetova,
linux-nfs, linux-afs, netdev
In-Reply-To: <152093820653.8636.15794912193976988473.stgit@localhost.localdomain>
Kirill Tkhai <ktkhai@virtuozzo.com> wrote:
> These pernet_operations modifies rxrpc_net_id-pointed
> per-net entities. There is external link to AF_RXRPC
> in fs/afs/Kconfig, but it seems there is no other
> pernet_operations interested in that per-net entities.
The fs/afs/ namespacing stuff isn't active yet as I'm trying to decide on how
to deal with the DNS cache which also needs namespacing.
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
DaveM: Can you take this into net-next and add:
Acked-by: David Howells <dhowells@redhat.com>
^ permalink raw reply
* Re: [PATCH net] ipv6: old_dport should be a __be16 in __ip6_datagram_connect()
From: David Miller @ 2018-03-20 16:45 UTC (permalink / raw)
To: sbrivio; +Cc: pabeni, weiwan, g.nault, netdev
In-Reply-To: <f747595846809aa8626a2fc6b4bdcda5af75d42a.1521417707.git.sbrivio@redhat.com>
From: Stefano Brivio <sbrivio@redhat.com>
Date: Mon, 19 Mar 2018 11:24:58 +0100
> Fixes: 2f987a76a977 ("net: ipv6: keep sk status consistent after datagram connect failure")
> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
> Acked-by: Paolo Abeni <pabeni@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: pull-request: can 2018-03-19
From: David Miller @ 2018-03-20 16:45 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180319101431.11032-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 19 Mar 2018 11:14:30 +0100
> this is a pull reqeust of one patch for net/master.
>
> The patch is by Andri Yngvason and fixes a potential use-after-free bug
> in the cc770 driver introduced in the previous pull-request.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-20 16:44 UTC (permalink / raw)
To: Eric W. Biederman
Cc: shmulik.ladkani, netdev, mrv, daniel, davem, linux-kernel,
yuval.shaia, idan.brown
In-Reply-To: <87tvta67gl.fsf@xmission.com>
On 20/03/18 18:24, ebiederm@xmission.com wrote:
>
> I don't believe the current behavior is a bug.
>
> I looked through the history. Basically skb_scrub_packet
> started out as the scrubbing needed for crossing network
> namespaces.
>
> Then tunnels which needed 90% of the functionality started
> calling it, with the xnet flag added. Because the tunnels
> needed to preserve their historic behavior.
>
> Then dev_forward_skb started calling skb_scrub_packet.
>
> A veth pair is supposed to give the same behavior as a cross-over
> cable plugged into two local nics. A cross over cable won't
> preserve things like the skb mark. So I don't see why anyone would
> expect a veth pair to preserve the mark.
I disagree with this argument.
I think that a skb crossing netns is what simulates a real packet
crossing physical computers. Following your argument, why would
skb->mark should be preserved when crossing netdevs on same netns via
routing? But this does today preserve skb->mark.
Therefore, I do think that skb->mark should conceptually only be
scrubbed when crossing netns. Regardless of the netdev used to cross it.
>
> Right now I don't see the point of handling packets that don't cross
> network namespace boundaries specially, other than to preserve backwards
> compatibility.
>
> Eric
>
^ permalink raw reply
* Re: [PATCH net-next 1/1] net/ipv4: disable SMC TCP option with SYN Cookies
From: Eric Dumazet @ 2018-03-20 16:43 UTC (permalink / raw)
To: Eric Dumazet, Ursula Braun, davem
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <435f82d0-407e-6675-194a-102d83f418f8@gmail.com>
On 03/20/2018 09:21 AM, Eric Dumazet wrote:
>
>
> On 03/20/2018 08:53 AM, Ursula Braun wrote:
>> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
>>
>> Currently, the SMC experimental TCP option in a SYN packet is lost on
>> the server side when SYN Cookies are active. However, the corresponding
>> SYNACK sent back to the client contains the SMC option. This causes an
>> inconsistent view of the SMC capabilities on the client and server.
>>
>> This patch disables the SMC option in the SYNACK when SYN Cookies are
>> active to avoid this issue.
>>
>> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
>> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
>> ---
>> net/ipv4/tcp_output.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> index 383cac0ff0ec..22894514feae 100644
>> --- a/net/ipv4/tcp_output.c
>> +++ b/net/ipv4/tcp_output.c
>> @@ -3199,6 +3199,8 @@ struct sk_buff *tcp_make_synack(const struct sock *sk, struct dst_entry *dst,
>> /* Under synflood, we do not attach skb to a socket,
>> * to avoid false sharing.
>> */
>> + if (IS_ENABLED(CONFIG_SMC))
>> + ireq->smc_ok = 0;
>> break;
>> case TCP_SYNACK_FASTOPEN:
>> /* sk is a const pointer, because we want to express multiple
>>
>
> I disagree with net-next qualification.
>
> This fixes a bug, so please send it for net tree, and including an appropriate Fixes: tag.
>
Also, please do not add the fix in tcp_make_synack()
tcp_make_synack() builds an skb, and really should not modify ireq, ideally.
The only reason ireq is not const is because of the skb_set_owner_w().
I would clear it in cookie_v4_check()/cookie_v6_check()
(We could have a common helper to allocate a TCP ireq btw, but this will wait a future patch for net-next)
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-20 16:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <20180320.123401.2138083793709750726.davem@davemloft.net>
On 20/03/18 18:34, David Miller wrote:
> From: Liran Alon <LIRAN.ALON@ORACLE.COM>
> Date: Tue, 20 Mar 2018 18:11:49 +0200
>
>> 1. Do we want to make a flag for every bug that is user-space visible?
>> I think there is place for consideration on a per-case basis. I still
>> don't see how a user can utilize this behaviour. He is basically
>> loosing information (skb->mark) without this patch.
>
> And maybe people trying to work in this situation have added code to
> get the mark set some other way, or to validate that it is in fact
> zero after passing through, which we would break with this change.
>
> If it's set to zero now, it's reasonable to expect it to be zero.
>
> By changing it to non-zero, different rules and routes will match
> and this for sure has potential to break things.
>
OK.
What is your opinion in regards if it's OK to put the flag enabling this
"fix" in /proc/sys/net/core? Do you think it's sufficient?
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: David Miller @ 2018-03-20 16:34 UTC (permalink / raw)
To: LIRAN.ALON; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <5AB132C5.5010806@ORACLE.COM>
From: Liran Alon <LIRAN.ALON@ORACLE.COM>
Date: Tue, 20 Mar 2018 18:11:49 +0200
> 1. Do we want to make a flag for every bug that is user-space visible?
> I think there is place for consideration on a per-case basis. I still
> don't see how a user can utilize this behaviour. He is basically
> loosing information (skb->mark) without this patch.
And maybe people trying to work in this situation have added code to
get the mark set some other way, or to validate that it is in fact
zero after passing through, which we would break with this change.
If it's set to zero now, it's reasonable to expect it to be zero.
By changing it to non-zero, different rules and routes will match
and this for sure has potential to break things.
^ permalink raw reply
* Re: [PATCH v2 0/3] net: dsa: mv88e6xxx: some fixes
From: David Miller @ 2018-03-20 16:30 UTC (permalink / raw)
To: u.kleine-koenig
Cc: andrew, vivien.didelot, kernel, gregory.clement, netdev,
f.fainelli
In-Reply-To: <20180320094442.18368-1-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-K�nig <u.kleine-koenig@pengutronix.de>
Date: Tue, 20 Mar 2018 10:44:39 +0100
> these patches target net-next and got approved by Andrew Lunn.
>
> Compared to (implicit) v1, I dropped the patch that I didn't know if it
> was right because of missing documentation on my side. But Andrew
> already cared for that in a patch that is now adfccf118211 in net-next.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH v12 net-next 12/12] crypto: chtls - Makefile Kconfig
From: kbuild test robot @ 2018-03-20 16:28 UTC (permalink / raw)
To: Atul Gupta
Cc: kbuild-all, davem, herbert, davejwatson, sd, sbrivio,
linux-crypto, netdev, ganeshgr
In-Reply-To: <1521467745-23201-13-git-send-email-atul.gupta@chelsio.com>
[-- Attachment #1: Type: text/plain, Size: 3051 bytes --]
Hi Atul,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20180309]
[also build test ERROR on v4.16-rc6]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Atul-Gupta/Chelsio-Inline-TLS/20180320-101600
config: mips-allmodconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips
All errors (new ones prefixed by >>):
drivers/crypto/chelsio/chtls/chtls_main.c: In function 'chtls_uld_state_change':
>> drivers/crypto/chelsio/chtls/chtls_main.c:319:7: error: 'CXGB4_STATE_FATAL_ERROR' undeclared (first use in this function); did you mean 'CXGB4_STATE_DETACH'?
case CXGB4_STATE_FATAL_ERROR:
^~~~~~~~~~~~~~~~~~~~~~~
CXGB4_STATE_DETACH
drivers/crypto/chelsio/chtls/chtls_main.c:319:7: note: each undeclared identifier is reported only once for each function it appears in
vim +319 drivers/crypto/chelsio/chtls/chtls_main.c
29f9f684 Atul Gupta 2018-03-19 307
29f9f684 Atul Gupta 2018-03-19 308 static int chtls_uld_state_change(void *handle, enum cxgb4_state new_state)
29f9f684 Atul Gupta 2018-03-19 309 {
29f9f684 Atul Gupta 2018-03-19 310 struct chtls_dev *cdev = handle;
29f9f684 Atul Gupta 2018-03-19 311
29f9f684 Atul Gupta 2018-03-19 312 switch (new_state) {
29f9f684 Atul Gupta 2018-03-19 313 case CXGB4_STATE_UP:
29f9f684 Atul Gupta 2018-03-19 314 chtls_register_dev(cdev);
29f9f684 Atul Gupta 2018-03-19 315 break;
29f9f684 Atul Gupta 2018-03-19 316 case CXGB4_STATE_DOWN:
29f9f684 Atul Gupta 2018-03-19 317 break;
29f9f684 Atul Gupta 2018-03-19 318 case CXGB4_STATE_START_RECOVERY:
29f9f684 Atul Gupta 2018-03-19 @319 case CXGB4_STATE_FATAL_ERROR:
29f9f684 Atul Gupta 2018-03-19 320 break;
29f9f684 Atul Gupta 2018-03-19 321 case CXGB4_STATE_DETACH:
29f9f684 Atul Gupta 2018-03-19 322 mutex_lock(&cdev_mutex);
29f9f684 Atul Gupta 2018-03-19 323 list_del(&cdev->list);
29f9f684 Atul Gupta 2018-03-19 324 mutex_unlock(&cdev_mutex);
29f9f684 Atul Gupta 2018-03-19 325 chtls_free_uld(cdev);
29f9f684 Atul Gupta 2018-03-19 326 break;
29f9f684 Atul Gupta 2018-03-19 327 }
29f9f684 Atul Gupta 2018-03-19 328 return 0;
29f9f684 Atul Gupta 2018-03-19 329 }
29f9f684 Atul Gupta 2018-03-19 330
:::::: The code at line 319 was first introduced by commit
:::::: 29f9f68416a9775029d6cc8135cf3f01995dd9f4 crypto: chtls - Register chtls with net tls
:::::: TO: Atul Gupta <atul.gupta@chelsio.com>
:::::: CC: 0day robot <fengguang.wu@intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55197 bytes --]
^ permalink raw reply
* Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
From: Ben Greear @ 2018-03-20 16:24 UTC (permalink / raw)
To: Steve deRosier
Cc: Michal Kubecek, linux-wireless,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CALLGbRKU_PCk-3ZMBRu6CC-QyaEEPTAOavGVzPpQUdEMQ+s9BQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/20/2018 09:11 AM, Steve deRosier wrote:
> On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
>> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>>
>>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
>>>>
>>>> From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>>
>>>> This is similar to ETHTOOL_GSTATS, but it allows you to specify
>>>> a 'level'. This level can be used by the driver to decrease the
>>>> amount of stats refreshed. In particular, this helps with ath10k
>>>> since getting the firmware stats can be slow.
>>>>
>>>> Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>> ---
>>>>
>>>> NOTE: I know to make it upstream I would need to split the patch and
>>>> remove the #define for 'backporting' that I added. But, is the
>>>> feature in general wanted? If so, I'll do the patch split and
>>>> other tweaks that might be suggested.
>>>
>>>
>>
>> Yes, but that would require changing all drivers at once, and would make
>> backporting
>> and out-of-tree drivers harder to manage. I had low hopes that this feature
>> would
>> make it upstream, so I didn't want to propose any large changes up front.
>>
>
> Hi Ben,
>
> I find the feature OK, but I'm not thrilled with the arbitrary scale
> of "level". Maybe there could be some named values, either on a
> spectrum as level already is, similar to the kernel log DEBUG, WARN,
> INFO.... type levels. Or named bit flags like the way the ath drivers
> do their debug flags for granular results. Thoughts?
Yes, that would be easier to code too. If there are any other drivers
out there that might take advantage of this, maybe they could chime in with
what levels and/or bit-fields they would like to see.
For instance a bit that says 'refresh-stats-from-firmware' would be great for ath10k,
but maybe useless for everyone else....
Thanks,
Ben
>
> - Steve
>
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Eric W. Biederman @ 2018-03-20 16:24 UTC (permalink / raw)
To: Liran Alon
Cc: shmulik.ladkani, netdev, mrv, daniel, davem, linux-kernel,
yuval.shaia, idan.brown
In-Reply-To: <0d84d286-9965-45cb-93c8-379ca1b2441e@default>
Liran Alon <liran.alon@oracle.com> writes:
> ----- shmulik.ladkani@gmail.com wrote:
>
>> On Thu, 15 Mar 2018 09:35:51 -0700 (PDT) Liran Alon
>> <liran.alon@oracle.com> wrote:
>> > ----- shmulik.ladkani@gmail.com wrote:
>> >
>> > > On Thu, 15 Mar 2018 08:01:03 -0700 (PDT) Liran Alon
>> > > <liran.alon@oracle.com> wrote:
>> > > >
>> > > > I still think that default behavior should be to zero skb->mark
>> only
>> > > when skb
>> > > > cross netdevs in different netns.
>> > >
>> > > But the previous default was scrub the mark in *both* xnet and
>> > > non-xnet
>> > > situations.
>> > >
>> > > Therefore, there might be users which RELY on this (strange)
>> default
>> > > behavior in their same-netns-veth-pair setups.
>> > > Meaning, changing the default behavior might break their apps
>> relying
>> > > on
>> > > the former default behavior.
>> > >
>> > > This is why the "disable mark scrubbing in non-xnet case" should
>> be
>> > > opt-in.
>> >
>> > We think the same.
>> > The only difference is that I think this for now should be
>> controllable
>> > by a global /proc/sys/net/core file instead of giving a flexible
>> per-netdev
>> > control.
>> > Because that is a larger change that could be done later.
>>
>> A flags attribute to veth newlink is a very scoped change.
>> User controls this per veth creation.
>> This is way more neat than /proc/sys/net and provides the desired
>> granular
>> control.
>>
>> Also, scoping this to veth has the advantage of not affecting the many
>> other
>> dev_forward_skb callers.
>
> Agreed. But isn't this an issue also for the
> many others (& future) callers of dev_forward_skb()?
> This seems problematic to me.
>
> This will kinda leave a kernel interface with broken default behavior
> for backwards comparability.
>
> A flag to netdev or /proc/sys/net/core to "fix" default behavior
> will avoid this.
I don't believe the current behavior is a bug.
I looked through the history. Basically skb_scrub_packet
started out as the scrubbing needed for crossing network
namespaces.
Then tunnels which needed 90% of the functionality started
calling it, with the xnet flag added. Because the tunnels
needed to preserve their historic behavior.
Then dev_forward_skb started calling skb_scrub_packet.
A veth pair is supposed to give the same behavior as a cross-over
cable plugged into two local nics. A cross over cable won't
preserve things like the skb mark. So I don't see why anyone would
expect a veth pair to preserve the mark.
Right now I don't see the point of handling packets that don't cross
network namespace boundaries specially, other than to preserve backwards
compatibility.
Eric
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: Revert "ipv4: fix a deadlock in ip_ra_control"
From: David Miller @ 2018-03-20 16:23 UTC (permalink / raw)
To: ktkhai
Cc: yoshfuji, edumazet, yanhaishuang, nikolay, yotamg, soheil, avagin,
nicolas.dichtel, ebiederm, fw, roman.kapl, netdev, xiyou.wangcong,
dvyukov, andreyknvl, lkp
In-Reply-To: <152145089432.7718.3981942805167545803.stgit@localhost.localdomain>
From: Kirill Tkhai <ktkhai@virtuozzo.com>
Date: Mon, 19 Mar 2018 12:14:54 +0300
> This reverts commit 1215e51edad1.
> Since raw_close() is used on every RAW socket destruction,
> the changes made by 1215e51edad1 scale sadly. This clearly
> seen on endless unshare(CLONE_NEWNET) test, and cleanup_net()
> kwork spends a lot of time waiting for rtnl_lock() introduced
> by this commit.
>
> Next patches in series will rework this in another way,
> so now we revert 1215e51edad1. Also, it doesn't seen
> mrtsock_destruct() takes sk_lock, and the comment to the commit
> does not show the actual stack dump. So, there is a question
> did we really need in it.
>
> Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Kirill, I think the commit you are reverting is legitimate.
The IP_RAW_CONTROL path has an ABBA deadlock with other paths once
you revert this, so you are reintroducing a bug.
All code paths that must take both RTNL and the socket lock must
do them in the same order. And that order is RTNL then socket
lock.
But you are breaking that here by getting us back into a state
where IP_RAW_CONTROL setsockopt will take the socket lock and
then RTNL.
Again, we can't take, or retake, RTNL if we have the socket lock
currently.
The only valid locking order is socket lock then RTNL.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net/ipv4: disable SMC TCP option with SYN Cookies
From: Eric Dumazet @ 2018-03-20 16:21 UTC (permalink / raw)
To: Ursula Braun, davem
Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180320155340.18017-2-ubraun@linux.vnet.ibm.com>
On 03/20/2018 08:53 AM, Ursula Braun wrote:
> From: Hans Wippel <hwippel@linux.vnet.ibm.com>
>
> Currently, the SMC experimental TCP option in a SYN packet is lost on
> the server side when SYN Cookies are active. However, the corresponding
> SYNACK sent back to the client contains the SMC option. This causes an
> inconsistent view of the SMC capabilities on the client and server.
>
> This patch disables the SMC option in the SYNACK when SYN Cookies are
> active to avoid this issue.
>
> Signed-off-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
> ---
> net/ipv4/tcp_output.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 383cac0ff0ec..22894514feae 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -3199,6 +3199,8 @@ struct sk_buff *tcp_make_synack(const struct sock *sk, struct dst_entry *dst,
> /* Under synflood, we do not attach skb to a socket,
> * to avoid false sharing.
> */
> + if (IS_ENABLED(CONFIG_SMC))
> + ireq->smc_ok = 0;
> break;
> case TCP_SYNACK_FASTOPEN:
> /* sk is a const pointer, because we want to express multiple
>
I disagree with net-next qualification.
This fixes a bug, so please send it for net tree, and including an appropriate Fixes: tag.
Thanks !
^ permalink raw reply
* Re: NETDEV WATCHDOG: eth0 (tg3): transmit queue 0 timed out
From: Borislav Petkov @ 2018-03-20 16:18 UTC (permalink / raw)
To: Satish Baddipadige
Cc: Siva Reddy Kallam, Linux Netdev List, Prashant Sreedharan,
Michael Chan, Linux Kernel list
In-Reply-To: <CA+oDAx8CCW8rUfdqSZJpKFzHUBocY_Q1xbJXB0y8qa6qP0iUAg@mail.gmail.com>
On Tue, Mar 20, 2018 at 11:41:06AM +0530, Satish Baddipadige wrote:
> Can you please test the attached patch?
Sure, will do when I get back next week.
Thx.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply. Srsly.
^ permalink raw reply
* Re: [PATCH linux-stable-4.14] tcp: reset sk_send_head in tcp_write_queue_purge
From: Willy Tarreau @ 2018-03-20 16:13 UTC (permalink / raw)
To: davem
Cc: yongjian xu, Soheil Hassas Yeganeh, netdev, ycheng, ncardwell,
nefelim4ag, Soheil Hassas Yeganeh, Eric Dumazet
In-Reply-To: <CACrmbvZzCvO6pTpvq=mE54s3CwAaBB4npc+E7Fa8zvMArL3t7A@mail.gmail.com>
Hi David,
regarding the patch below, I'm not certain whether you planned to take
it since it's marked "not applicable" on patchwork, but I suspect it's
only because it doesn't apply to mainline.
However, please note that there are two typos in commit IDs referenced in
the commit message that might be nice to fix before merging :
> > For example, after 27fid7a8ed38 (tcp: purge write queue upon RST),
- here it's "a27fd7a8ed38" (missing 'a' and extra 'i' in the middle)
- and lower in the fixes tag there's the extra 'i' as well :
> > Fixes: a27fid7a8ed38 (tcp: purge write queue upon RST)
There was another report today on the stable list for a similar crash
on 4.14.28 and I suspect it's the one I saw this week-end on my firewall
after upgrading from 4.14.10 to 4.14.27 though I didn't have the symbols
to confirm.
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH] net: dev_forward_skb(): Scrub packet's per-netns info only when crossing netns
From: Liran Alon @ 2018-03-20 16:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, idan.brown, yuval.shaia
In-Reply-To: <20180320.120036.1999626754164343704.davem@davemloft.net>
On 20/03/18 18:00, David Miller wrote:
> From: Liran Alon <LIRAN.ALON@ORACLE.COM>
> Date: Tue, 20 Mar 2018 17:34:38 +0200
>
>> I personally don't understand why we should maintain
>> backwards-comparability to this behaviour.
>
> The reason is because not breaking things is a cornerstone of Linux
> kernel development.
>
>> This feature is not documented to user-mode and I don't see why it
>> is legit for the user to rely on it.
>
> Whether it is documented or not is irrelevant. A lot of our
> interfaces and behaviors are not documented or poorly documented
> at best.
>
>> In addition, even if we do want to maintain backwards-comparability to
>> this behaviour, I think it is enough to have an opt-in flag in
>> /proc/sys/net/core/ that when set to 1 will activate the fix in
>> dev_forward_skb() provided by this patch. That would also be a very
>> simple change to the patch provided here.
>
> Making it opt-in makes it more palatable, that's for sure.
>
1. Do we want to make a flag for every bug that is user-space visible? I
think there is place for consideration on a per-case basis. I still
don't see how a user can utilize this behaviour. He is basically loosing
information (skb->mark) without this patch.
2. Having said that, I don't mind changing patch to maintain backwards
compatibility here. However, there was also a discussion here on where
the flag should sit. I think that a global /proc/sys/net/core/ flag
should be enough. Do you agree it's sufficient for now?
Thanks,
-Liran
^ permalink raw reply
* Re: [PATCH net-next 0/4] mlxsw: Adapt driver to upcoming firmware versions
From: David Miller @ 2018-03-20 16:11 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw
In-Reply-To: <20180319075103.17671-1-idosch@mellanox.com>
From: Ido Schimmel <idosch@mellanox.com>
Date: Mon, 19 Mar 2018 09:50:59 +0200
> The first two patches make sure that reserved fields are set to zero, as
> required by the device's programmer's reference manual (PRM).
>
> Last two patches prevent the driver from performing an invalid operation
> that is going to be denied by upcoming firmware versions.
Series applied, thank you.
^ permalink raw reply
* Re: [RFC] ethtool: Support ETHTOOL_GSTATS2 command.
From: Steve deRosier @ 2018-03-20 16:11 UTC (permalink / raw)
To: Ben Greear
Cc: Michal Kubecek, linux-wireless,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <37830d46-762b-2a92-4506-5792a65d2ebd-my8/4N5VtI7c+919tysfdA@public.gmane.org>
On Tue, Mar 20, 2018 at 8:39 AM, Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org> wrote:
> On 03/20/2018 03:37 AM, Michal Kubecek wrote:
>>
>> On Wed, Mar 07, 2018 at 11:51:29AM -0800, greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org wrote:
>>>
>>> From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>>
>>> This is similar to ETHTOOL_GSTATS, but it allows you to specify
>>> a 'level'. This level can be used by the driver to decrease the
>>> amount of stats refreshed. In particular, this helps with ath10k
>>> since getting the firmware stats can be slow.
>>>
>>> Signed-off-by: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
>>> ---
>>>
>>> NOTE: I know to make it upstream I would need to split the patch and
>>> remove the #define for 'backporting' that I added. But, is the
>>> feature in general wanted? If so, I'll do the patch split and
>>> other tweaks that might be suggested.
>>
>>
>
> Yes, but that would require changing all drivers at once, and would make
> backporting
> and out-of-tree drivers harder to manage. I had low hopes that this feature
> would
> make it upstream, so I didn't want to propose any large changes up front.
>
Hi Ben,
I find the feature OK, but I'm not thrilled with the arbitrary scale
of "level". Maybe there could be some named values, either on a
spectrum as level already is, similar to the kernel log DEBUG, WARN,
INFO.... type levels. Or named bit flags like the way the ath drivers
do their debug flags for granular results. Thoughts?
- Steve
^ 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