* Re: [PATCH] bnxt_en: Uninitialized variable in bnxt_tc_parse_actions()
From: David Miller @ 2017-12-06 19:00 UTC (permalink / raw)
To: dan.carpenter; +Cc: michael.chan, sathya.perla, netdev, kernel-janitors
In-Reply-To: <20171205143752.cymsw7fzlqn6ejeq@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 5 Dec 2017 17:37:52 +0300
> Smatch warns that:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_tc.c:160 bnxt_tc_parse_actions()
> error: uninitialized symbol 'rc'.
>
> "rc" is either uninitialized or set to zero here so we can just remove
> the check.
>
> Fixes: 8c95f773b4a3 ("bnxt_en: add support for Flower based vxlan encap/decap offload")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Michael, please review.
Thanks.
^ permalink raw reply
* pull-request: bpf 2017-12-06
From: Daniel Borkmann @ 2017-12-06 18:56 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) Fixing broken uapi for BPF tracing programs for s390 and arm64
architectures due to pt_regs being in-kernel only, and not part
of uapi right now. A wrapper is added that exports pt_regs in
an asm-generic way. For arm64 this maps to existing user_pt_regs
structure and for s390 a user_pt_regs structure exporting the
beginning of pt_regs is added and uapi-exported, thus fixing the
BPF issues seen in perf (and BPF selftests), all from Hendrik.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 2391f0b4808e3d5af348324d69f5f45c56a26836:
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost (2017-12-04 11:32:02 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 037776e4c667a658616a9ea63d792874328c5fba:
Merge branch 'bpf-fix-broken-uapi-for-pt-regs' (2017-12-05 15:02:42 +0100)
----------------------------------------------------------------
Daniel Borkmann (1):
Merge branch 'bpf-fix-broken-uapi-for-pt-regs'
Hendrik Brueckner (6):
bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type
s390/bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type
arm64/bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type
s390/uapi: correct whitespace & coding style in asm/ptrace.h
selftests/bpf: sync kernel headers and introduce arch support in Makefile
perf s390: add regs_query_register_offset()
arch/alpha/include/uapi/asm/Kbuild | 2 +
arch/arc/include/uapi/asm/Kbuild | 1 +
arch/arm/include/uapi/asm/Kbuild | 1 +
arch/arm64/include/asm/perf_event.h | 2 +
arch/arm64/include/uapi/asm/bpf_perf_event.h | 9 +
arch/blackfin/include/uapi/asm/Kbuild | 1 +
arch/c6x/include/uapi/asm/Kbuild | 1 +
arch/cris/include/uapi/asm/Kbuild | 1 +
arch/frv/include/uapi/asm/Kbuild | 2 +
arch/h8300/include/uapi/asm/Kbuild | 1 +
arch/hexagon/include/uapi/asm/Kbuild | 1 +
arch/ia64/include/uapi/asm/Kbuild | 1 +
arch/m32r/include/uapi/asm/Kbuild | 1 +
arch/m68k/include/uapi/asm/Kbuild | 1 +
arch/metag/include/uapi/asm/Kbuild | 1 +
arch/microblaze/include/uapi/asm/Kbuild | 1 +
arch/mips/include/uapi/asm/Kbuild | 1 +
arch/mn10300/include/uapi/asm/Kbuild | 1 +
arch/nios2/include/uapi/asm/Kbuild | 1 +
arch/openrisc/include/uapi/asm/Kbuild | 1 +
arch/parisc/include/uapi/asm/Kbuild | 1 +
arch/powerpc/include/uapi/asm/Kbuild | 1 +
arch/riscv/include/uapi/asm/Kbuild | 1 +
arch/s390/include/asm/perf_event.h | 1 +
arch/s390/include/asm/ptrace.h | 11 +-
arch/s390/include/uapi/asm/bpf_perf_event.h | 9 +
arch/s390/include/uapi/asm/ptrace.h | 125 +++---
arch/score/include/uapi/asm/Kbuild | 1 +
arch/sh/include/uapi/asm/Kbuild | 1 +
arch/sparc/include/uapi/asm/Kbuild | 1 +
arch/tile/include/uapi/asm/Kbuild | 1 +
arch/unicore32/include/uapi/asm/Kbuild | 1 +
arch/x86/include/uapi/asm/Kbuild | 1 +
arch/xtensa/include/uapi/asm/Kbuild | 1 +
include/linux/perf_event.h | 6 +-
include/uapi/asm-generic/bpf_perf_event.h | 9 +
include/uapi/linux/bpf_perf_event.h | 5 +-
kernel/events/core.c | 2 +-
tools/arch/arm64/include/uapi/asm/bpf_perf_event.h | 9 +
tools/arch/s390/include/uapi/asm/bpf_perf_event.h | 9 +
tools/arch/s390/include/uapi/asm/ptrace.h | 457 +++++++++++++++++++++
tools/include/uapi/asm-generic/bpf_perf_event.h | 9 +
tools/include/uapi/linux/bpf_perf_event.h | 6 +-
tools/perf/arch/s390/Makefile | 1 +
tools/perf/arch/s390/util/dwarf-regs.c | 32 +-
tools/perf/check-headers.sh | 1 +
tools/testing/selftests/bpf/Makefile | 14 +-
47 files changed, 668 insertions(+), 79 deletions(-)
create mode 100644 arch/arm64/include/uapi/asm/bpf_perf_event.h
create mode 100644 arch/s390/include/uapi/asm/bpf_perf_event.h
create mode 100644 include/uapi/asm-generic/bpf_perf_event.h
create mode 100644 tools/arch/arm64/include/uapi/asm/bpf_perf_event.h
create mode 100644 tools/arch/s390/include/uapi/asm/bpf_perf_event.h
create mode 100644 tools/arch/s390/include/uapi/asm/ptrace.h
create mode 100644 tools/include/uapi/asm-generic/bpf_perf_event.h
^ permalink raw reply
* Re: [PATCH v2 net-next 7/8] net: dsa: microchip: Prepare PHY for proper advertisement
From: Andrew Lunn @ 2017-12-06 18:56 UTC (permalink / raw)
To: Tristram.Ha
Cc: Florian Fainelli, Pavel Machek, Ruediger Schmitt,
Arkadi Sharshevsky, UNGLinuxDriver, netdev
In-Reply-To: <1512524798-16210-8-git-send-email-Tristram.Ha@microchip.com>
Hi Tristram
> +static void ksz9477_phy_setup(struct ksz_device *dev, int port,
> + struct phy_device *phy)
> +{
> + if (port < dev->phy_port_cnt) {
> + /* SUPPORTED_Asym_Pause and SUPPORTED_Pause can be removed to
> + * disable flow control when rate limiting is used.
> + */
> + phy->advertising = phy->supported;
> + }
This looks a bit odd. phy_probe() does the same:
/* Start out supporting everything. Eventually,
* a controller will attach, and may modify one
* or both of these values
*/
phydev->supported = phydrv->features;
of_set_phy_supported(phydev);
phydev->advertising = phydev->supported;
You don't modify anything here, so i don't see why it is needed.
> +void ksz_adjust_link(struct dsa_switch *ds, int port,
> + struct phy_device *phydev)
> +{
> + struct ksz_device *dev = ds->priv;
> + struct ksz_port *p = &dev->ports[port];
> +
> + if (phydev->link) {
> + p->speed = phydev->speed;
> + p->duplex = phydev->duplex;
> + p->flow_ctrl = phydev->pause;
> + p->link_up = 1;
> + dev->live_ports |= (1 << port) & dev->on_ports;
> + } else if (p->link_up) {
> + p->link_up = 0;
> + p->link_down = 1;
> + dev->live_ports &= ~(1 << port);
> + }
The link_down looks odd. If you are setting link_up to 1, should
link_down also be set to 0? Can it be both up and down at the same
time?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] bnxt: Don't print message, if DAC isn't connected on both ends
From: David Miller @ 2017-12-06 18:49 UTC (permalink / raw)
To: tbogendoerfer; +Cc: michael.chan, netdev, linux-kernel
In-Reply-To: <20171205123340.3307-1-tbogendoerfer@suse.de>
From: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Date: Tue, 5 Dec 2017 13:33:40 +0100
> bnxt driver spams logfiles with
>
> [ 541.003065] bnxt_en 0000:5d:00.1 eth5: Link speed -1 no longer supported
>
> if a direct attached cable (DAC) is plugged into the bnxt card and is
> unplugged on the other side. This patch removes the code printing this
> message, since it doesn't provide any useful information.
>
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Michael, I really need you to review this.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 net-next 3/8] net: dsa: microchip: Initialize mutex before use
From: Andrew Lunn @ 2017-12-06 18:44 UTC (permalink / raw)
To: Tristram.Ha
Cc: Florian Fainelli, Pavel Machek, Ruediger Schmitt,
Arkadi Sharshevsky, UNGLinuxDriver, netdev
In-Reply-To: <1512524798-16210-4-git-send-email-Tristram.Ha@microchip.com>
On Tue, Dec 05, 2017 at 05:46:33PM -0800, Tristram.Ha@microchip.com wrote:
> From: Tristram Ha <Tristram.Ha@microchip.com>
>
> Initialize mutex before use.
>
> Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] bpf/tracing: allow user space to query prog array on the same tp
From: Yonghong Song @ 2017-12-06 18:37 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: rostedt, ast, daniel, kafai, netdev, kernel-team
In-Reply-To: <20171206131650.djwcm5sjp4j4u7qg@hirez.programming.kicks-ass.net>
On 12/6/17 5:16 AM, Peter Zijlstra wrote:
> On Wed, Dec 06, 2017 at 12:56:36PM +0100, Peter Zijlstra wrote:
>> On Tue, Dec 05, 2017 at 10:31:28PM -0800, Yonghong Song wrote:
>>> Commit e87c6bc3852b ("bpf: permit multiple bpf attachments
>>> for a single perf event") added support to attach multiple
>>> bpf programs to a single perf event.
>>> Commit 2541517c32be ("tracing, perf: Implement BPF programs
>>> attached to kprobes") utilized the existing perf ioctl
>>> interface and added the command PERF_EVENT_IOC_SET_BPF
>>> to attach a bpf program to a tracepoint.
>>>
>>> This patch adds a new ioctl
>>> command, given a perf event fd, to query the bpf program array
>>> attached to the same perf tracepoint event.
>>>
>>> The new uapi ioctl command:
>>> PERF_EVENT_IOC_QUERY_BPF
>>>
>>> The new uapi/linux/perf_event.h structure:
>>> struct perf_event_query_bpf {
>>> __u64 prog_ids;
>>> __u32 prog_cnt;
>>> };
>>>
>>> The usage:
>>> struct perf_event_query_bpf query;
>>> query.prog_ids = (__u64)usr_prog_ids_buf;
>>> query.prog_cnt = usr_prog_ids_buf_len;
>>> err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, &query);
>>>
>>> Signed-off-by: Yonghong Song <yhs@fb.com>
>>> Acked-by: Alexei Starovoitov <ast@kernel.org>
>>
>> Can you please fix that example to make it clear that prog_ids is in
>> fact a pointer to an array of size prog_cnt. Ideally also describing
>> what the type of array is.
Right. Will address this with more descriptions in the commit message
and also add some comments in the perf_event.h.
>>
>> In fact, would not something like:
>>
>> struct perf_event_query_bpf {
>> __u32 len;
>> __u32 __reserved;
>
> I suppose we could use this field to store the number of entries
> returned, retaining the len to indicate how large the structure is.
>
>> __u64 ids[0];
>> };
>>
>> be a much clearer interface?
Yes, this is clearer and may be consistent with perf interface.
FYI, my old interface is similar to the BPF query interface below:
struct { /* anonymous struct used by BPF_PROG_QUERY command */
__u32 target_fd; /* container object to
query */
__u32 attach_type;
__u32 query_flags;
__u32 attach_flags;
__aligned_u64 prog_ids;
__u32 prog_cnt;
} query;
>>
>> Also, you forgot to tell us why we need this interface at all.
Right. Will add some descriptions for this.
^ permalink raw reply
* [PATCH net] adding missing rcu_read_unlock in ipxip6_rcv
From: Nikita V. Shirokov @ 2017-12-06 18:19 UTC (permalink / raw)
To: netdev; +Cc: ast, vnuorval, Nikita V. Shirokov
commit 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
introduced new exit point in ipxip6_rcv. however rcu_read_unlock is
missing there. this diff is fixing this
Signed-off-by: Nikita V. Shirokov <tehnerd@fb.com>
---
net/ipv6/ip6_tunnel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 3d3092a..00f2c79 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -903,8 +903,10 @@ static int ipxip6_rcv(struct sk_buff *skb, u8 ipproto,
goto drop;
if (t->parms.collect_md) {
tun_dst = ipv6_tun_rx_dst(skb, 0, 0, 0);
- if (!tun_dst)
+ if (!tun_dst) {
+ rcu_read_unlock();
return 0;
+ }
}
ret = __ip6_tnl_rcv(t, skb, tpi, tun_dst, dscp_ecn_decapsulate,
log_ecn_error);
--
2.9.5
^ permalink raw reply related
* Re: Waiting for the PHY to complete auto-negotiation
From: Andrew Lunn @ 2017-12-06 18:26 UTC (permalink / raw)
To: Mason; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <c1c242b2-2ef8-802d-c048-59efb36f839c@free.fr>
> The problem with this is the following mind-boggling quirk of
> the hardware: once RX DMA is enabled, there is no supported
> way to disable it! Thus, I'm trying to find a clean way to set
> the control flow parameter BEFORE enabling the MAC.
There is no solution. I can pull the cable out, and plug it into a
different computer. The first could use flow control, the second not.
If you cannot disable RX DMA, you should probably disable unloading of
the module. Also kexec.
Andrew
^ permalink raw reply
* Re: [RFC v2 6/6] flow_dissector: Parse batman-adv unicast headers
From: Willem de Bruijn @ 2017-12-06 18:24 UTC (permalink / raw)
To: Sven Eckelmann
Cc: Eric Dumazet, Tom Herbert,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, LKML, Jiri Pirko,
Linux Kernel Network Developers, David S . Miller
In-Reply-To: <7082766.sOGqpe4oL6@bentobox>
> On Mittwoch, 6. Dezember 2017 11:54:13 CET Willem de Bruijn wrote:
>> Perhaps it can even be behind a static key depending on whether any
>> devices are active, adjusted in batadv_hardif_(en|dis)able_interface.
>
> I don't like that because we don't need batman-adv loaded to simply forward
> (bridge) traffic between interfaces. And not being able to use RPS with
> multiple cores just because the batman-adv module (and interfaces) is not
> enabled seems to be counter-intuitive.
Okay. Ack on Tom's points, too.
I want to be able to administratively limit the footprint of flow dissector,
but agreed that this can be configured independent from the rest of the
datapath, i.e., with knobs specific to flow dissector.
>> Please implement FLOW_DISSECTOR_F_STOP_AT_ENCAP. It may
>> be used in more flow dissector paths in the future.
>>
>> The features are also used by GRE, which can encap Ethernet, for an example
>> that is closer to this protocol.
>
> Thanks for the feedback. I have it now implemented like in GRE.
>
> The change can already be found in
> https://git.open-mesh.org/linux-merge.git/shortlog/refs/heads/ecsv/flowdissector
Great, thanks.
^ permalink raw reply
* Re: Waiting for the PHY to complete auto-negotiation
From: Mason @ 2017-12-06 18:03 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <20171206165903.GM27063@lunn.ch>
On 06/12/2017 17:59, Andrew Lunn wrote:
> On Wed, Dec 06, 2017 at 05:39:00PM +0100, Mason wrote:
>
>> I've been trying to wrap my head around Ethernet auto-negotiation,
>> vs actual / real packets seen at the MAC layer. I found the relevant
>> Wikipedia article to be fairly informative:
>>
>> https://en.wikipedia.org/wiki/Autonegotiation
>>
>> The reason I care is that my Ethernet HW does not allow changing the
>> flow control setting once the MAC has started (more specifically, once
>> RX DMA has been enabled).
>>
>> In nb8800_open(), the code currently works in this order:
>>
>> nb8800_start_rx(dev);
>> phy_start(phydev);
>>
>> The first line enables the MAC (and DMA).
>> The second enables the PHY and starts auto-negotiation.
>>
>> This is a problem: I would like for PHY auto-negotiation to be
>> /complete/ before I enable the MAC.
>>
>> What is the recommended way to wait for the PHY?
>
>> AFAICT, the PHY layer calls back into the eth driver through the
>> adjust_link() callback registered through of_phy_connect().
>> It seems like this might be a good place to enable the MAC?
>
> That probably works, but you might have a few corner cases to handle.
> I'm not sure changes at the PHY always transition through down. So you
> could for example get a callback saying the link is up, 1Gbps, then a
> second call saying it has dropped to 100Mbps, if your
> cables/connectors are bad.
>
> If your hardware has problems, it might be safest to stop everything
> in the callback, make configuration changes, and they start everything
> back up. A link negotiation change is not something you expect to
> happen often. So making it slow but robust is O.K.
What you've described is, in fact, the existing implementation! ;-)
nb8800_pause_config() checks for netif_running() and, when true,
tries to disable everything, make the change, then re-enable
everything.
The problem with this is the following mind-boggling quirk of
the hardware: once RX DMA is enabled, there is no supported
way to disable it! Thus, I'm trying to find a clean way to set
the control flow parameter BEFORE enabling the MAC.
Regards.
^ permalink raw reply
* Re: [PATCH iproute2] tc: police: fix control action parsing
From: Stephen Hemminger @ 2017-12-06 17:55 UTC (permalink / raw)
To: Michal Privoznik; +Cc: Jiri Pirko, netdev, jiri
In-Reply-To: <16bd923d-f725-e455-f8c3-43708b233564@redhat.com>
On Wed, 29 Nov 2017 10:06:26 +0100
Michal Privoznik <mprivozn@redhat.com> wrote:
> On 11/28/2017 02:02 PM, Jiri Pirko wrote:
> > Mon, Nov 27, 2017 at 09:32:59PM CET, stephen@networkplumber.org wrote:
> >> On Mon, 27 Nov 2017 19:00:14 +0100
> >> Michal Privoznik <mprivozn@redhat.com> wrote:
> >>
> >>> parse_action_control helper does advancing of the arg inside. So don't
> >>> do it outside.
> >>>
> >>> Fixes: e67aba559581 ("tc: actions: add helpers to parse and print control actions")
> >>> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> >>
> >> The helpers are not helping here.
> >> Adding another layer of indirection on moving argc/argv then causing caller
> >> to have to keep track is bad design.
> >>
> >> Also since pars_action_control_slash is only used by police, why was it
> >> moved into tc_util in the first place? I would prefer just to rip out that
> >> bit and put it back in policer.
> >
> > I tried to make all the x-specific parsing to go away and make all done
> > in core. That should have been done from the very beginning, we would
> > lot of mess.
> >
>
> Okay, would it be a better solution if __parse_action_control() wouldn't
> call NEXT_ARG_FWD() at the end? Then this patch wouldn't be needed and
> every place that calls parse_action_control() would not need to special
> case it.
>
> Just a bit of background:
> Libvirt has a capability of setting QoS on bridges/TAPs it manages. And
> as part of that it issues the following command to set traffic limiting:
>
> tc filter add dev virbr0 parent ffff: protocol all u32 match u32 0 0 \
> police rate 50kbps burst 50kb mtu 64kb drop flowid :1
>
> More info can be found in this bug:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1514963
>
> Fortunately, no a lot of distros ship 4.13+ so libvirt ain't broken yet.
> But soon.
>
> Michal
Michal, if you and Jiri can work out cleaner parse action semantic that would
be best. If not, then this patch would do. Let me know next week what you figure out.
^ permalink raw reply
* [PATCH 28/45] samples: bpf: remove duplicate includes
From: Pravin Shedge @ 2017-12-06 17:34 UTC (permalink / raw)
To: netdev, ast, daniel; +Cc: linux-kernel, pravin.shedge4linux
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
---
samples/bpf/bpf_load.c | 1 -
samples/bpf/sampleip_user.c | 1 -
samples/bpf/test_current_task_under_cgroup_user.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 522ca92..2a1ae26 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -1,6 +1,5 @@
// SPDX-License-Identifier: GPL-2.0
#include <stdio.h>
-#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <libelf.h>
diff --git a/samples/bpf/sampleip_user.c b/samples/bpf/sampleip_user.c
index 4ed690b..0e1f250 100644
--- a/samples/bpf/sampleip_user.c
+++ b/samples/bpf/sampleip_user.c
@@ -9,7 +9,6 @@
*/
#include <stdio.h>
#include <stdlib.h>
-#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <signal.h>
diff --git a/samples/bpf/test_current_task_under_cgroup_user.c b/samples/bpf/test_current_task_under_cgroup_user.c
index 65b5fb5..0643b2d 100644
--- a/samples/bpf/test_current_task_under_cgroup_user.c
+++ b/samples/bpf/test_current_task_under_cgroup_user.c
@@ -11,7 +11,6 @@
#include <unistd.h>
#include "libbpf.h"
#include "bpf_load.h"
-#include <linux/bpf.h>
#include "cgroup_helpers.h"
#define CGROUP_PATH "/my-cgroup"
--
2.7.4
^ permalink raw reply related
* Re: [RFC v2 6/6] flow_dissector: Parse batman-adv unicast headers
From: Sven Eckelmann @ 2017-12-06 17:27 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Eric Dumazet, Tom Herbert,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, LKML, Jiri Pirko,
Linux Kernel Network Developers, David S . Miller
In-Reply-To: <CAF=yD-LR5WSQt5jwN-+T-1iWyrxovk0qZ1cb-QUO6_+Wy8Ci-A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
On Mittwoch, 6. Dezember 2017 11:54:13 CET Willem de Bruijn wrote:
> Perhaps it can even be behind a static key depending on whether any
> devices are active, adjusted in batadv_hardif_(en|dis)able_interface.
I don't like that because we don't need batman-adv loaded to simply forward
(bridge) traffic between interfaces. And not being able to use RPS with
multiple cores just because the batman-adv module (and interfaces) is not
enabled seems to be counter-intuitive.
> Please implement FLOW_DISSECTOR_F_STOP_AT_ENCAP. It may
> be used in more flow dissector paths in the future.
>
> The features are also used by GRE, which can encap Ethernet, for an example
> that is closer to this protocol.
Thanks for the feedback. I have it now implemented like in GRE.
The change can already be found in
https://git.open-mesh.org/linux-merge.git/shortlog/refs/heads/ecsv/flowdissector
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH 2/2] net: fec: optimize IRQ handler
From: Lucas Stach @ 2017-12-06 17:24 UTC (permalink / raw)
To: Fugang Duan, netdev; +Cc: patchwork-lst, kernel
In-Reply-To: <20171206172459.14059-1-l.stach@pengutronix.de>
fep->work_rx and fep->work_tx are both non-zero, as long as the NAPI
softirq hasn't finished its work. So if the current IRQ does not
signal any RX or TX completion, but some unrelated event, the path to
schedule the NAPI context is still entered.
The handler works correctly as in this case napi_schedule_prep() will
reject the scheduling attempt, but the flow can still be optimized by
not trying to schedule if the IRQ doesn't signal RX or TX completion.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 0b70c07eb703..2043e140e9bd 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1587,14 +1587,14 @@ fec_enet_interrupt(int irq, void *dev_id)
int_events = readl_relaxed(fep->hwp + FEC_IEVENT) &
readl_relaxed(fep->hwp + FEC_IMASK);
writel(int_events, fep->hwp + FEC_IEVENT);
- fec_enet_collect_events(fep, int_events);
- if ((fep->work_tx || fep->work_rx) && fep->link) {
+ if ((int_events & (FEC_ENET_RXF | FEC_ENET_TXF)) && fep->link) {
ret = IRQ_HANDLED;
if (napi_schedule_prep(&fep->napi)) {
/* Disable the NAPI interrupts */
writel(FEC_NAPI_IMASK, fep->hwp + FEC_IMASK);
+ fec_enet_collect_events(fep, int_events);
__napi_schedule(&fep->napi);
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] net: fec: don't ack masked interrupt events
From: Lucas Stach @ 2017-12-06 17:24 UTC (permalink / raw)
To: Fugang Duan, netdev; +Cc: patchwork-lst, kernel
The FEC doesn't have a real interrupt status register, that takes
into account the mask status of the IRQ. The driver reads the raw
interrupt event register, which also reports events for masked
IRQs.
The driver needs to apply the current mask itself, to avoid acking
IRQs that are currently masked, as NAPI relies on the masking to
hide the IRQs. The current behavior of just acking all interrupts
regardless of their mask status opens the driver up the "rotting
packet" race-window, as described in the original NAPI-HOWTO, which
has been observed in the wild.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
---
drivers/net/ethernet/freescale/fec_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 610573855213..0b70c07eb703 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1584,7 +1584,8 @@ fec_enet_interrupt(int irq, void *dev_id)
uint int_events;
irqreturn_t ret = IRQ_NONE;
- int_events = readl(fep->hwp + FEC_IEVENT);
+ int_events = readl_relaxed(fep->hwp + FEC_IEVENT) &
+ readl_relaxed(fep->hwp + FEC_IMASK);
writel(int_events, fep->hwp + FEC_IEVENT);
fec_enet_collect_events(fep, int_events);
--
2.11.0
^ permalink raw reply related
* [PATCH] net: ethernet: arc: fix error handling in emac_rockchip_probe
From: Branislav Radocaj @ 2017-12-06 17:24 UTC (permalink / raw)
To: heiko, netdev
Cc: linux-rockchip, linux-kernel, linux-arm-kernel, Branislav Radocaj
If clk_set_rate() fails, we should disable clk
before return.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Branislav Radocaj <branislav@radocaj.org>
---
drivers/net/ethernet/arc/emac_rockchip.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/arc/emac_rockchip.c b/drivers/net/ethernet/arc/emac_rockchip.c
index e278e3d96ee0..c6163874e4e7 100644
--- a/drivers/net/ethernet/arc/emac_rockchip.c
+++ b/drivers/net/ethernet/arc/emac_rockchip.c
@@ -220,9 +220,11 @@ static int emac_rockchip_probe(struct platform_device *pdev)
/* RMII TX/RX needs always a rate of 25MHz */
err = clk_set_rate(priv->macclk, 25000000);
- if (err)
+ if (err) {
dev_err(dev,
"failed to change mac clock rate (%d)\n", err);
+ goto out_clk_disable_macclk;
+ }
}
err = arc_emac_probe(ndev, interface);
@@ -232,7 +234,8 @@ static int emac_rockchip_probe(struct platform_device *pdev)
}
return 0;
-
+out_clk_disable_macclk:
+ clk_disable_unprepare(priv->macclk);
out_regulator_disable:
if (priv->regulator)
regulator_disable(priv->regulator);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3] net: sched: crash on blocks with goto chain action
From: Cong Wang @ 2017-12-06 17:18 UTC (permalink / raw)
To: David Miller; +Cc: Roman Kapl, Linux Kernel Network Developers, Jiri Pirko
In-Reply-To: <20171205.112213.619683454960802411.davem@davemloft.net>
On Tue, Dec 5, 2017 at 8:22 AM, David Miller <davem@davemloft.net> wrote:
>
> This doesn't apply cleanly to 'net'.
Dave, you already applied v2:
commit a60b3f515d30d0fe8537c64671926879a3548103
Author: Roman Kapl <code@rkapl.cz>
Date: Fri Nov 24 12:27:58 2017 +0100
net: sched: crash on blocks with goto chain action
And the difference between v2 and v3 is only the Fixes tag, so
not a big deal.
^ permalink raw reply
* Re: [PATCH 13/45] drivers: net: dsa: remove duplicate includes
From: Andrew Lunn @ 2017-12-06 17:13 UTC (permalink / raw)
To: Pravin Shedge; +Cc: netdev, f.fainelli, vivien.didelot, linux-kernel
In-Reply-To: <1512579520-5474-1-git-send-email-pravin.shedge4linux@gmail.com>
On Wed, Dec 06, 2017 at 10:28:40PM +0530, Pravin Shedge wrote:
> These duplicate includes have been found with scripts/checkincludes.pl but
> they have been removed manually to avoid removing false positives.
>
> Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH 19/45] drivers: staging: remove duplicate includes
From: Pravin Shedge @ 2017-12-06 17:12 UTC (permalink / raw)
To: devel, netdev, gregkh, samuel; +Cc: linux-kernel, pravin.shedge4linux
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
---
drivers/staging/ccree/ssi_buffer_mgr.c | 1 -
drivers/staging/ccree/ssi_driver.c | 1 -
drivers/staging/irda/drivers/pxaficp_ir.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c b/drivers/staging/ccree/ssi_buffer_mgr.c
index 1f8a225..834bddd 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -23,7 +23,6 @@
#include <crypto/scatterwalk.h>
#include <linux/dmapool.h>
#include <linux/dma-mapping.h>
-#include <linux/crypto.h>
#include <linux/module.h>
#include <linux/platform_device.h>
diff --git a/drivers/staging/ccree/ssi_driver.c b/drivers/staging/ccree/ssi_driver.c
index 1a3c481..2cec0e1 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -55,7 +55,6 @@
#include <linux/uaccess.h>
#include <linux/pagemap.h>
#include <linux/sched.h>
-#include <linux/random.h>
#include <linux/of.h>
#include <linux/clk.h>
#include <linux/of_address.h>
diff --git a/drivers/staging/irda/drivers/pxaficp_ir.c b/drivers/staging/irda/drivers/pxaficp_ir.c
index 1dba16b..2ea00a6 100644
--- a/drivers/staging/irda/drivers/pxaficp_ir.c
+++ b/drivers/staging/irda/drivers/pxaficp_ir.c
@@ -12,7 +12,6 @@
* Infra-red driver (SIR/FIR) for the PXA2xx embedded microprocessor
*
*/
-#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
#include <linux/module.h>
#include <linux/netdevice.h>
--
2.7.4
^ permalink raw reply related
* Re: [RFC v2 6/6] flow_dissector: Parse batman-adv unicast headers
From: Tom Herbert @ 2017-12-06 17:10 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Sven Eckelmann, Linux Kernel Network Developers, David S . Miller,
Jiri Pirko, Eric Dumazet, LKML, b.a.t.m.a.n
In-Reply-To: <CAF=yD-LR5WSQt5jwN-+T-1iWyrxovk0qZ1cb-QUO6_+Wy8Ci-A@mail.gmail.com>
On Wed, Dec 6, 2017 at 8:54 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Wed, Dec 6, 2017 at 5:26 AM, Sven Eckelmann
> <sven.eckelmann@openmesh.com> wrote:
>> On Dienstag, 5. Dezember 2017 09:19:45 CET Tom Herbert wrote:
>> [...]
>>> Switch statements with cases having many LOC is hard to read and
>>> __skb_flow_dissect is aleady quite convoluted to begin with.
>>>
>>> I suggest putting this in a static function similar to how MPLS and
>>> GRE are handled.
>
> Perhaps it can even be behind a static key depending on whether any
> devices are active, adjusted in batadv_hardif_(en|dis)able_interface.
>
It's aready in a switch statement so static key shouldn't make a
difference. Also, we have made flow dissector operate indendently of
whether to end protocol is enable (for instance GRE is dissected
regarless of whether and GRE tunnels are configured).
Tom
>> Thanks for the feedback.
>>
>> I was not sure whether "inline" or an extra function would be preferred. I've
>> then decided to implement it like most of the other protocols. But since an
>> extra function is the preferred method for handling new protos, I will move it
>> to an extra function.
>>
>> The change can already be found in
>> https://git.open-mesh.org/linux-merge.git/shortlog/refs/heads/ecsv/flowdissector
>>
>> I also saw that you've introduced in
>> commit 823b96939578 ("flow_dissector: Add control/reporting of encapsulation")
>> a flag to stop dissecting when something encapsulated was detected. It is not
>> 100% clear to me when the FLOW_DIS_ENCAPSULATION should be set and
>> FLOW_DISSECTOR_F_STOP_AT_ENCAP be checked. Only when there is IP/eth in IP
>> (like in the two examples from the commit message) or also when there is a
>> ethernet header, followed by batman-adv unicast header and again followed by
>> an ethernet header?
>
> Please implement FLOW_DISSECTOR_F_STOP_AT_ENCAP. It may
> be used in more flow dissector paths in the future.
>
> The features are also used by GRE, which can encap Ethernet, for an example
> that is closer to this protocol.
^ permalink raw reply
* Re: Waiting for the PHY to complete auto-negotiation
From: Andrew Lunn @ 2017-12-06 16:59 UTC (permalink / raw)
To: Mason; +Cc: netdev, Florian Fainelli, David Miller
In-Reply-To: <e54cda57-6a7d-611e-89b9-0b3c9ea55cc1@free.fr>
On Wed, Dec 06, 2017 at 05:39:00PM +0100, Mason wrote:
> Hello,
>
> I've been trying to wrap my head around Ethernet auto-negotiation,
> vs actual / real packets seen at the MAC layer. I found the relevant
> Wikipedia article to be fairly informative:
>
> https://en.wikipedia.org/wiki/Autonegotiation
>
> The reason I care is that my Ethernet HW does not allow changing the
> flow control setting once the MAC has started (more specifically, once
> RX DMA has been enabled).
>
> In nb8800_open(), the code currently works in this order:
>
> nb8800_start_rx(dev);
> phy_start(phydev);
>
> The first line enables the MAC (and DMA).
> The second enables the PHY and starts auto-negotiation.
>
> This is a problem: I would like for PHY auto-negotiation to be
> /complete/ before I enable the MAC.
>
> What is the recommended way to wait for the PHY?
> AFAICT, the PHY layer calls back into the eth driver through the
> adjust_link() callback registered through of_phy_connect().
> It seems like this might be a good place to enable the MAC?
That probably works, but you might have a few corner cases to handle.
I'm not sure changes at the PHY always transition through down. So you
could for example get a callback saying the link is up, 1Gbps, then a
second call saying it has dropped to 100Mbps, if your
cables/connectors are bad.
If your hardware has problems, it might be safest to stop everything
in the callback, make configuration changes, and they start everything
back up. A link negotiation change is not something you expect to
happen often. So making it slow but robust is O.K.
Andrew
^ permalink raw reply
* [PATCH 13/45] drivers: net: dsa: remove duplicate includes
From: Pravin Shedge @ 2017-12-06 16:58 UTC (permalink / raw)
To: netdev, f.fainelli, vivien.didelot, andrew
Cc: linux-kernel, pravin.shedge4linux
These duplicate includes have been found with scripts/checkincludes.pl but
they have been removed manually to avoid removing false positives.
Signed-off-by: Pravin Shedge <pravin.shedge4linux@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ea01f24..b62d472 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -14,7 +14,6 @@
#include <linux/netdevice.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
-#include <linux/of.h>
#include <linux/phy.h>
#include <linux/phy_fixed.h>
#include <linux/mii.h>
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 6/6] net: sched: sch: add extack for graft callback
From: Jamal Hadi Salim @ 2017-12-06 16:58 UTC (permalink / raw)
To: Alexander Aring, davem; +Cc: xiyou.wangcong, jiri, netdev, kernel, David Ahern
In-Reply-To: <20171206160845.6646-7-aring@mojatatu.com>
On 17-12-06 11:08 AM, Alexander Aring wrote:
> This patch adds extack support for graft callback to prepare per-qdisc
> specific changes for extack.
>
> Cc: David Ahern<dsahern@gmail.com>
> Signed-off-by: Alexander Aring<aring@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ permalink raw reply
* Re: [RFC v2 2/6] batman-adv: Rename batman-adv.h to batadv_genl.h
From: Willem de Bruijn @ 2017-12-06 16:58 UTC (permalink / raw)
To: Sven Eckelmann
Cc: Network Development, b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
Jiri Pirko, LKML, Eric Dumazet, David S . Miller
In-Reply-To: <5212497.opIP8sI45N@bentobox>
On Wed, Dec 6, 2017 at 11:55 AM, Sven Eckelmann
<sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> wrote:
> On Mittwoch, 6. Dezember 2017 11:42:33 CET Willem de Bruijn wrote:
>> On Tue, Dec 5, 2017 at 9:35 AM, Sven Eckelmann
>> <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org> wrote:
>> > This file contains the relevant information to let userspace communicate
>> > with batman-adv over generic netlink. The relevant genl enums for the
>> > attributes and commands have the prefix batadv_genl. Renaming this file to
>> > this name therefore represents the content better and avoids confusion
> with
>> > the file which will contain the packet format definitions.
>> >
>> > Signed-off-by: Sven Eckelmann <sven.eckelmann-lv6y7wLVQPlWk0Htik3J/w@public.gmane.org>
>> > ---
>> > MAINTAINERS | 2 +-
>> > include/uapi/linux/{batman_adv.h => batadv_genl.h} | 6 +++---
>>
>> This and the previous patch changes uapi. That might break userspace
>> applications that rely on it.
>
> I am not aware of any application because all (alfred, batctl and some gluon
> integration) of them currently ship their own copy because distribution didn't
> catch up. And this is also the reason why I want to do it now - not later.
That assumes that you know all applications, including those not
publicly available. It may be true in this instance, but it is not
possible to be certain.
^ permalink raw reply
* Re: [PATCH net-next 5/6] net: sched: sch: add extack for block callback
From: Jamal Hadi Salim @ 2017-12-06 16:57 UTC (permalink / raw)
To: Alexander Aring, davem; +Cc: xiyou.wangcong, jiri, netdev, kernel, David Ahern
In-Reply-To: <20171206160845.6646-6-aring@mojatatu.com>
On 17-12-06 11:08 AM, Alexander Aring wrote:
> This patch adds extack support for block callback to prepare per-qdisc
> specific changes for extack.
>
> Cc: David Ahern<dsahern@gmail.com>
> Signed-off-by: Alexander Aring<aring@mojatatu.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
^ 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