* Re: [PATCH v5 bpf-next 0/4] capture integers in BTF type info for map defs
From: Andrii Nakryiko @ 2019-07-06 3:49 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Andrii Nakryiko, Kernel Team, Alexei Starovoitov, Networking, bpf
In-Reply-To: <86f8f511-655c-bf9e-8d78-f2e3f65efdb9@iogearbox.net>
On Fri, Jul 5, 2019 at 2:15 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 07/05/2019 05:50 PM, Andrii Nakryiko wrote:
> > This patch set implements an update to how BTF-defined maps are specified. The
> > change is in how integer attributes, e.g., type, max_entries, map_flags, are
> > specified: now they are captured as part of map definition struct's BTF type
> > information (using array dimension), eliminating the need for compile-time
> > data initialization and keeping all the metadata in one place.
> >
> > All existing selftests that were using BTF-defined maps are updated, along
> > with some other selftests, that were switched to new syntax.
> >
> > v4->v5:
> > - revert sample_map_ret0.c, which is loaded with iproute2 (kernel test robot);
> > v3->v4:
> > - add acks;
> > - fix int -> uint type in commit message;
> > v2->v3:
> > - rename __int into __uint (Yonghong);
> > v1->v2:
> > - split bpf_helpers.h change from libbpf change (Song).
> >
> > Andrii Nakryiko (4):
> > libbpf: capture value in BTF type info for BTF-defined map defs
> > selftests/bpf: add __uint and __type macro for BTF-defined maps
> > selftests/bpf: convert selftests using BTF-defined maps to new syntax
> > selftests/bpf: convert legacy BPF maps to BTF-defined ones
> >
> > tools/lib/bpf/libbpf.c | 58 +++++----
> > tools/testing/selftests/bpf/bpf_helpers.h | 3 +
> > tools/testing/selftests/bpf/progs/bpf_flow.c | 28 ++---
> > .../selftests/bpf/progs/get_cgroup_id_kern.c | 26 ++---
> > .../testing/selftests/bpf/progs/netcnt_prog.c | 20 ++--
> > tools/testing/selftests/bpf/progs/pyperf.h | 90 +++++++-------
> > .../selftests/bpf/progs/socket_cookie_prog.c | 13 +--
> > .../bpf/progs/sockmap_verdict_prog.c | 48 ++++----
> > .../testing/selftests/bpf/progs/strobemeta.h | 68 +++++------
> > .../selftests/bpf/progs/test_btf_newkv.c | 13 +--
> > .../bpf/progs/test_get_stack_rawtp.c | 39 +++----
> > .../selftests/bpf/progs/test_global_data.c | 37 +++---
> > tools/testing/selftests/bpf/progs/test_l4lb.c | 65 ++++-------
> > .../selftests/bpf/progs/test_l4lb_noinline.c | 65 ++++-------
> > .../selftests/bpf/progs/test_map_in_map.c | 30 ++---
> > .../selftests/bpf/progs/test_map_lock.c | 26 ++---
> > .../testing/selftests/bpf/progs/test_obj_id.c | 12 +-
> > .../bpf/progs/test_select_reuseport_kern.c | 67 ++++-------
> > .../bpf/progs/test_send_signal_kern.c | 26 ++---
> > .../bpf/progs/test_sock_fields_kern.c | 78 +++++--------
> > .../selftests/bpf/progs/test_spin_lock.c | 36 +++---
> > .../bpf/progs/test_stacktrace_build_id.c | 55 ++++-----
> > .../selftests/bpf/progs/test_stacktrace_map.c | 52 +++------
> > .../selftests/bpf/progs/test_tcp_estats.c | 13 +--
> > .../selftests/bpf/progs/test_tcpbpf_kern.c | 26 ++---
> > .../selftests/bpf/progs/test_tcpnotify_kern.c | 28 ++---
> > tools/testing/selftests/bpf/progs/test_xdp.c | 26 ++---
> > .../selftests/bpf/progs/test_xdp_loop.c | 26 ++---
> > .../selftests/bpf/progs/test_xdp_noinline.c | 81 +++++--------
> > .../selftests/bpf/progs/xdp_redirect_map.c | 12 +-
> > .../testing/selftests/bpf/progs/xdping_kern.c | 12 +-
> > .../selftests/bpf/test_queue_stack_map.h | 30 ++---
> > .../testing/selftests/bpf/test_sockmap_kern.h | 110 +++++++++---------
> > 33 files changed, 559 insertions(+), 760 deletions(-)
>
> LGTM, applied, thanks! Shouldn't we also move __uint and __type macros
> into libbpf as otherwise people tend to redefine this over and over?
Yes, we need something like bpf_helpers.h as part of libbpf for
inclusion into BPF programs. It's on my todo list as part of BPF CO-RE
project as well.
^ permalink raw reply
* Re: [PATCH v5 bpf-next 4/9] libbpf: add kprobe/uprobe attach API
From: Andrii Nakryiko @ 2019-07-06 3:48 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Andrii Nakryiko, bpf, Networking, Alexei Starovoitov, Kernel Team,
Yonghong Song
In-Reply-To: <a24b3328-2d4a-17f2-3aa3-756af7432e6b@iogearbox.net>
On Fri, Jul 5, 2019 at 1:46 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 07/04/2019 02:57 AM, Andrii Nakryiko wrote:
> > On Wed, Jul 3, 2019 at 9:47 AM Andrii Nakryiko
> > <andrii.nakryiko@gmail.com> wrote:
> [...]
> >> [1] https://lore.kernel.org/bpf/20190621045555.4152743-4-andriin@fb.com/T/#m6cfc141e7b57970bc948134bf671a46972b95134
> >>
> >>> with bpf_link with destructor looks good to me, but my feedback from back then was
> >>> that all the kprobe/uprobe/tracepoint/raw_tracepoint should be split API-wise, so
> >>> you'll end up with something like the below, that is, 1) a set of functions that
> >>> only /create/ the bpf_link handle /once/, and 2) a helper that allows /attaching/
> >>> progs to one or multiple bpf_links. The set of APIs would look like:
> >>>
> >>> struct bpf_link *bpf_link__create_kprobe(bool retprobe, const char *func_name);
> >>> struct bpf_link *bpf_link__create_uprobe(bool retprobe, pid_t pid,
> >>> const char *binary_path,
> >>> size_t func_offset);
> >>> int bpf_program__attach_to_link(struct bpf_link *link, struct bpf_program *prog);
> >>> int bpf_link__destroy(struct bpf_link *link);
> >>>
> >>> This seems much more natural to me. Right now you sort of do both in one single API.
> >>
> >> It felt that way for me as well, until I implemented it and used it in
> >> selftests. And then it felt unnecessarily verbose without giving any
> >> benefit. I still have a local patchset with that change, I can post it
> >> as RFC, if you don't trust my judgement. Please let me know.
> >>
> >>> Detangling the bpf_program__attach_{uprobe,kprobe}() would also avoid that you have
> >>> to redo all the perf_event_open_probe() work over and over in order to get the pfd
> >
> > So re-reading this again, I wonder if you meant that with separate
> > bpf_link (or rather bpf_hook in that case) creation and attachment
> > operations, one would be able to create single bpf_hook for same
> > kprobe and then attach multiple BPF programs to that single pfd
> > representing that specific probe.
> >
> > If that's how I should have read it, I agree that it probably would be
> > possible for some types of hooks, but not for every type of hook. But
> > furthermore, how often in practice same application attaches many
> > different BPF programs to the same hook? And it's also hard to imagine
> > that hook creation (i.e., creating such FD for BPF hook), would ever
> > be a bottleneck.
> >
> > So I still think it's not a strong reason to go with API that's harder
> > to use for typical use cases just because of hypothetical benefits in
> > some extreme cases.
>
> Was thinking along that lines, yes, as we run over an array of BPF progs,
> but I just double checked the kernel code again and the relationship of
> a BPF prog to perf_event is really just 1:1, just that the backing tp_event
> (trace_event_call) contains the shared array. Given that, all makes sense
> and there is no point in splitting. Therefore, applied, thanks!
Great, thanks a lot!
^ permalink raw reply
* [PATCH] net: axienet: fix a potential double free in axienet_probe()
From: Wen Yang @ 2019-07-06 3:38 UTC (permalink / raw)
To: linux-kernel
Cc: xue.zhihong, wang.yi59, cheng.shengyu, Wen Yang, Anirudha Sarangi,
John Linn, David S. Miller, Michal Simek, Robert Hancock, netdev,
linux-arm-kernel
There is a possible use-after-free issue in the axienet_probe():
1701: np = of_parse_phandle(pdev->dev.of_node, "axistream-connected", 0);
1702: if (np) {
...
1787: of_node_put(np); ---> released here
1788: lp->eth_irq = platform_get_irq(pdev, 0);
1789: } else {
...
1801: }
1802: if (IS_ERR(lp->dma_regs)) {
...
1805: of_node_put(np); ---> double released here
1806: goto free_netdev;
1807: }
We solve this problem by removing the unnecessary of_node_put().
Fixes: 28ef9ebdb64c ("net: axienet: make use of axistream-connected attribute optional")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Anirudha Sarangi <anirudh@xilinx.com>
Cc: John Linn <John.Linn@xilinx.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Robert Hancock <hancock@sedsystems.ca>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index 561e28a..4fc627f 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -1802,7 +1802,6 @@ static int axienet_probe(struct platform_device *pdev)
if (IS_ERR(lp->dma_regs)) {
dev_err(&pdev->dev, "could not map DMA regs\n");
ret = PTR_ERR(lp->dma_regs);
- of_node_put(np);
goto free_netdev;
}
if ((lp->rx_irq <= 0) || (lp->tx_irq <= 0)) {
--
2.9.5
^ permalink raw reply related
* [PATCH] can: flexcan: fix an use-after-free in flexcan_setup_stop_mode()
From: Wen Yang @ 2019-07-06 3:37 UTC (permalink / raw)
To: linux-kernel
Cc: xue.zhihong, wang.yi59, cheng.shengyu, Wen Yang,
Wolfgang Grandegger, Marc Kleine-Budde, David S. Miller,
linux-can, netdev
The gpr_np variable is still being used in dev_dbg() after the
of_node_put() call, which may result in use-after-free.
Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-can@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/can/flexcan.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
index f2fe344..33ce45d 100644
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -1437,10 +1437,10 @@ static int flexcan_setup_stop_mode(struct platform_device *pdev)
priv = netdev_priv(dev);
priv->stm.gpr = syscon_node_to_regmap(gpr_np);
- of_node_put(gpr_np);
if (IS_ERR(priv->stm.gpr)) {
dev_dbg(&pdev->dev, "could not find gpr regmap\n");
- return PTR_ERR(priv->stm.gpr);
+ ret = PTR_ERR(priv->stm.gpr);
+ goto out_put_node;
}
priv->stm.req_gpr = out_val[1];
@@ -1455,7 +1455,9 @@ static int flexcan_setup_stop_mode(struct platform_device *pdev)
device_set_wakeup_capable(&pdev->dev, true);
- return 0;
+out_put_node:
+ of_node_put(gpr_np);
+ return ret;
}
static const struct of_device_id flexcan_of_match[] = {
--
2.9.5
^ permalink raw reply related
* epoll_wait() (and epoll_pwait) stall for 206 ms per call on sockets with a small-ish snd/rcv buffer.
From: Carlo Wood @ 2019-07-06 1:45 UTC (permalink / raw)
To: davem, netdev
Hi all,
hopefully I'm reporting this in the right place.
While working on my C++ networking library, I ran into a problem that
I have traced back to the kernel itself.
The problem is related to setting a socket buffer size (snd/rcv).
At first I noticed the problem while trying to test the thread-safety
of my lock free stream buffer implementation, with std::streambuf
interface, that allows reading and writing by different threads
at the same time. In order to test this, I read data from a socket
into a buffer and write that back to the same socket from the
same buffer. This resulted in a speed of only a few 10kB/s bandwidth,
and after investigation turned out to be caused by epoll_pwait()
not returning until 205 to 208 ms had passed, even though data was
already available.
At first I thought it could be a bug in libev that I was using as
wrapper around epoll - so I ripped that out and wrote my own code to
interface with epoll, but with the same result. Next I changed the test
into a one-way stream: just send data from one socket to another (not
back); also with the same result. Then I wrote a test application that
was standalone, single threaded and in C. Here I discovered that first
calling connect() on a socket and then (immediately after) setting the
socket buffer sizes caused the stall to occur. Assuming that this
is not allowed I thought I had solved it.
But, back to sending data back and forth over the TCP connection
caused the problem to return.
I wrote again a standalone C program, single threaded, that
reproduces the problem.
You can find this program here (I'm scared to trigger spam filters
by attaching it here, but let me know if that is OK):
https://github.com/CarloWood/ai-evio-testsuite/blob/e6e36b66256ec5d1760d2b7b96b34d60a12477aa/src/epoll_bug.c
With socket snd/rcv buffers smaller than 32kB I always get
the problem, but using 64kB (65536 bytes) I don't, on my box.
I tested this with kernels 4.15, 5.2.0-rc7 and had someone
else confirm it with 5.1.15.
When running the program as-is, it will start printing a flood
of "epoll_wait() was delayed!" meaning that epoll_wait() didn't
return within 10 ms. The actual delay can be seen with for
example strace -T. You can also uncomment the commented printf's
which will print what is the amount of bytes written to and read
from each socket and therefore what is the number of bytes that
are still "in the pipe line".
What I observe is that the number of bytes in the pipe line is
very constant (because this just writes till no more can be
written, and then - on the other end - reads till there is nothing
to be read anymore - and that single threaded) until suddenly
that amount jumps UP to about 2.5 MB - then is SLOWLY eaten till
a say 1.5 MB (without that epoll says more can be written)
when suddenly more can be written and it fills up the pipe line
again.
I have no idea where those mega bytes of data are buffered; the
socket buffers are WAY smaller.
Obviously I have no idea if this is a problem with epoll itself,
or that there is a problem with TCP/IP for this case.
But I am not a kernel hacker, so all I could to was provide this
little test case that allows you to reproduce it.
--
Carlo Wood <carlo@alinoe.com>
^ permalink raw reply
* Re: bonded active-backup ethernet-wifi drops packets
From: Jay Vosburgh @ 2019-07-06 0:46 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: netdev
In-Reply-To: <8d40b6ed3bf8a7540cff26e3834f0296228d9922.camel@interlinx.bc.ca>
Brian J. Murrell <brian@interlinx.bc.ca> wrote:
>On Tue, 2019-06-18 at 14:57 -0400, Brian J. Murrell wrote:
>> Hi.
>>
>> I have an active-backup bonded connection on a 5.1.6 kernel where the
>> slaves are an Ethernet interface and a wifi interface. The goal is
>> to
>> have network transparent (i.e. same and IP address on both
>> interfaces)
>> interface which takes advantage of high-speed and low-latency when it
>> can be physically plugged into the wired network but have portability
>> when unplugged through WiFi.
>>
>> It all works, mostly. :-/
>>
>> I find that even when the primary interface, being the Ethernet
>> interface is plugged in and active, the bonded interface will drop
>> packets periodically.
>>
>> If I down the bonded interface and plumb the Ethernet interface
>> directly, not as a slave of the bonded interface, no such packet
>> dropping occurs.
>>
>> My measure of packet dropping, is by observing the output of "sudo
>> ping
>> -f <ip_address>. In less than a few minutes even, on the bonded
>> interface, even with the Ethernet interface as the active slave, I
>> will
>> have a long string of dots indicating pings that were never
>> replied. On the unbonded Ethernet interface, no dots, even when
>> measured over many days.
>>
>> My bonding config:
>>
>> $ cat /proc/net/bonding/bond0
>> Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
>>
>> Bonding Mode: fault-tolerance (active-backup)
>> Primary Slave: enp0s31f6 (primary_reselect always)
>> Currently Active Slave: enp0s31f6
>> MII Status: up
>> MII Polling Interval (ms): 100
>> Up Delay (ms): 0
>> Down Delay (ms): 0
>>
>> Slave Interface: enp0s31f6
>> MII Status: up
>> Speed: 1000 Mbps
>> Duplex: full
>> Link Failure Count: 0
>> Permanent HW addr: 0c:54:15:4a:b2:0d
>> Slave queue ID: 0
>>
>> Slave Interface: wlp2s0
>> MII Status: up
>> Speed: Unknown
>> Duplex: Unknown
>> Link Failure Count: 1
>> Permanent HW addr: 0c:54:15:4a:b2:0d
>> Slave queue ID: 0
>>
>> Current interface config/stats:
>>
>> $ ifconfig bond0
>> bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
>> inet 10.75.22.245 netmask 255.255.255.0 broadcast
>> 10.75.22.255
>> inet6 fe80::ee66:b8c9:d55:a28f prefixlen 64 scopeid
>> 0x20<link>
>> inet6 2001:123:ab:123:d36d:5e5d:acc8:e9bc prefixlen
>> 64 scopeid 0x0<global>
>> ether 0c:54:15:4a:b2:0d txqueuelen 1000 (Ethernet)
>> RX packets 1596206 bytes 165221404 (157.5 MiB)
>> RX errors 0 dropped 0 overruns 0 frame 0
>> TX packets 1590552 bytes 162689350 (155.1 MiB)
>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>>
>> Devices:
>> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection
>> (2) I219-LM (rev 31)
>> 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275
>> (rev 78)
>>
>> Happy to provide any other useful information.
>>
>> Any ideas why the dropping, only when using the bonded interface?
>
>Wondering if I have the wrong list with this question. Is there a list
>where this question would be more on-topic or focused?
Not that I'm aware of; netdev is where bonding development
discussions and such take place.
>Perhaps I didn't provide enough information? I am happy to provide
>whatever is needed. I just don't know what more is needed at this
>point.
I did set this up and test it, but haven't had time to analyze
in depth.
What I saw was that ping (IPv4) flood worked fine, bonded or
not, over a span of several hours. However, ping6 showed small numbers
of drops on a ping6 flood when bonded, on the order of 200 drops out of
48,000,000 requests sent. Zero losses when no bond in the stack. Both
tests to the same peer connected to the same switch. All of the above
with the bond using the Ethernet slave. I haven't tracked down where
those losses are occurring, so I don't know if it's on the transmit or
receive sides (or both).
I did this testing on a laptop with iwlwifi (Centrino 6205) and
an e1000e (82579LM) network device, using the a kernel built from
net-next as of earlier this week (it claimed to be 5.2.0-rc5+).
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH v9 net-next 2/5] net: ethernet: ti: davinci_cpdma: add dma mapped submit
From: Ivan Khoronzhuk @ 2019-07-05 23:57 UTC (permalink / raw)
To: grygorii.strashko, hawk, davem
Cc: ast, linux-kernel, linux-omap, xdp-newbies, ilias.apalodimas,
netdev, daniel, jakub.kicinski, john.fastabend, Ivan Khoronzhuk
In-Reply-To: <20190705150502.6600-3-ivan.khoronzhuk@linaro.org>
In case if dma mapped packet needs to be sent, like with XDP
page pool, the "mapped" submit can be used. This patch adds dma
mapped submit based on regular one.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
v9..v8
- fix potential warnings on arm64 caused by typos in type casting
drivers/net/ethernet/ti/davinci_cpdma.c | 89 ++++++++++++++++++++++---
drivers/net/ethernet/ti/davinci_cpdma.h | 4 ++
2 files changed, 83 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 5cf1758d425b..4e693c3aab27 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -139,6 +139,7 @@ struct submit_info {
int directed;
void *token;
void *data;
+ int flags;
int len;
};
@@ -184,6 +185,8 @@ static struct cpdma_control_info controls[] = {
(directed << CPDMA_TO_PORT_SHIFT)); \
} while (0)
+#define CPDMA_DMA_EXT_MAP BIT(16)
+
static void cpdma_desc_pool_destroy(struct cpdma_ctlr *ctlr)
{
struct cpdma_desc_pool *pool = ctlr->pool;
@@ -1015,6 +1018,7 @@ static int cpdma_chan_submit_si(struct submit_info *si)
struct cpdma_chan *chan = si->chan;
struct cpdma_ctlr *ctlr = chan->ctlr;
int len = si->len;
+ int swlen = len;
struct cpdma_desc __iomem *desc;
dma_addr_t buffer;
u32 mode;
@@ -1036,16 +1040,22 @@ static int cpdma_chan_submit_si(struct submit_info *si)
chan->stats.runt_transmit_buff++;
}
- buffer = dma_map_single(ctlr->dev, si->data, len, chan->dir);
- ret = dma_mapping_error(ctlr->dev, buffer);
- if (ret) {
- cpdma_desc_free(ctlr->pool, desc, 1);
- return -EINVAL;
- }
-
mode = CPDMA_DESC_OWNER | CPDMA_DESC_SOP | CPDMA_DESC_EOP;
cpdma_desc_to_port(chan, mode, si->directed);
+ if (si->flags & CPDMA_DMA_EXT_MAP) {
+ buffer = (dma_addr_t)si->data;
+ dma_sync_single_for_device(ctlr->dev, buffer, len, chan->dir);
+ swlen |= CPDMA_DMA_EXT_MAP;
+ } else {
+ buffer = dma_map_single(ctlr->dev, si->data, len, chan->dir);
+ ret = dma_mapping_error(ctlr->dev, buffer);
+ if (ret) {
+ cpdma_desc_free(ctlr->pool, desc, 1);
+ return -EINVAL;
+ }
+ }
+
/* Relaxed IO accessors can be used here as there is read barrier
* at the end of write sequence.
*/
@@ -1055,7 +1065,7 @@ static int cpdma_chan_submit_si(struct submit_info *si)
writel_relaxed(mode | len, &desc->hw_mode);
writel_relaxed((uintptr_t)si->token, &desc->sw_token);
writel_relaxed(buffer, &desc->sw_buffer);
- writel_relaxed(len, &desc->sw_len);
+ writel_relaxed(swlen, &desc->sw_len);
desc_read(desc, sw_len);
__cpdma_chan_submit(chan, desc);
@@ -1079,6 +1089,32 @@ int cpdma_chan_idle_submit(struct cpdma_chan *chan, void *token, void *data,
si.data = data;
si.len = len;
si.directed = directed;
+ si.flags = 0;
+
+ spin_lock_irqsave(&chan->lock, flags);
+ if (chan->state == CPDMA_STATE_TEARDOWN) {
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return -EINVAL;
+ }
+
+ ret = cpdma_chan_submit_si(&si);
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return ret;
+}
+
+int cpdma_chan_idle_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed)
+{
+ struct submit_info si;
+ unsigned long flags;
+ int ret;
+
+ si.chan = chan;
+ si.token = token;
+ si.data = (void *)data;
+ si.len = len;
+ si.directed = directed;
+ si.flags = CPDMA_DMA_EXT_MAP;
spin_lock_irqsave(&chan->lock, flags);
if (chan->state == CPDMA_STATE_TEARDOWN) {
@@ -1103,6 +1139,32 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
si.data = data;
si.len = len;
si.directed = directed;
+ si.flags = 0;
+
+ spin_lock_irqsave(&chan->lock, flags);
+ if (chan->state != CPDMA_STATE_ACTIVE) {
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return -EINVAL;
+ }
+
+ ret = cpdma_chan_submit_si(&si);
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return ret;
+}
+
+int cpdma_chan_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed)
+{
+ struct submit_info si;
+ unsigned long flags;
+ int ret;
+
+ si.chan = chan;
+ si.token = token;
+ si.data = (void *)data;
+ si.len = len;
+ si.directed = directed;
+ si.flags = CPDMA_DMA_EXT_MAP;
spin_lock_irqsave(&chan->lock, flags);
if (chan->state != CPDMA_STATE_ACTIVE) {
@@ -1140,10 +1202,17 @@ static void __cpdma_chan_free(struct cpdma_chan *chan,
uintptr_t token;
token = desc_read(desc, sw_token);
- buff_dma = desc_read(desc, sw_buffer);
origlen = desc_read(desc, sw_len);
- dma_unmap_single(ctlr->dev, buff_dma, origlen, chan->dir);
+ buff_dma = desc_read(desc, sw_buffer);
+ if (origlen & CPDMA_DMA_EXT_MAP) {
+ origlen &= ~CPDMA_DMA_EXT_MAP;
+ dma_sync_single_for_cpu(ctlr->dev, buff_dma, origlen,
+ chan->dir);
+ } else {
+ dma_unmap_single(ctlr->dev, buff_dma, origlen, chan->dir);
+ }
+
cpdma_desc_free(pool, desc, 1);
(*chan->handler)((void *)token, outlen, status);
}
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h b/drivers/net/ethernet/ti/davinci_cpdma.h
index 9343c8c73c1b..0271a20c2e09 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -77,8 +77,12 @@ int cpdma_chan_stop(struct cpdma_chan *chan);
int cpdma_chan_get_stats(struct cpdma_chan *chan,
struct cpdma_chan_stats *stats);
+int cpdma_chan_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed);
int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
int len, int directed);
+int cpdma_chan_idle_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed);
int cpdma_chan_idle_submit(struct cpdma_chan *chan, void *token, void *data,
int len, int directed);
int cpdma_chan_process(struct cpdma_chan *chan, int quota);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 00/12] mlx5 TLS TX HW offload support
From: David Miller @ 2019-07-05 23:29 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, saeedm, jakub.kicinski, moshe
In-Reply-To: <1562340622-4423-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Fri, 5 Jul 2019 18:30:10 +0300
> This series from Eran and me, adds TLS TX HW offload support to
> the mlx5 driver.
Series applied, please deal with any further feedback you get from
Jakub et al.
Thanks.
^ permalink raw reply
* Re: [PATCH 06/15 net-next,v2] net: sched: add tcf_setup_block_offload()
From: Jakub Kicinski @ 2019-07-05 23:27 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-7-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:34 +0200, Pablo Neira Ayuso wrote:
> Most drivers do the same thing to set up the block, add a helper
> function to do this.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 534a545ea51e..003f24a1323f 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -922,6 +922,26 @@ static int tcf_block_setup(struct tcf_block *block, struct tc_block_offload *bo)
> return err;
> }
>
> +int tcf_setup_block_offload(struct tc_block_offload *f, tc_setup_cb_t *cb,
> + void *cb_ident, void *cb_priv, bool ingress_only)
> +{
> + if (ingress_only &&
> + f->binder_type != TCF_BLOCK_BINDER_TYPE_CLSACT_INGRESS)
> + return -EOPNOTSUPP;
> +
> + switch (f->command) {
> + case TC_BLOCK_BIND:
> + return tcf_block_cb_register(f->block, cb, cb_ident, cb_priv,
> + f->extack);
> + case TC_BLOCK_UNBIND:
> + tcf_block_cb_unregister(f->block, cb, cb_ident);
> + return 0;
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +EXPORT_SYMBOL(tcf_setup_block_offload);
> +
> static struct rhashtable indr_setup_block_ht;
>
> struct tc_indr_block_dev {
This change is pretty much unrelated to the rest of the series, isn't
it? Can you please post it separately and make the series smaller
this way?
Perhaps tcf_setup_block_offload_simple() would be a good name for this
helper?
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Larry Finger @ 2019-07-05 23:26 UTC (permalink / raw)
To: Daniel Drake, Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAD8Lp44HLPgOU+Z+w4Pq6ukLjZv2hM0=uBL7pWzQp+RsdRgG6Q@mail.gmail.com>
On 7/4/19 10:44 PM, Daniel Drake wrote:
> On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>> My point is this seems to be very dongle dependent :( We have to be
>> careful not breaking it for some users while fixing it for others.
>
> Do you still have your device?
>
> Once we get to the point when you are happy with Chris's two patches
> here on a code review level, we'll reach out to other driver
> contributors plus people who previously complained about these types
> of problems, and see if we can get some wider testing.
>
> Larry, do you have these devices, can you help with testing too?
I have some of the devices, and I can help with the testing.
Larry
^ permalink raw reply
* Re: [PATCH 12/15 net-next,v2] net: flow_offload: make flow block callback list per-driver
From: Jakub Kicinski @ 2019-07-05 23:25 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-13-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:40 +0200, Pablo Neira Ayuso wrote:
> Remove the global flow_block_cb_list, replace it by per-driver list
> of flow block objects. This will make it easier later on to support
> for policy hardware offload of multiple subsystems.
>
> Suggested-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
I don't understand the need for a per driver list of callbacks.
Your concern seems to be that drivers will get confused by multiple
subsystems trying to bind blocks. We have a feature flag for TC
offloads, why can't netfilter have one too? Way simpler.
If I may comment on the patches in general this series is really hard
to follow. Changes are split into patches in a strange way, and the
number of things called some combination of block cb and list makes my
head hurt :/
^ permalink raw reply
* Re: [pull request][net-next V2 0/2] Mellanox, mlx5 updates 2019-07-04
From: David Miller @ 2019-07-05 23:24 UTC (permalink / raw)
To: saeedm; +Cc: netdev, tariqt
In-Reply-To: <20190704205050.3354-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 4 Jul 2019 20:51:22 +0000
> This series adds the support for devlink fw query in mlx5
>
> Please pull and let me know if there is any problem.
>
> Please note that the series starts with a merge of mlx5-next branch,
> to resolve and avoid dependency with rdma tree.
> This what was actually missing from my previous submission of the 2
> devlink patches.
>
> v1->v2:
> - Removed the TLS patches from the pull request and will post them as a
> standalone series for Jakub to review.
Pulled.
^ permalink raw reply
* Re: [PATCH net] ipv4: Fix NULL pointer dereference in ipv4_neigh_lookup()
From: David Miller @ 2019-07-05 23:19 UTC (permalink / raw)
To: idosch; +Cc: netdev, dsahern, jiri, shalomt, mlxsw, idosch
In-Reply-To: <20190704162638.17913-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 4 Jul 2019 19:26:38 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Both ip_neigh_gw4() and ip_neigh_gw6() can return either a valid pointer
> or an error pointer, but the code currently checks that the pointer is
> not NULL.
>
> Fix this by checking that the pointer is not an error pointer, as this
> can result in a NULL pointer dereference [1]. Specifically, I believe
> that what happened is that ip_neigh_gw4() returned '-EINVAL'
> (0xffffffffffffffea) to which the offset of 'refcnt' (0x70) was added,
> which resulted in the address 0x000000000000005a.
>
> [1]
...
> Fixes: 5c9f7c1dfc2e ("ipv4: Add helpers for neigh lookup for nexthop")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Shalom Toledo <shalomt@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 6/7] nfp: Use spinlock_t instead of struct spinlock
From: David Miller @ 2019-07-05 23:18 UTC (permalink / raw)
To: bigeasy; +Cc: linux-kernel, tglx, peterz, jakub.kicinski, oss-drivers, netdev
In-Reply-To: <20190704153803.12739-7-bigeasy@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Thu, 4 Jul 2019 17:38:02 +0200
> For spinlocks the type spinlock_t should be used instead of "struct
> spinlock".
>
> Use spinlock_t for spinlock's definition.
>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: oss-drivers@netronome.com
> Cc: netdev@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 04/15 net-next,v2] net: sched: add tcf_block_setup()
From: Jakub Kicinski @ 2019-07-05 22:58 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-5-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:32 +0200, Pablo Neira Ayuso wrote:
> @@ -1052,12 +1145,19 @@ static int tcf_block_offload_cmd(struct tcf_block *block,
> struct netlink_ext_ack *extack)
> {
> struct tc_block_offload bo = {};
> + int err;
>
> bo.command = command;
> bo.binder_type = ei->binder_type;
> bo.block = block;
> bo.extack = extack;
> - return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
> + INIT_LIST_HEAD(&bo.cb_list);
> +
> + err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
> + if (err < 0)
> + return err;
> +
> + return tcf_block_setup(block, &bo);
If this fails nothing will undo the old ndo call, no?
> }
>
> static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
^ permalink raw reply
* Re: [net-next, PATCH, v2] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-05 22:45 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel, arnd
In-Reply-To: <1562251569-16506-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 4 Jul 2019 17:46:09 +0300
> Quoting Arnd,
>
> We have to do a sync_single_for_device /somewhere/ before the
> buffer is given to the device. On a non-cache-coherent machine with
> a write-back cache, there may be dirty cache lines that get written back
> after the device DMA's data into it (e.g. from a previous memset
> from before the buffer got freed), so you absolutely need to flush any
> dirty cache lines on it first.
>
> Since the coherency is configurable in this device make sure we cover
> all configurations by explicitly syncing the allocated buffer for the
> device before refilling it's descriptors
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
>
> Changes since V1:
> - Make the code more readable
Ooops, I applied v1. Could you please send me any changes still necessary
relative to that?
Thanks.
^ permalink raw reply
* Re: [PATCH 12/15 net-next,v2] net: flow_offload: make flow block callback list per-driver
From: Jakub Kicinski @ 2019-07-05 22:42 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-13-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:40 +0200, Pablo Neira Ayuso wrote:
> diff --git a/drivers/net/ethernet/netronome/nfp/abm/cls.c b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> index 96b89a7c468b..a42f92318b7a 100644
> --- a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> +++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> @@ -262,9 +262,12 @@ static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
> }
> }
>
> +static LIST_HEAD(nfp_abm_vf_block_cb_list);
s/_vf//
> int nfp_abm_setup_cls_block(struct net_device *netdev, struct nfp_repr *repr,
> struct flow_block_offload *f)
> {
> - return flow_block_setup_offload(f, nfp_abm_setup_tc_block_cb,
> + return flow_block_setup_offload(f, &nfp_abm_block_cb_list,
> + nfp_abm_setup_tc_block_cb,
> repr, repr, true);
> }
> diff --git a/drivers/net/ethernet/netronome/nfp/bpf/main.c b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> index 3897cc4f7a7e..5316d85261c0 100644
> --- a/drivers/net/ethernet/netronome/nfp/bpf/main.c
> +++ b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> @@ -160,6 +160,8 @@ static int nfp_bpf_setup_tc_block_cb(enum tc_setup_type type,
> return 0;
> }
>
> +static LIST_HEAD(nfp_bfp_block_cb_list);
s/bfp/bpf/
> static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
> enum tc_setup_type type, void *type_data)
> {
> @@ -168,6 +170,7 @@ static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
> switch (type) {
> case TC_SETUP_BLOCK:
> return flow_block_setup_offload(type_data,
> + &nfp_bfp_block_cb_list,
> nfp_bpf_setup_tc_block_cb,
> nn, nn, true);
> default:
^ permalink raw reply
* Re: [PATCH] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-05 22:42 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel, arnd
In-Reply-To: <1562249469-14807-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 4 Jul 2019 17:11:09 +0300
> Quoting Arnd,
>
> We have to do a sync_single_for_device /somewhere/ before the
> buffer is given to the device. On a non-cache-coherent machine with
> a write-back cache, there may be dirty cache lines that get written back
> after the device DMA's data into it (e.g. from a previous memset
> from before the buffer got freed), so you absolutely need to flush any
> dirty cache lines on it first.
>
> Since the coherency is configurable in this device make sure we cover
> all configurations by explicitly syncing the allocated buffer for the
> device before refilling it's descriptors
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Please make it explicit in your Subject lines which tree a patch is
for, in this case it should have been "[PATCH net-next] ".
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: hns3: some cleanups & bugfixes
From: David Miller @ 2019-07-05 22:39 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1562249068-40176-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Thu, 4 Jul 2019 22:04:19 +0800
> This patch-set includes cleanups and bugfixes for
> the HNS3 ethernet controller driver.
>
> [patch 1/9] fixes VF's broadcast promisc mode not enabled after
> initializing.
>
> [patch 2/9] adds hints for fibre port not support flow control.
>
> [patch 3/9] fixes a port capbility updating issue.
>
> [patch 4/9 - 9/9] adds some cleanups for HNS3 driver.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] r8152: set RTL8152_UNPLUG only for real disconnection
From: David Miller @ 2019-07-05 22:38 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-288-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Thu, 4 Jul 2019 17:36:32 +0800
> Set the flag of RTL8152_UNPLUG if and only if the device is unplugged.
> Some error codes sometimes don't mean the real disconnection of usb device.
> For those situations, set the flag of RTL8152_UNPLUG causes the driver skips
> some flows of disabling the device, and it let the device stay at incorrect
> state.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH 04/15 net-next,v2] net: sched: add tcf_block_setup()
From: Jakub Kicinski @ 2019-07-05 22:31 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-5-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:32 +0200, Pablo Neira Ayuso wrote:
> +static int tcf_block_bind(struct tcf_block *block, struct tc_block_offload *bo)
> +{
> + struct tcf_block_cb *block_cb, *next;
> + int err, i = 0;
> +
> + list_for_each_entry(block_cb, &bo->cb_list, global_list) {
> + err = tcf_block_playback_offloads(block, block_cb->cb,
> + block_cb->cb_priv, true,
> + tcf_block_offload_in_use(block),
> + bo->extack);
> + if (err)
> + goto err_unroll;
> +
> + list_add(&block_cb->list, &block->cb_list);
> + i++;
> + }
> + list_splice(&bo->cb_list, &tcf_block_cb_list);
> +
> + return 0;
> +
> +err_unroll:
> + list_for_each_entry_safe(block_cb, next, &bo->cb_list, global_list) {
> + if (i-- > 0) {
> + list_del(&block_cb->list);
> + tcf_block_playback_offloads(block, block_cb->cb,
> + block_cb->cb_priv, false,
> + tcf_block_offload_in_use(block),
> + NULL);
> + }
> + kfree(block_cb);
Is this not a tcf_block_cb_free() on purpose?
> + }
> +
> + return err;
> +}
^ permalink raw reply
* Re: [PATCH][net-next] net: remove unused parameter from skb_checksum_try_convert
From: David Miller @ 2019-07-05 22:30 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1562231006-16341-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Thu, 4 Jul 2019 17:03:26 +0800
> the check parameter is never used
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/8] mlxsw: Enable/disable PTP shapers
From: David Miller @ 2019-07-05 22:29 UTC (permalink / raw)
To: idosch; +Cc: netdev, richardcochran, jiri, petrm, shalomt, mlxsw, idosch
In-Reply-To: <20190704070740.302-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 4 Jul 2019 10:07:32 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Shalom says:
>
> In order to get more accurate hardware time stamping in Spectrum-1, the
> driver needs to apply a shaper on the port for speeds lower than 40Gbps.
> This shaper is called a PTP shaper and it is applied on hierarchy 0,
> which is the port hierarchy. This shaper may affect the shaper rates of
> all hierarchies.
>
> This patchset adds the ability to enable or disable the PTP shaper on
> the port in two scenarios:
> 1. When the user wants to enable/disable the hardware time stamping
> 2. When the port is brought up or down (including port speed change)
>
> Patch #1 adds the QEEC.ptps field that is used for enabling or disabling
> the PTP shaper on a port.
>
> Patch #2 adds a note about disabling the PTP shaper when calling to
> mlxsw_sp_port_ets_maxrate_set().
>
> Patch #3 adds the QPSC register that is responsible for configuring the
> PTP shaper parameters per speed.
>
> Patch #4 sets the PTP shaper parameters during the ptp_init().
>
> Patch #5 adds new operation for getting the port's speed.
>
> Patch #6 enables/disables the PTP shaper when turning on or off the
> hardware time stamping.
>
> Patch #7 enables/disables the PTP shaper when the port's status has
> changed (including port speed change).
>
> Patch #8 applies the PTP shaper enable/disable logic by filling the PTP
> shaper parameters array.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: socionext: remove set but not used variable 'pkts'
From: David Miller @ 2019-07-05 22:28 UTC (permalink / raw)
To: yuehaibing
Cc: jaswinder.singh, ast, ilias.apalodimas, daniel, jakub.kicinski,
hawk, netdev, xdp-newbies, bpf, kernel-janitors
In-Reply-To: <20190704033745.1758-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 4 Jul 2019 03:37:45 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/socionext/netsec.c: In function 'netsec_clean_tx_dring':
> drivers/net/ethernet/socionext/netsec.c:637:15: warning:
> variable 'pkts' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit ba2b232108d3 ("net: netsec: add XDP support")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net: ethernet: allwinner: Remove unneeded memset
From: David Miller @ 2019-07-05 22:26 UTC (permalink / raw)
To: hariprasad.kelam
Cc: maxime.ripard, wens, ynezz, f.fainelli, andrew, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190704025906.GA20005@hari-Inspiron-1545>
From: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Date: Thu, 4 Jul 2019 08:29:06 +0530
> Remove unneeded memset as alloc_etherdev is using kvzalloc which uses
> __GFP_ZERO flag
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Applied.
^ 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