* Re: [PATCH net-next v5 5/6] flow_offload: support get flow_block immediately
From: wenxu @ 2019-08-02 23:19 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: jiri, pablo, fw, netfilter-devel, netdev, John Hurley
In-Reply-To: <20190802110216.5e1fd938@cakuba.netronome.com>
在 2019/8/3 2:02, Jakub Kicinski 写道:
> On Fri, 2 Aug 2019 21:09:03 +0800, wenxu wrote:
>>>> We'd have something like the loop in flow_get_default_block():
>>>>
>>>> for each (subsystem)
>>>> subsystem->handle_new_indir_cb(indr_dev, cb);
>>>>
>>>> And then per-subsystem logic would actually call the cb. Or:
>>>>
>>>> for each (subsystem)
>>>> block = get_default_block(indir_dev)
>>>> indr_dev->ing_cmd_cb(...)
>>> nft dev chian is also based on register_netdevice_notifier, So for unregister case,
>>>
>>> the basechian(block) of nft maybe delete before the __tc_indr_block_cb_unregister. is right?
>>>
>>> So maybe we can cache the block as a list of all the subsystem in indr_dev ?
>>
>> when the device is unregister the nft netdev chain related to this device will also be delete through netdevice_notifier
>>
>> . So for unregister case,the basechian(block) of nft maybe delete before the __tc_indr_block_cb_unregister.
> Hm, but I don't think that should be an issue. The ordering should be
> like one of the following two:
>
> device unregister:
> - driver notifier callback
> - unregister flow cb
> - UNBIND cb
> - free driver's block state
> - free driver's device state
> - nft block destroy
> # doesn't see driver's CB any more
>
> Or:
>
> device unregister:
> - nft block destroy
> - UNBIND cb
> - free driver's block state
> - driver notifier callback
> - free driver's state
>
> No?
For the second case maybe can't unbind cb? because the nft block is destroied. There is no way
to find the block(chain) in nft.
>
>> cache for the block is not work because the chain already be delete and free. Maybe it improve the prio of
>>
>> rep_netdev_event can help this?
> In theory the cache should work in a similar way as drivers, because
> once the indr_dev is created and the initial block is found, the cached
> value is just recorded in BIND/UNBIND calls. So if BIND/UNBIND works for
> drivers it will also put the right info in the cache.
>
^ permalink raw reply
* Re: [PATCH] net: sctp: Rename fallthrough label to unhandled
From: Joe Perches @ 2019-08-02 23:26 UTC (permalink / raw)
To: David Miller
Cc: nhorman, vyasevich, marcelo.leitner, linux-sctp, netdev,
linux-kernel
In-Reply-To: <20190802.161932.1776993765494484851.davem@davemloft.net>
On Fri, 2019-08-02 at 16:19 -0700, David Miller wrote:
> From: Joe Perches <joe@perches.com>
> Date: Fri, 02 Aug 2019 10:47:34 -0700
>
> > On Wed, 2019-07-31 at 08:16 -0400, Neil Horman wrote:
> >> On Wed, Jul 31, 2019 at 04:32:43AM -0700, Joe Perches wrote:
> >> > On Wed, 2019-07-31 at 07:19 -0400, Neil Horman wrote:
> >> > > On Tue, Jul 30, 2019 at 10:04:37PM -0700, Joe Perches wrote:
> >> > > > fallthrough may become a pseudo reserved keyword so this only use of
> >> > > > fallthrough is better renamed to allow it.
> >
> > Can you or any other maintainer apply this patch
> > or ack it so David Miller can apply it?
>
> I, like others, don't like the lack of __ in the keyword. It's kind of
> rediculous the problems it creates to pollute the global namespace like
> that and yes also inconsistent with other shorthands for builtins.
Please add that to the conversation on the RFC thread.
https://lore.kernel.org/patchwork/patch/1108577/
In any case, fallthrough is not really a good label
name for this use.
^ permalink raw reply
* [PATCH bpf-next 1/2] selftests/bpf: add loop test 4
From: Alexei Starovoitov @ 2019-08-02 23:33 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, bpf, kernel-team
In-Reply-To: <20190802233344.863418-1-ast@kernel.org>
Add a test that returns a 'random' number between [0, 2^20)
If state pruning is not working correctly for loop body the number of
processed insns will be 2^20 * num_of_insns_in_loop_body and the program
will be rejected.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
.../bpf/prog_tests/bpf_verif_scale.c | 1 +
tools/testing/selftests/bpf/progs/loop4.c | 23 +++++++++++++++++++
2 files changed, 24 insertions(+)
create mode 100644 tools/testing/selftests/bpf/progs/loop4.c
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
index b4be96162ff4..757e39540eda 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
@@ -71,6 +71,7 @@ void test_bpf_verif_scale(void)
{ "loop1.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
{ "loop2.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
+ { "loop4.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
/* partial unroll. 19k insn in a loop.
* Total program size 20.8k insn.
diff --git a/tools/testing/selftests/bpf/progs/loop4.c b/tools/testing/selftests/bpf/progs/loop4.c
new file mode 100644
index 000000000000..3e7ee14fddbd
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/loop4.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019 Facebook
+#include <linux/sched.h>
+#include <linux/ptrace.h>
+#include <stdint.h>
+#include <stddef.h>
+#include <stdbool.h>
+#include <linux/bpf.h>
+#include "bpf_helpers.h"
+
+char _license[] SEC("license") = "GPL";
+
+SEC("socket")
+int combinations(volatile struct __sk_buff* skb)
+{
+ int ret = 0, i;
+
+#pragma nounroll
+ for (i = 0; i < 20; i++)
+ if (skb->len)
+ ret |= 1 << i;
+ return ret;
+}
--
2.20.0
^ permalink raw reply related
* [PATCH bpf-next 0/2] selftests/bpf: more loop tests
From: Alexei Starovoitov @ 2019-08-02 23:33 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, bpf, kernel-team
Add two bounded loop tests.
Alexei Starovoitov (2):
selftests/bpf: add loop test 4
selftests/bpf: add loop test 5
.../bpf/prog_tests/bpf_verif_scale.c | 2 +
tools/testing/selftests/bpf/progs/loop4.c | 23 ++++++++++++
tools/testing/selftests/bpf/progs/loop5.c | 37 +++++++++++++++++++
3 files changed, 62 insertions(+)
create mode 100644 tools/testing/selftests/bpf/progs/loop4.c
create mode 100644 tools/testing/selftests/bpf/progs/loop5.c
--
2.20.0
^ permalink raw reply
* [PATCH bpf-next 2/2] selftests/bpf: add loop test 5
From: Alexei Starovoitov @ 2019-08-02 23:33 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, bpf, kernel-team
In-Reply-To: <20190802233344.863418-1-ast@kernel.org>
Add a test with multiple exit conditions.
It's not an infinite loop only when the verifier can properly track
all math on variable 'i' through all possible ways of executing this loop.
barrier()s are needed to disable llvm optimization that combines multiple
branches into fewer branches.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
---
.../bpf/prog_tests/bpf_verif_scale.c | 1 +
tools/testing/selftests/bpf/progs/loop5.c | 37 +++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 tools/testing/selftests/bpf/progs/loop5.c
diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
index 757e39540eda..29615a4a9362 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_verif_scale.c
@@ -72,6 +72,7 @@ void test_bpf_verif_scale(void)
{ "loop1.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
{ "loop2.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
{ "loop4.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
+ { "loop5.o", BPF_PROG_TYPE_RAW_TRACEPOINT },
/* partial unroll. 19k insn in a loop.
* Total program size 20.8k insn.
diff --git a/tools/testing/selftests/bpf/progs/loop5.c b/tools/testing/selftests/bpf/progs/loop5.c
new file mode 100644
index 000000000000..9d9817efe208
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/loop5.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019 Facebook
+#include <linux/sched.h>
+#include <linux/ptrace.h>
+#include <stdint.h>
+#include <stddef.h>
+#include <stdbool.h>
+#include <linux/bpf.h>
+#include "bpf_helpers.h"
+#define barrier() __asm__ __volatile__("": : :"memory")
+
+char _license[] SEC("license") = "GPL";
+
+SEC("socket")
+int while_true(volatile struct __sk_buff* skb)
+{
+ int i = 0;
+
+ while (true) {
+ if (skb->len)
+ i += 3;
+ else
+ i += 7;
+ if (i == 9)
+ break;
+ barrier();
+ if (i == 10)
+ break;
+ barrier();
+ if (i == 13)
+ break;
+ barrier();
+ if (i == 14)
+ break;
+ }
+ return i;
+}
--
2.20.0
^ permalink raw reply related
* RE: [PATCH net 1/2] net/tls: partially revert fix transition through disconnect with close
From: John Fastabend @ 2019-08-02 23:57 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, oss-drivers, edumazet, davejwatson, borisp, aviadye,
john.fastabend, daniel, Jakub Kicinski
In-Reply-To: <20190801213602.19634-1-jakub.kicinski@netronome.com>
Jakub Kicinski wrote:
> Looks like we were slightly overzealous with the shutdown()
> cleanup. Even though the sock->sk_state can reach CLOSED again,
> socket->state will not got back to SS_UNCONNECTED once
> connections is ESTABLISHED. Meaning we will see EISCONN if
> we try to reconnect, and EINVAL if we try to listen.
>
> Only listen sockets can be shutdown() and reused, but since
> ESTABLISHED sockets can never be re-connected() or used for
> listen() we don't need to try to clean up the ULP state early.
>
> Fixes: 32857cf57f92 ("net/tls: fix transition through disconnect with close")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
Thanks Jakub this looks reasonable to me I'm going to run some tests
with sockmap + ktls on it this weekend to be sure the two work
together with some of our applications. I believe the original
series should be enough so that BPF can be safely unloaded out
from underneath ktls now.
I guess we could do something similar on the sockmap side but I
do want to loosen the restrictions there at some point so might
be best just to keep it as is.
Thanks,
John
^ permalink raw reply
* Re: [PATCH net-next v5 5/6] flow_offload: support get flow_block immediately
From: Jakub Kicinski @ 2019-08-03 0:21 UTC (permalink / raw)
To: wenxu; +Cc: jiri, pablo, fw, netfilter-devel, netdev, John Hurley
In-Reply-To: <45660f1e-b6a8-1bcb-0d57-7c1790d3fbaf@ucloud.cn>
On Sat, 3 Aug 2019 07:19:31 +0800, wenxu wrote:
> > Or:
> >
> > device unregister:
> > - nft block destroy
> > - UNBIND cb
> > - free driver's block state
> > - driver notifier callback
> > - free driver's state
> >
> > No?
>
> For the second case maybe can't unbind cb? because the nft block is
> destroied. There is no way to find the block(chain) in nft.
But before the block is destroyed doesn't nft send an UNBIND event to
the drivers, always?
^ permalink raw reply
* Re: [PATCH net-next] net/tls: prevent skb_orphan() from leaking TLS plain text with offload
From: David Miller @ 2019-08-03 0:24 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, edumazet, borisp, aviadye, davejwatson,
john.fastabend, daniel, willemb, xiyou.wangcong, fw,
alexei.starovoitov
In-Reply-To: <20190730211258.13748-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 30 Jul 2019 14:12:58 -0700
> I'm sending this for net-next because of lack of confidence
> in my own abilities. It should apply cleanly to net... :)
It looks like there will be changes to this.
^ permalink raw reply
* Re: [PATCH v2 net] hv_sock: Fix hang when a connection is closed
From: David Miller @ 2019-08-03 0:27 UTC (permalink / raw)
To: decui
Cc: sunilmut, netdev, kys, haiyangz, sthemmin, sashal, mikelley,
linux-hyperv, linux-kernel, olaf, apw, jasowang, vkuznets,
marcelo.cerri
In-Reply-To: <PU1P153MB01696DDD3A3F601370701DD2BFDF0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
From: Dexuan Cui <decui@microsoft.com>
Date: Wed, 31 Jul 2019 01:25:45 +0000
>
> There is a race condition for an established connection that is being closed
> by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the
> 'remove_sock' is false):
>
> 1 for the initial value;
> 1 for the sk being in the bound list;
> 1 for the sk being in the connected list;
> 1 for the delayed close_work.
>
> After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may*
> decrease the refcnt to 3.
>
> Concurrently, hvs_close_connection() runs in another thread:
> calls vsock_remove_sock() to decrease the refcnt by 2;
> call sock_put() to decrease the refcnt to 0, and free the sk;
> next, the "release_sock(sk)" may hang due to use-after-free.
>
> In the above, after hvs_release() finishes, if hvs_close_connection() runs
> faster than "__vsock_release() -> sock_put(sk)", then there is not any issue,
> because at the beginning of hvs_close_connection(), the refcnt is still 4.
>
> The issue can be resolved if an extra reference is taken when the
> connection is established.
>
> Fixes: a9eeb998c28d ("hv_sock: Add support for delayed close")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
Applied and queued up for -stable.
Do not ever CC: stable for networking patches, we submit to -stable manually.
Thank you.
^ permalink raw reply
* Re: [PATCH net v3] net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a global address
From: David Miller @ 2019-08-03 0:29 UTC (permalink / raw)
To: suyj.fnst; +Cc: kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <1564537972-76503-1-git-send-email-suyj.fnst@cn.fujitsu.com>
From: Su Yanjun <suyj.fnst@cn.fujitsu.com>
Date: Wed, 31 Jul 2019 09:52:52 +0800
> When the egress interface does not have a link local address, it can
> not communicate with other hosts.
>
> In RFC4861, 7.2.2 says
> "If the source address of the packet prompting the solicitation is the
> same as one of the addresses assigned to the outgoing interface, that
> address SHOULD be placed in the IP Source Address of the outgoing
> solicitation. Otherwise, any one of the addresses assigned to the
> interface should be used."
>
> In this patch we try get a global address if we get ll address failed.
>
> Signed-off-by: Su Yanjun <suyj.fnst@cn.fujitsu.com>
> ---
> Changes since V2:
> - Let banned_flags under the scope of its use.
I do not want to apply this.
The only situation where this can occur is when userland is managing the
interface addresses and has failed to properly add a link local address.
That is a failure by userspace to uphold it's responsibilites when it
has taken over management of these issues, not a situation the kernel
should handle.
Sorry.
^ permalink raw reply
* Re: [PATCH] atm: iphase: Fix Spectre v1 vulnerability
From: David Miller @ 2019-08-03 0:31 UTC (permalink / raw)
To: gustavo; +Cc: 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20190731032141.GA30246@embeddedor>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 30 Jul 2019 22:21:41 -0500
> board is controlled by user-space, hence leading to a potential
> exploitation of the Spectre variant 1 vulnerability.
>
> This issue was detected with the help of Smatch:
Applied and queued up for -stable.
Do not CC: -stable for networking fixes, we take care of the stable
submissions manually for this subsystem.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: phy: Add AST2600 MDIO support
From: David Miller @ 2019-08-03 0:33 UTC (permalink / raw)
To: andrew
Cc: netdev, robh+dt, mark.rutland, joel, andrew, f.fainelli,
hkallweit1, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20190731053959.16293-1-andrew@aj.id.au>
From: Andrew Jeffery <andrew@aj.id.au>
Date: Wed, 31 Jul 2019 15:09:55 +0930
> v2 of the ASPEED MDIO series addresses comments from Rob on the devicetree
> bindings and Andrew on the driver itself.
>
> v1 of the series can be found here:
>
> http://patchwork.ozlabs.org/cover/1138140/
>
> Please review!
Series applied, thank you.
^ permalink raw reply
* RE: [PATCH v2 net] hv_sock: Fix hang when a connection is closed
From: Dexuan Cui @ 2019-08-03 0:49 UTC (permalink / raw)
To: David Miller
Cc: Sunil Muthuswamy, netdev@vger.kernel.org, KY Srinivasan,
Haiyang Zhang, Stephen Hemminger, sashal@kernel.org,
Michael Kelley, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org, olaf@aepfle.de, apw@canonical.com,
jasowang@redhat.com, vkuznets, marcelo.cerri@canonical.com
In-Reply-To: <20190802.172729.1656276508211556851.davem@davemloft.net>
> From: linux-hyperv-owner@vger.kernel.org
> Sent: Friday, August 2, 2019 5:27 PM
> ...
> Applied and queued up for -stable.
>
> Do not ever CC: stable for networking patches, we submit to -stable manually.
Thanks, David!
I'll remember to not add the stable tag for network patches.
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH] net/ethernet/qlogic/qed: force the string buffer NULL-terminated
From: David Miller @ 2019-08-03 0:57 UTC (permalink / raw)
To: xywang.sjtu; +Cc: aelior, GR-everest-linux-l2, netdev
In-Reply-To: <20190731081542.14178-1-xywang.sjtu@sjtu.edu.cn>
From: Wang Xiayang <xywang.sjtu@sjtu.edu.cn>
Date: Wed, 31 Jul 2019 16:15:42 +0800
> strncpy() does not ensure NULL-termination when the input string
> size equals to the destination buffer size 30.
> The output string is passed to qed_int_deassertion_aeu_bit()
> which calls DP_INFO() and relies NULL-termination.
>
> Use strlcpy instead. The other conditional branch above strncpy()
> needs no fix as snprintf() ensures NULL-termination.
>
> This issue is identified by a Coccinelle script.
>
> Signed-off-by: Wang Xiayang <xywang.sjtu@sjtu.edu.cn>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: dsa: mv88e6xxx: add support for MV88E6220
From: David Miller @ 2019-08-03 0:59 UTC (permalink / raw)
To: h.feurstein
Cc: netdev, linux-kernel, andrew, vivien.didelot, f.fainelli,
rasmus.villemoes
In-Reply-To: <20190731082351.3157-1-h.feurstein@gmail.com>
From: Hubert Feurstein <h.feurstein@gmail.com>
Date: Wed, 31 Jul 2019 10:23:45 +0200
> This patch series adds support for the MV88E6220 chip to the mv88e6xxx driver.
> The MV88E6220 is almost the same as MV88E6250 except that the ports 2-4 are
> not routed to pins.
>
> Furthermore, PTP support is added to the MV88E6250 family.
>
> v2:
> - insert all 6220 entries in correct numerical order
> - introduce invalid_port_mask
> - move ptp_cc_mult* to ptp_ops and restored original ptp_adjfine code
> - added Andrews Reviewed-By to patch 2 and 4
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH] atm: iphase: Fix Spectre v1 vulnerability
From: Gustavo A. R. Silva @ 2019-08-03 0:42 UTC (permalink / raw)
To: David Miller; +Cc: 3chas3, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20190802.173125.399771294364845553.davem@davemloft.net>
Hi Dave,
On 8/2/19 7:31 PM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 30 Jul 2019 22:21:41 -0500
>
>> board is controlled by user-space, hence leading to a potential
>> exploitation of the Spectre variant 1 vulnerability.
>>
>> This issue was detected with the help of Smatch:
>
> Applied and queued up for -stable.
>
> Do not CC: -stable for networking fixes, we take care of the stable
> submissions manually for this subsystem.
>
Yeah. I'm aware of that. The thing is that you don't appear
as a maintainer of this file:
$ scripts/get_maintainer.pl --nokeywords --nogit --nogit-fallback -f drivers/atm/iphase.c
Chas Williams <3chas3@gmail.com> (maintainer:ATM)
linux-atm-general@lists.sourceforge.net (moderated list:ATM)
netdev@vger.kernel.org (open list:ATM)
linux-kernel@vger.kernel.org (open list)
so, I didn't know this patch would be applied to net.
Thanks
--
Gustavo
^ permalink raw reply
* Re: [PATCH] net: mdio-octeon: Fix build error and Kconfig warning
From: David Miller @ 2019-08-03 1:11 UTC (permalink / raw)
To: natechancellor
Cc: andrew, broonie, devel, f.fainelli, gregkh, hkallweit1,
kernel-build-reports, linux-arm-kernel, linux-next, netdev, willy,
lkp, rdunlap
In-Reply-To: <20190731185023.20954-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Wed, 31 Jul 2019 11:50:24 -0700
> arm allyesconfig warns:
>
> WARNING: unmet direct dependencies detected for MDIO_OCTEON
> Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=y]
> Selected by [y]:
> - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC &&
> NETDEVICES [=y] || COMPILE_TEST [=y])
>
> and errors:
>
> In file included from ../drivers/net/phy/mdio-octeon.c:14:
> ../drivers/net/phy/mdio-octeon.c: In function 'octeon_mdiobus_probe':
> ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> function 'writeq'; did you mean 'writeb'?
The proper way to fix this is to include either
linux/io-64-nonatomic-hi-lo.h
or
linux/io-64-nonatomic-lo-hi.h
whichever is appropriate.
^ permalink raw reply
* Re: [PATCH net] net: phy: fix race in genphy_update_link
From: David Miller @ 2019-08-03 1:15 UTC (permalink / raw)
To: hkallweit1; +Cc: andrew, f.fainelli, netdev, liuyonglong
In-Reply-To: <19122a98-cfcd-424c-a598-e034c1a9349d@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 31 Jul 2019 23:05:10 +0200
> In phy_start_aneg() autoneg is started, and immediately after that
> link and autoneg status are read. As reported in [0] it can happen that
> at time of this read the PHY has reset the "aneg complete" bit but not
> yet the "link up" bit, what can result in a false link-up detection.
> To fix this don't report link as up if we're in aneg mode and PHY
> doesn't signal "aneg complete".
>
> [0] https://marc.info/?t=156413509900003&r=1&w=2
>
> Fixes: 4950c2ba49cc ("net: phy: fix autoneg mismatch case in genphy_read_status")
> Reported-by: liuyonglong <liuyonglong@huawei.com>
> Tested-by: liuyonglong <liuyonglong@huawei.com>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] enetc: Select PHYLIB while CONFIG_FSL_ENETC_VF is set
From: David Miller @ 2019-08-03 1:15 UTC (permalink / raw)
To: yuehaibing; +Cc: claudiu.manoil, linux-kernel, netdev
In-Reply-To: <20190801012419.9728-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 1 Aug 2019 09:24:19 +0800
> Like FSL_ENETC, when CONFIG_FSL_ENETC_VF is set,
> we should select PHYLIB, otherwise building still fails:
>
> drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
> enetc.c:(.text+0x2744): undefined reference to `phy_start'
> enetc.c:(.text+0x282c): undefined reference to `phy_disconnect'
> drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_close':
> enetc.c:(.text+0x28f8): undefined reference to `phy_stop'
> enetc.c:(.text+0x2904): undefined reference to `phy_disconnect'
> drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x3f8): undefined reference to `phy_ethtool_get_link_ksettings'
> drivers/net/ethernet/freescale/enetc/enetc_ethtool.o:(.rodata+0x400): undefined reference to `phy_ethtool_set_link_ksettings'
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] r8152: fix typo in register name
From: David Miller @ 2019-08-03 1:17 UTC (permalink / raw)
To: kevlo; +Cc: hayeswang, netdev
In-Reply-To: <20190801032938.GA22256@ns.kevlo.org>
From: Kevin Lo <kevlo@kevlo.org>
Date: Thu, 1 Aug 2019 11:29:38 +0800
> It is likely that PAL_BDC_CR should be PLA_BDC_CR.
>
> Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Applied.
^ permalink raw reply
* NFSv4: rare bug *and* root cause captured in the wild
From: John Hubbard @ 2019-08-03 1:27 UTC (permalink / raw)
To: Trond Myklebust, Anna Schumaker, David S. Miller, Chuck Lever,
J. Bruce Fields, linux-nfs, netdev, LKML
Hi,
While testing unrelated (put_user_pages) work on Linux 5.3-rc2+,
I rebooted the NFS *server*, tried to ssh to the client, and the
client dumped a backtrace as shown below.
Good news: I found that I can reliably reproduce it with those steps,
at commit 1e78030e5e5b (in linux.git) plus my 34-patch series [1], which
off course is completely unrelated. :) Anyway, I'm making a note of the
exact repro commit, so I don't lose the repro.
I see what's wrong, but I do *not* see an easy fix. Can one of the
designers please recommend an approach to fixing this?
This is almost certainly caused by commit 7e0a0e38fcfe ("SUNRPC:
Replace the queue timer with a delayed work function"), which changed
over to running things in process (kthread) context. The commit is dated
May 1, 2019, but I've only been running NFSv4 for a couple days, so
the problem has likely been there all along, not specific to 5.3.
The call stack starts off in atomic context, so we get the bug:
nfs4_do_reclaim
rcu_read_lock /* we are now in_atomic() and must not sleep */
nfs4_purge_state_owners
nfs4_free_state_owner
nfs4_destroy_seqid_counter
rpc_destroy_wait_queue
cancel_delayed_work_sync
__cancel_work_timer
__flush_work
start_flush_work
might_sleep:
(kernel/workqueue.c:2975: BUG)
Details: actual backtrace I am seeing:
BUG: sleeping function called from invalid context at kernel/workqueue.c:2975
in_atomic(): 1, irqs_disabled(): 0, pid: 2224, name: 10.110.48.28-ma
1 lock held by 10.110.48.28-ma/2224:
#0: 00000000d338d2ec (rcu_read_lock){....}, at: nfs4_do_reclaim+0x22/0x6b0 [nfsv4]
CPU: 8 PID: 2224 Comm: 10.110.48.28-ma Not tainted 5.3.0-rc2-hubbard-github+ #52
Hardware name: ASUS X299-A/PRIME X299-A, BIOS 1704 02/14/2019
Call Trace:
dump_stack+0x46/0x60
___might_sleep.cold+0x8e/0x9b
__flush_work+0x61/0x370
? find_held_lock+0x2b/0x80
? add_timer+0x100/0x200
? _raw_spin_lock_irqsave+0x35/0x40
__cancel_work_timer+0xfb/0x180
? nfs4_purge_state_owners+0xf4/0x170 [nfsv4]
nfs4_free_state_owner+0x10/0x50 [nfsv4]
nfs4_purge_state_owners+0x139/0x170 [nfsv4]
nfs4_do_reclaim+0x7a/0x6b0 [nfsv4]
? pnfs_destroy_layouts_byclid+0xc4/0x100 [nfsv4]
nfs4_state_manager+0x6be/0x7f0 [nfsv4]
nfs4_run_state_manager+0x1b/0x40 [nfsv4]
kthread+0xfb/0x130
? nfs4_state_manager+0x7f0/0x7f0 [nfsv4]
? kthread_bind+0x20/0x20
ret_from_fork+0x35/0x40
And last but not least, some words of encouragement: the reason I moved
from NFSv3 to NFSv4 is that the easy authentication (matching UIDs on
client and server) now works perfectly. Yea! So I'm enjoying v4, despite
the occasional minor glitch. :)
[1] https://lore.kernel.org/r/20190802022005.5117-1-jhubbard@nvidia.com
thanks,
--
John Hubbard
NVIDIA
^ permalink raw reply
* Re: [PATCH] net: mdio-octeon: Fix build error and Kconfig warning
From: Nathan Chancellor @ 2019-08-03 1:30 UTC (permalink / raw)
To: David Miller
Cc: andrew, broonie, devel, f.fainelli, gregkh, hkallweit1,
kernel-build-reports, linux-arm-kernel, linux-next, netdev, willy,
lkp, rdunlap
In-Reply-To: <20190802.181132.1425585873361511856.davem@davemloft.net>
On Fri, Aug 02, 2019 at 06:11:32PM -0700, David Miller wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Wed, 31 Jul 2019 11:50:24 -0700
>
> > arm allyesconfig warns:
> >
> > WARNING: unmet direct dependencies detected for MDIO_OCTEON
> > Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> > && 64BIT && HAS_IOMEM [=y] && OF_MDIO [=y]
> > Selected by [y]:
> > - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC &&
> > NETDEVICES [=y] || COMPILE_TEST [=y])
> >
> > and errors:
> >
> > In file included from ../drivers/net/phy/mdio-octeon.c:14:
> > ../drivers/net/phy/mdio-octeon.c: In function 'octeon_mdiobus_probe':
> > ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> > function 'writeq'; did you mean 'writeb'?
>
> The proper way to fix this is to include either
>
> linux/io-64-nonatomic-hi-lo.h
>
> or
>
> linux/io-64-nonatomic-lo-hi.h
>
> whichever is appropriate.
Hmmmm, is that not what I did?
Although I did not know about io-64-nonatomic-hi-lo.h. What is the
difference and which one is needed here?
There is apparently another failure when OF_MDIO is not set, I guess I
can try to look into that as well and respin into a series if
necessary.
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH 31/34] nfs: convert put_page() to put_user_page*()
From: Calum Mackay @ 2019-08-03 1:27 UTC (permalink / raw)
To: john.hubbard, Andrew Morton
Cc: calum.mackay, Christoph Hellwig, Dan Williams, Dave Chinner,
Dave Hansen, Ira Weiny, Jan Kara, Jason Gunthorpe,
Jérôme Glisse, LKML, amd-gfx, ceph-devel, devel, devel,
dri-devel, intel-gfx, kvm, linux-arm-kernel, linux-block,
linux-crypto, linux-fbdev, linux-fsdevel, linux-media, linux-mm,
linux-nfs, linux-rdma, linux-rpi-kernel, linux-xfs, netdev,
rds-devel, sparclinux, x86, xen-devel, John Hubbard,
Trond Myklebust, Anna Schumaker
In-Reply-To: <20190802022005.5117-32-jhubbard@nvidia.com>
On 02/08/2019 3:20 am, john.hubbard@gmail.com wrote:
> From: John Hubbard <jhubbard@nvidia.com>
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Trond Myklebust <trond.myklebust@hammerspace.com>
> Cc: Anna Schumaker <anna.schumaker@netapp.com>
> Cc: linux-nfs@vger.kernel.org
> Signed-off-by: John Hubbard <jhubbard@nvidia.com>
> ---
> fs/nfs/direct.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
> index 0cb442406168..b00b89dda3c5 100644
> --- a/fs/nfs/direct.c
> +++ b/fs/nfs/direct.c
> @@ -278,9 +278,7 @@ ssize_t nfs_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
>
> static void nfs_direct_release_pages(struct page **pages, unsigned int npages)
> {
> - unsigned int i;
> - for (i = 0; i < npages; i++)
> - put_page(pages[i]);
> + put_user_pages(pages, npages);
> }
Since it's static, and only called twice, might it be better to change
its two callers [nfs_direct_{read,write}_schedule_iovec()] to call
put_user_pages() directly, and remove nfs_direct_release_pages() entirely?
thanks,
calum.
>
> void nfs_init_cinfo_from_dreq(struct nfs_commit_info *cinfo,
>
^ permalink raw reply
* Re: [PATCH] net: mdio-octeon: Fix build error and Kconfig warning
From: Matthew Wilcox @ 2019-08-03 1:39 UTC (permalink / raw)
To: Nathan Chancellor
Cc: David Miller, andrew, broonie, devel, f.fainelli, gregkh,
hkallweit1, kernel-build-reports, linux-arm-kernel, linux-next,
netdev, lkp, rdunlap
In-Reply-To: <20190803013031.GA76252@archlinux-threadripper>
On Fri, Aug 02, 2019 at 06:30:31PM -0700, Nathan Chancellor wrote:
> On Fri, Aug 02, 2019 at 06:11:32PM -0700, David Miller wrote:
> > The proper way to fix this is to include either
> >
> > linux/io-64-nonatomic-hi-lo.h
> >
> > or
> >
> > linux/io-64-nonatomic-lo-hi.h
> >
> > whichever is appropriate.
>
> Hmmmm, is that not what I did?
>
> Although I did not know about io-64-nonatomic-hi-lo.h. What is the
> difference and which one is needed here?
Whether you write the high or low 32 bits first. For this, it doesn't
matter, since the compiled driver will never be run on real hardware.
> There is apparently another failure when OF_MDIO is not set, I guess I
> can try to look into that as well and respin into a series if
> necessary.
Thanks for taking care of that!
^ permalink raw reply
* Re: [PATCH 31/34] nfs: convert put_page() to put_user_page*()
From: John Hubbard @ 2019-08-03 1:41 UTC (permalink / raw)
To: Calum Mackay, john.hubbard, Andrew Morton
Cc: Christoph Hellwig, Dan Williams, Dave Chinner, Dave Hansen,
Ira Weiny, Jan Kara, Jason Gunthorpe, Jérôme Glisse,
LKML, amd-gfx, ceph-devel, devel, devel, dri-devel, intel-gfx,
kvm, linux-arm-kernel, linux-block, linux-crypto, linux-fbdev,
linux-fsdevel, linux-media, linux-mm, linux-nfs, linux-rdma,
linux-rpi-kernel, linux-xfs, netdev, rds-devel, sparclinux, x86,
xen-devel, Trond Myklebust, Anna Schumaker
In-Reply-To: <1738cb1e-15d8-0bbe-5362-341664f6efc8@oracle.com>
On 8/2/19 6:27 PM, Calum Mackay wrote:
> On 02/08/2019 3:20 am, john.hubbard@gmail.com wrote:
...
> Since it's static, and only called twice, might it be better to change its two callers [nfs_direct_{read,write}_schedule_iovec()] to call put_user_pages() directly, and remove nfs_direct_release_pages() entirely?
>
> thanks,
> calum.
>
>
>> void nfs_init_cinfo_from_dreq(struct nfs_commit_info *cinfo,
>>
Hi Calum,
Absolutely! Is it OK to add your reviewed-by, with the following incremental
patch made to this one?
diff --git a/fs/nfs/direct.c b/fs/nfs/direct.c
index b00b89dda3c5..c0c1b9f2c069 100644
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -276,11 +276,6 @@ ssize_t nfs_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
return nfs_file_direct_write(iocb, iter);
}
-static void nfs_direct_release_pages(struct page **pages, unsigned int npages)
-{
- put_user_pages(pages, npages);
-}
-
void nfs_init_cinfo_from_dreq(struct nfs_commit_info *cinfo,
struct nfs_direct_req *dreq)
{
@@ -510,7 +505,7 @@ static ssize_t nfs_direct_read_schedule_iovec(struct nfs_direct_req *dreq,
pos += req_len;
dreq->bytes_left -= req_len;
}
- nfs_direct_release_pages(pagevec, npages);
+ put_user_pages(pagevec, npages);
kvfree(pagevec);
if (result < 0)
break;
@@ -933,7 +928,7 @@ static ssize_t nfs_direct_write_schedule_iovec(struct nfs_direct_req *dreq,
pos += req_len;
dreq->bytes_left -= req_len;
}
- nfs_direct_release_pages(pagevec, npages);
+ put_user_pages(pagevec, npages);
kvfree(pagevec);
if (result < 0)
break;
thanks,
--
John Hubbard
NVIDIA
^ 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