* [PATCH net-next v2 2/3] net: ethernet: freescale: Allow FEC with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:52 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
In-Reply-To: <20180516185258.20508-1-f.fainelli@gmail.com>
The Freescale FEC driver builds fine with COMPILE_TEST, so make that
possible.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/ethernet/freescale/Kconfig | 2 +-
drivers/net/ethernet/freescale/fec.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 6e490fd2345d..a580a3dcbe59 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -22,7 +22,7 @@ if NET_VENDOR_FREESCALE
config FEC
tristate "FEC ethernet controller (of ColdFire and some i.MX CPUs)"
depends on (M523x || M527x || M5272 || M528x || M520x || M532x || \
- ARCH_MXC || SOC_IMX28)
+ ARCH_MXC || SOC_IMX28 || COMPILE_TEST)
default ARCH_MXC || SOC_IMX28 if ARM
select PHYLIB
imply PTP_1588_CLOCK
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index e7381f8ef89d..4778b663653e 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -21,7 +21,7 @@
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
- defined(CONFIG_ARM64)
+ defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
/*
* Just figures, Motorola would have to change the offsets for
* registers in the same peripheral device on different models
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index d4604bc8eb5b..91e334b5a836 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -2111,7 +2111,7 @@ static int fec_enet_get_regs_len(struct net_device *ndev)
/* List of registers that can be safety be read to dump them with ethtool */
#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || defined(CONFIG_M528x) || \
defined(CONFIG_M520x) || defined(CONFIG_M532x) || defined(CONFIG_ARM) || \
- defined(CONFIG_ARM64)
+ defined(CONFIG_ARM64) || defined(CONFIG_COMPILE_TEST)
static u32 fec_enet_register_offset[] = {
FEC_IEVENT, FEC_IMASK, FEC_R_DES_ACTIVE_0, FEC_X_DES_ACTIVE_0,
FEC_ECNTRL, FEC_MII_DATA, FEC_MII_SPEED, FEC_MIB_CTRLSTAT, FEC_R_CNTRL,
--
2.14.1
^ permalink raw reply related
* [PATCH net-next v2 3/3] net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:52 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
In-Reply-To: <20180516185258.20508-1-f.fainelli@gmail.com>
Those drivers build just fine with COMPILE_TEST, so make that possible.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/phy/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 0e2305ccc91f..343989f9f9d9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -118,7 +118,7 @@ config MDIO_I2C
config MDIO_MOXART
tristate "MOXA ART MDIO interface support"
- depends on ARCH_MOXART
+ depends on ARCH_MOXART || COMPILE_TEST
help
This driver supports the MDIO interface found in the network
interface units of the MOXA ART SoC
@@ -142,7 +142,7 @@ config MDIO_OCTEON
config MDIO_SUN4I
tristate "Allwinner sun4i MDIO interface support"
- depends on ARCH_SUNXI
+ depends on ARCH_SUNXI || COMPILE_TEST
help
This driver supports the MDIO interface found in the network
interface units of the Allwinner SoC that have an EMAC (A10,
--
2.14.1
^ permalink raw reply related
* [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 18:52 UTC (permalink / raw)
To: netdev
Cc: fugang.duan, Florian Fainelli, David S. Miller, Andrew Lunn,
open list
Hi David,
This patch series includes more drivers to be build tested with COMPILE_TEST
enabled. This helps cover some of the issues I just ran into with missing
a driver *sigh*.
Changes in v2:
- allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
registers, this is not meant to run, so this is not a real issue if we
are not matching the correct register layout
Florian Fainelli (3):
net: ethernet: ti: Allow most drivers with COMPILE_TEST
net: ethernet: freescale: Allow FEC with COMPILE_TEST
net: phy: Allow MDIO_MOXART and MDIO_SUN4I with COMPILE_TEST
drivers/net/ethernet/freescale/Kconfig | 2 +-
drivers/net/ethernet/freescale/fec.h | 2 +-
drivers/net/ethernet/freescale/fec_main.c | 2 +-
drivers/net/ethernet/ti/Kconfig | 14 +++++++-------
drivers/net/phy/Kconfig | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
--
2.14.1
^ permalink raw reply
* Re: [PATCH net] tuntap: fix use after free during release
From: David Miller @ 2018-05-16 18:53 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, xiyou.wangcong, avagin, mst
In-Reply-To: <1526474373-16685-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Wed, 16 May 2018 20:39:33 +0800
> After commit b196d88aba8a ("tun: fix use after free for ptr_ring") we
> need clean up tx ring during release(). But unfortunately, it tries to
> do the cleanup blindly after socket were destroyed which will lead
> another use-after-free. Fix this by doing the cleanup before dropping
> the last reference of the socket in __tun_detach().
>
> Reported-by: Andrei Vagin <avagin@virtuozzo.com>
> Acked-by: Andrei Vagin <avagin@virtuozzo.com>
> Fixes: b196d88aba8a ("tun: fix use after free for ptr_ring")
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [RFC PATCH bpf-next 12/12] i40e: implement Tx zero-copy
From: Jesper Dangaard Brouer @ 2018-05-16 18:53 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Björn Töpel, Karlsson, Magnus, Alexander Duyck,
Alexander Duyck, John Fastabend, Alexei Starovoitov,
Willem de Bruijn, Daniel Borkmann, Michael S. Tsirkin,
Network Development, michael.lundkvist, Brandeburg, Jesse,
Singhai, Anjali, Zhang, Qi Z, intel-wired-lan, brouer
In-Reply-To: <CAJ8uoz2K+5WR37yoNcEsZhC9JyPbb4CuxoFbpdQBkAccnG+Row@mail.gmail.com>
On Wed, 16 May 2018 17:38:12 +0200
Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
> On Wed, May 16, 2018 at 4:38 PM, Magnus Karlsson
> <magnus.karlsson@gmail.com> wrote:
> > On Wed, May 16, 2018 at 4:28 PM, Jesper Dangaard Brouer
> > <brouer@redhat.com> wrote:
> >> On Tue, 15 May 2018 21:06:15 +0200
> >> Björn Töpel <bjorn.topel@gmail.com> wrote:
> >>
> >>> From: Magnus Karlsson <magnus.karlsson@intel.com>
> >>>
> >>> Here, the zero-copy ndo is implemented. As a shortcut, the existing
> >>> XDP Tx rings are used for zero-copy. This means that and XDP program
> >>> cannot redirect to an AF_XDP enabled XDP Tx ring.
> >>
> >> I've changed i40e1 to only have one queue via:
> >> $ ethtool -L i40e1 combined 1
> >>
> >> And then, I'm sending on queue 1, which is/should not be avail... and then crash/BUG:
> >>
> >> $ sudo taskset -c 2 ./xdpsock --tx --interface=i40e1 --queue=1
> >>
> >> [ 3799.936877] Number of in use tx queues changed invalidating tc mappings. Priority traffic
> >> classification disabled!
> >> [ 3799.972970] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> >> [ 3799.980790] PGD 80000007b0992067 P4D 80000007b0992067 PUD 7b62d4067 PMD 0
> >> [ 3799.987654] Oops: 0002 [#1] PREEMPT SMP PTI
> >> [ 3799.991831] Modules linked in: nf_nat_masquerade_ipv4 tun nfnetlink bridge stp llc nf_nat
> >> nf_conntrack rpcrdma ib_ipoib rdma_ucm ib_ucm ib_umad rdma_cm ib_cm iw_cm sunrpc mlx5_ib ib
> >> _uverbs ib_core coretemp kvm_intel kvm irqbypass intel_cstate intel_uncore intel_rapl_perf p
> >> cspkr i2c_i801 shpchp wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad sch_fq_codel i40e ml
> >> x5_core hid_generic ixgbe igb devlink mdio ptp sd_mod i2c_algo_bit i2c_core pps_core [last u
> >> nloaded: x_tables]
> >> [ 3800.033472] CPU: 2 PID: 2006 Comm: xdpsock Not tainted 4.17.0-rc3-af_xdp03_ZC_rfc+ #155
> >> [ 3800.041465] Hardware name: Supermicro Super Server/X10SRi-F, BIOS 2.0a 08/01/2016
> >> [ 3800.048943] RIP: 0010:i40e_xmit_frame_ring+0xd4/0x1490 [i40e]
> >> [ 3800.054683] RSP: 0018:ffffc9000407bcd0 EFLAGS: 00010293
> >> [ 3800.059900] RAX: 0000000000000000 RBX: ffff88084f0fd200 RCX: 0000000000000000
> >> [ 3800.067022] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8807b6e710c0
> >> [ 3800.074148] RBP: ffff8807c6397800 R08: 00000000000000c0 R09: 0000000000000001
> >> [ 3800.081270] R10: 0000000000000800 R11: 0000000000000010 R12: 0000000000000001
> >> [ 3800.088396] R13: 0000000000000000 R14: 0000000000000001 R15: 000000000000003c
> >> [ 3800.095520] FS: 00007f1d1e00bb80(0000) GS:ffff88087fc80000(0000) knlGS:0000000000000000
> >> [ 3800.103597] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> >> [ 3800.109335] CR2: 0000000000000008 CR3: 000000087d542001 CR4: 00000000003606e0
> >> [ 3800.116458] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> >> [ 3800.123583] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> >> [ 3800.130706] Call Trace:
> >> [ 3800.133157] ? validate_xmit_skb.isra.116+0x1c/0x270
> >> [ 3800.138118] dev_direct_xmit+0xec/0x1d0
> >> [ 3800.141949] xsk_sendmsg+0x1f4/0x380
> >> [ 3800.145521] sock_sendmsg+0x30/0x40
> >> [ 3800.149005] __sys_sendto+0x10e/0x140
> >> [ 3800.152662] ? __do_page_fault+0x283/0x500
> >> [ 3800.156751] __x64_sys_sendto+0x24/0x30
> >> [ 3800.160585] do_syscall_64+0x42/0xf0
> >> [ 3800.164156] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >> [ 3800.169204] RIP: 0033:0x7f1d1d9db430
> >> [ 3800.172774] RSP: 002b:00007fffb7278610 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
> >> [ 3800.180333] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1d1d9db430
> >> [ 3800.187456] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
> >> [ 3800.194582] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> >> [ 3800.201705] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000
> >> [ 3800.208830] R13: 0000000000000000 R14: 0000000000755510 R15: 00007f1d0d3fc000
> >> [ 3800.215953] Code: d0 0f 86 db 05 00 00 01 c8 0f b7 ca 29 c8 83 e8 01 39 c6 0f 8f ea 06 00 00 48 8b 45 28 48 8d 14 92 41 b9 01 00 00 00 4c 8d 2c d0 <49> 89 5d 08 8b 83 80 00 00 00 66 45 89 4d 14 41 89 45 10 0f b7
> >> [ 3800.234798] RIP: i40e_xmit_frame_ring+0xd4/0x1490 [i40e] RSP: ffffc9000407bcd0
> >> [ 3800.242005] CR2: 0000000000000008
> >> [ 3800.245320] ---[ end trace f169e36f468e0c59 ]---
> >> [ 3801.726719] Kernel panic - not syncing: Fatal exception in interrupt
> >> [ 3801.733097] Kernel Offset: disabled
> >> [ 3801.785836] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
> >> [ 3801.793403] ------------[ cut here ]------------
> >>
> >> (gdb) list *(i40e_xmit_frame_ring)+0xd4
> >> 0x2ccd4 is in i40e_xmit_frame_ring (drivers/net/ethernet/intel/i40e/i40e_txrx.c:4048).
> >> warning: Source file is more recent than executable.
> >> 4043 return NETDEV_TX_BUSY;
> >> 4044 }
> >> 4045
> >> 4046 /* record the location of the first descriptor for this packet */
> >> 4047 first = &tx_ring->tx_bi[tx_ring->next_to_use];
> >> 4048 first->skb = skb;
> >> 4049 first->bytecount = skb->len;
> >> 4050 first->gso_segs = 1;
> >> 4051
> >> 4052 /* prepare the xmit flags */
> >>
> >>
> >> (gdb) list *(xsk_sendmsg)+0x1f4
> >> 0xffffffff81800c34 is in xsk_sendmsg (net/xdp/xsk.c:251).
> >> warning: Source file is more recent than executable.
> >> 246 skb_shinfo(skb)->destructor_arg = (void *)(long)id;
> >> 247 skb->destructor = xsk_destruct_skb;
> >> 248
> >> 249 err = dev_direct_xmit(skb, xs->queue_id);
> >> 250 /* Ignore NET_XMIT_CN as packet might have been sent */
> >> 251 if (err == NET_XMIT_DROP || err == NETDEV_TX_BUSY) {
> >> 252 err = -EAGAIN;
> >> 253 /* SKB consumed by dev_direct_xmit() */
> >> 254 goto out;
> >> 255 }
> >
>
> Found it. Checked num_rx_queues in the xsk_bind code instead of
> real_num_rx_queues. The code below will solve the problem. Will post a
> proper patch for it tomorrow. Thanks Jesper for reporting this.
> Appreciated.
>
> /Magnus
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index ac97902..4b62a1e 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -391,7 +391,8 @@ static int xsk_bind(struct socket *sock, struct
> sockaddr *addr, int addr_len)
> goto out_unlock;
> }
>
> - if (sxdp->sxdp_queue_id >= dev->num_rx_queues) {
> + if ((xs->rx && sxdp->sxdp_queue_id >= dev->real_num_rx_queues) ||
> + (xs->tx && sxdp->sxdp_queue_id >= dev->real_num_tx_queues)) {
> err = -EINVAL;
> goto out_unlock;
> }
Tried this patch... it fixed/catched the problem :-)
$ sudo ./xdpsock --interface=i40e1 --queue=42 --txonly
samples/bpf/xdpsock_user.c:xsk_configure:528: Assertion failed: bind(sfd, (struct sockaddr *)&sxdp, sizeof(sxdp)) == 0: errno: 22/"Invalid argument"
Segmentation fault
You can add:
Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
Notice: this bug is not related to this zero-copy patch, but to your
previous patchset, which are in bpf-next. Thus, you need to send a fix
patch to bpf-next...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC bpf-next 07/11] bpf: Add helper to retrieve socket in BPF
From: Joe Stringer @ 2018-05-16 18:55 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: Alexei Starovoitov, Joe Stringer, daniel, netdev, ast,
john fastabend
In-Reply-To: <20180515164801.lp5oyabhnukagczc@kafai-mbp.dhcp.thefacebook.com>
On 15 May 2018 at 09:48, Martin KaFai Lau <kafai@fb.com> wrote:
> On Mon, May 14, 2018 at 08:16:59PM -0700, Alexei Starovoitov wrote:
>> On Fri, May 11, 2018 at 05:54:33PM -0700, Joe Stringer wrote:
>> > On 11 May 2018 at 14:41, Martin KaFai Lau <kafai@fb.com> wrote:
>> > > On Fri, May 11, 2018 at 02:08:01PM -0700, Joe Stringer wrote:
>> > >> On 10 May 2018 at 22:00, Martin KaFai Lau <kafai@fb.com> wrote:
>> > >> > On Wed, May 09, 2018 at 02:07:05PM -0700, Joe Stringer wrote:
>> > >> >> This patch adds a new BPF helper function, sk_lookup() which allows BPF
>> > >> >> programs to find out if there is a socket listening on this host, and
>> > >> >> returns a socket pointer which the BPF program can then access to
>> > >> >> determine, for instance, whether to forward or drop traffic. sk_lookup()
>> > >> >> takes a reference on the socket, so when a BPF program makes use of this
>> > >> >> function, it must subsequently pass the returned pointer into the newly
>> > >> >> added sk_release() to return the reference.
>> > >> >>
>> > >> >> By way of example, the following pseudocode would filter inbound
>> > >> >> connections at XDP if there is no corresponding service listening for
>> > >> >> the traffic:
>> > >> >>
>> > >> >> struct bpf_sock_tuple tuple;
>> > >> >> struct bpf_sock_ops *sk;
>> > >> >>
>> > >> >> populate_tuple(ctx, &tuple); // Extract the 5tuple from the packet
>> > >> >> sk = bpf_sk_lookup(ctx, &tuple, sizeof tuple, netns, 0);
>> > >> >> if (!sk) {
>> > >> >> // Couldn't find a socket listening for this traffic. Drop.
>> > >> >> return TC_ACT_SHOT;
>> > >> >> }
>> > >> >> bpf_sk_release(sk, 0);
>> > >> >> return TC_ACT_OK;
>> > >> >>
>> > >> >> Signed-off-by: Joe Stringer <joe@wand.net.nz>
>> > >> >> ---
>> > >>
>> > >> ...
>> > >>
>> > >> >> @@ -4032,6 +4036,96 @@ static const struct bpf_func_proto bpf_skb_get_xfrm_state_proto = {
>> > >> >> };
>> > >> >> #endif
>> > >> >>
>> > >> >> +struct sock *
>> > >> >> +sk_lookup(struct net *net, struct bpf_sock_tuple *tuple) {
>> > >> > Would it be possible to have another version that
>> > >> > returns a sk without taking its refcnt?
>> > >> > It may have performance benefit.
>> > >>
>> > >> Not really. The sockets are not RCU-protected, and established sockets
>> > >> may be torn down without notice. If we don't take a reference, there's
>> > >> no guarantee that the socket will continue to exist for the duration
>> > >> of running the BPF program.
>> > >>
>> > >> From what I follow, the comment below has a hidden implication which
>> > >> is that sockets without SOCK_RCU_FREE, eg established sockets, may be
>> > >> directly freed regardless of RCU.
>> > > Right, SOCK_RCU_FREE sk is the one I am concern about.
>> > > For example, TCP_LISTEN socket does not require taking a refcnt
>> > > now. Doing a bpf_sk_lookup() may have a rather big
>> > > impact on handling TCP syn flood. or the usual intention
>> > > is to redirect instead of passing it up to the stack?
>> >
>> > I see, if you're only interested in listen sockets then probably this
>> > series could be extended with a new flag, eg something like
>> > BPF_F_SK_FIND_LISTENERS which restricts the set of possible sockets
>> > found to only listen sockets, then the implementation would call into
>> > __inet_lookup_listener() instead of inet_lookup(). The presence of
>> > that flag in the relevant register during CALL instruction would show
>> > that the verifier should not reference-track the result, then there'd
>> > need to be a check on the release to ensure that this unreferenced
>> > socket is never released. Just a thought, completely untested and I
>> > could still be missing some detail..
>> >
>> > That said, I don't completely follow how you would expect to handle
>> > the traffic for sockets that are already established - the helper
>> > would no longer find those sockets, so you wouldn't know whether to
>> > pass the traffic up the stack for established traffic or not.
>>
>> I think Martin has a valid concern here that if somebody starts using
>> this helper on the rx traffic the bpf program (via these two new
>> helpers) will be doing refcnt++ and refcnt-- even for listener
>> sockets which will cause synflood to suffer.
>> One can argue that this is bpf author mistake, but without fixes
>> (and api changes) to the helper the programmer doesn't really have a way
>> of avoiding this situation.
>> Also udp sockets don't need refcnt at all.
>> How about we split this single helper into three:
>> - bpf_sk_lookup_tcp_established() that will return refcnt-ed socket
>> and has to be bpf_sk_release()d by the program.
>> - bpf_sk_lookup_tcp_listener() that doesn't refcnt, since progs
>> run in rcu.
>> - bpf_sk_lookup_udp() that also doesn't refcnt.
>> The logic you want to put into this helper can be easily
>> replicated with these three helpers and the whole thing will
>> be much faster.
>> Thoughts?
> Just came to my mind.
>
> or can we explore something like:
>
> On the bpf_sk_lookup() side, use __inet[6]_lookup()
> and __udp[46]_lib_lookup() instead. That should
> only take refcnt if it has to.
>
> On the bpf_sk_release() side, it skips refcnt--
> if sk is SOCK_RCU_FREE.
Reflecting the discussion from IOVisor call:
I voiced a concern with the above proposal by Alexei that it leaks
kernel implementation detail (established sockets are refcnted) into
the BPF API.
Martin's proposal here addresses this concern. We can force all
sk_lookup()s to match with a bpf_sk_release(), then inside the
bpf_sk_release() we can deal with the details of whether any freeing
is actually required.
It's still useful to split the helpers out into bpf_sk_lookup_tcp()
and bpf_sk_lookup_udp() because then we don't need to deal with the
forward-compatibility concern of adding support for different socket
types (eg SCTP). That said, the TCP established/listener split does
not have an immediate user, so we don't need to split these at this
time. If there is a use case for only finding the listener sockets, we
can always add a flag to the bpf_sk_lookup_tcp() helper to only find
the listener sockets.
I'll respin, thanks for the feedback all.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up
From: David Miller @ 2018-05-16 18:56 UTC (permalink / raw)
To: Jose.Abreu
Cc: netdev, Joao.Pinto, Vitor.Soares, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <cover.1526474646.git.joabreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Wed, 16 May 2018 13:50:42 +0100
> David raised some rightfull constrains about the use of indirect callbacks in
> the code. I did iperf tests with and without patches 3-12 and the performance
> remained equal. I guess for 1Gb/s and because my setup has a powerfull
> processor these patches don't affect the performance.
Does your cpu need Spectre v1 and v2 workarounds which cause indirect calls to
be extremely expensive?
That's the case I'm worried about.
^ permalink raw reply
* Re: [PATCH net-next V2 2/2] cxgb4: Support ethtool private flags
From: David Miller @ 2018-05-16 19:00 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun, leedom
In-Reply-To: <1526476284-6496-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 16 May 2018 18:41:24 +0530
> From: Arjun Vynipadath <arjun@chelsio.com>
>
> This is used to change TX workrequests, which helps in
> host->vf communication.
>
> Signed-off-by: Arjun Vynipadath <arjun@chelsio.com>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
> ---
> V2: no v2 changes in this patch
I don't know about this.
Perhaps find some way to high level abstract what this thing is so that
if another chip has the same kind of control they can use the same
generic ethtool flag/setting?
Thank you.
^ permalink raw reply
* Re: [PATCH net-next V2 1/2] cxgb4: Add support for FW_ETH_TX_PKT_VM_WR
From: David Miller @ 2018-05-16 19:00 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh, arjun, leedom
In-Reply-To: <1526476247-6452-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 16 May 2018 18:40:47 +0530
> @@ -554,6 +563,7 @@ struct port_info {
> struct hwtstamp_config tstamp_config;
> bool ptp_enable;
> struct sched_table *sched_tbl;
> + u32 eth_flags;
> };
>
> struct dentry;
> @@ -864,6 +874,7 @@ struct adapter {
> unsigned int flags;
> unsigned int adap_idx;
> enum chip_type chip;
> + unsigned int eth_flags;
Both of these new struct members should use the same type.
But see my feedback for patch #2 first.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up
From: Florian Fainelli @ 2018-05-16 19:01 UTC (permalink / raw)
To: David Miller, Jose.Abreu
Cc: netdev, Joao.Pinto, Vitor.Soares, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <20180516.145611.65752290278287985.davem@davemloft.net>
On 05/16/2018 11:56 AM, David Miller wrote:
> From: Jose Abreu <Jose.Abreu@synopsys.com>
> Date: Wed, 16 May 2018 13:50:42 +0100
>
>> David raised some rightfull constrains about the use of indirect callbacks in
>> the code. I did iperf tests with and without patches 3-12 and the performance
>> remained equal. I guess for 1Gb/s and because my setup has a powerfull
>> processor these patches don't affect the performance.
>
> Does your cpu need Spectre v1 and v2 workarounds which cause indirect calls to
> be extremely expensive?
Given how widespread stmmac is within the ARM CPU's ecosystem, the
answer is more than likely yes.
To get a better feeling of whether your indirect branches introduce a
difference, either don't run the CPU at full speed (e.g: use cpufreq to
slow it down), and/or profile the number of cycles and instruction cache
hits/miss ratio for the functions called in hot-path.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: update LE-TCAM collection for T6
From: David Miller @ 2018-05-16 19:01 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, ganeshgr, nirranjan, indranil
In-Reply-To: <1526480475-18867-1-git-send-email-rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Wed, 16 May 2018 19:51:15 +0530
> For T6, clip table is separated from main TCAM. So, update LE-TCAM
> collection logic to collect clip table TCAM as well. IPv6 takes
> 4 entries in clip table TCAM compared to 2 entries in main TCAM.
>
> Also, in case of errors, keep LE-TCAM collected so far and set the
> status to partial dump.
>
> Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC bpf-next 00/11] Add socket lookup support
From: Joe Stringer @ 2018-05-16 19:05 UTC (permalink / raw)
To: Joe Stringer; +Cc: daniel, netdev, ast, john fastabend, tgraf, Martin KaFai Lau
In-Reply-To: <20180509210709.7201-1-joe@wand.net.nz>
On 9 May 2018 at 14:06, Joe Stringer <joe@wand.net.nz> wrote:
> This series proposes a new helper for the BPF API which allows BPF programs to
> perform lookups for sockets in a network namespace. This would allow programs
> to determine early on in processing whether the stack is expecting to receive
> the packet, and perform some action (eg drop, forward somewhere) based on this
> information.
>
> The series is structured roughly into:
> * Misc refactor
> * Add the socket pointer type
> * Add reference tracking to ensure that socket references are freed
> * Extend the BPF API to add sk_lookup() / sk_release() functions
> * Add tests/documentation
>
> The helper proposed in this series includes a parameter for a tuple which must
> be filled in by the caller to determine the socket to look up. The simplest
> case would be filling with the contents of the packet, ie mapping the packet's
> 5-tuple into the parameter. In common cases, it may alternatively be useful to
> reverse the direction of the tuple and perform a lookup, to find the socket
> that initiates this connection; and if the BPF program ever performs a form of
> IP address translation, it may further be useful to be able to look up
> arbitrary tuples that are not based upon the packet, but instead based on state
> held in BPF maps or hardcoded in the BPF program.
>
> Currently, access into the socket's fields are limited to those which are
> otherwise already accessible, and are restricted to read-only access.
>
> A few open points:
> * Currently, the lookup interface only returns either a valid socket or a NULL
> pointer. This means that if there is any kind of issue with the tuple, such
> as it provides an unsupported protocol number, or the socket can't be found,
> then we are unable to differentiate these cases from one another. One natural
> approach to improve this could be to return an ERR_PTR from the
> bpf_sk_lookup() helper. This would be more complicated but maybe it's
> worthwhile.
This suggestion would add a lot of complexity, and there's not many
legitimately different error cases. There's:
* Unsupported socket type
* Cannot find netns
* Tuple argument is the wrong size
* Can't find socket
If we split the helpers into protocol-specific types, the first one
would be addressed. The last one is addressed by returning NULL. It
seems like a reasonable compromise to me to return NULL also in the
middle two cases as well, and rely on the BPF writer to provide valid
arguments.
> * No ordering is defined between sockets. If the tuple could find multiple
> sockets, then it will arbitrarily return one. It is up to the caller to
> handle this. If we wish to handle this more reliably in future, we could
> encode an ordering preference in the flags field.
Doesn't need to be addressed with this series, there is scope for
addressing these cases when the use case arises.
> * Currently this helper is only defined for TC hook point, but it should also
> be valid at XDP and perhaps some other hooks.
Easy to add support for XDP on demand, initial implementation doesn't need it.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST
From: David Miller @ 2018-05-16 19:06 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, fugang.duan, andrew, linux-kernel
In-Reply-To: <20180516185258.20508-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 16 May 2018 11:52:55 -0700
> This patch series includes more drivers to be build tested with COMPILE_TEST
> enabled. This helps cover some of the issues I just ran into with missing
> a driver *sigh*.
>
> Changes in v2:
>
> - allow FEC to build outside of CONFIG_ARM/ARM64 by defining a layout of
> registers, this is not meant to run, so this is not a real issue if we
> are not matching the correct register layout
Ok, this is a lot better.
But man, some of these drivers...
drivers/net/ethernet/ti/davinci_cpdma.c: In function ‘cpdma_desc_pool_destroy’:
drivers/net/ethernet/ti/davinci_cpdma.c:194:7: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
"cpdma_desc_pool size %d != avail %d",
^
gen_pool_size(pool->gen_pool),
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and on and on and on...
But I'm really happy to see FEC and others at least being build tested
in more scenerios.
So applied, thanks.
^ permalink raw reply
* [PATCH v3] {net, IB}/mlx5: Use 'kvfree()' for memory allocated by 'kvzalloc()'
From: Christophe JAILLET @ 2018-05-16 19:07 UTC (permalink / raw)
To: saeedm, matanb, leon, dledford, jgg, davem
Cc: netdev, linux-rdma, linux-kernel, kernel-janitors,
Christophe JAILLET
When 'kvzalloc()' is used to allocate memory, 'kvfree()' must be used to
free it.
Fixes: 1cbe6fc86ccfe ("IB/mlx5: Add support for CQE compressing")
Fixes: fed9ce22bf8ae ("net/mlx5: E-Switch, Add API to create vport rx rules")
Fixes: 9efa75254593d ("net/mlx5_core: Introduce access functions to query vport RoCE fields")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
v1 -> v2: More places to update have been added to the patch
v2 -> v3: Add Fixes tag
3 patches with one Fixes tag each should probably be better, but honestly, I won't send a v4.
Fill free to split it if needed.
---
drivers/infiniband/hw/mlx5/cq.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/vport.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/mlx5/cq.c b/drivers/infiniband/hw/mlx5/cq.c
index 77d257ec899b..6d52ea03574e 100644
--- a/drivers/infiniband/hw/mlx5/cq.c
+++ b/drivers/infiniband/hw/mlx5/cq.c
@@ -849,7 +849,7 @@ static int create_cq_user(struct mlx5_ib_dev *dev, struct ib_udata *udata,
return 0;
err_cqb:
- kfree(*cqb);
+ kvfree(*cqb);
err_db:
mlx5_ib_db_unmap_user(to_mucontext(context), &cq->db);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index 35e256eb2f6e..b123f8a52ad8 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -663,7 +663,7 @@ static int esw_create_vport_rx_group(struct mlx5_eswitch *esw)
esw->offloads.vport_rx_group = g;
out:
- kfree(flow_group_in);
+ kvfree(flow_group_in);
return err;
}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/vport.c b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
index 177e076b8d17..719cecb182c6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/vport.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/vport.c
@@ -511,7 +511,7 @@ int mlx5_query_nic_vport_system_image_guid(struct mlx5_core_dev *mdev,
*system_image_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.system_image_guid);
- kfree(out);
+ kvfree(out);
return 0;
}
@@ -531,7 +531,7 @@ int mlx5_query_nic_vport_node_guid(struct mlx5_core_dev *mdev, u64 *node_guid)
*node_guid = MLX5_GET64(query_nic_vport_context_out, out,
nic_vport_context.node_guid);
- kfree(out);
+ kvfree(out);
return 0;
}
@@ -587,7 +587,7 @@ int mlx5_query_nic_vport_qkey_viol_cntr(struct mlx5_core_dev *mdev,
*qkey_viol_cntr = MLX5_GET(query_nic_vport_context_out, out,
nic_vport_context.qkey_violation_counter);
- kfree(out);
+ kvfree(out);
return 0;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST
From: David Miller @ 2018-05-16 19:07 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, fugang.duan, andrew, linux-kernel
In-Reply-To: <20180516.150659.104496510409110952.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 16 May 2018 15:06:59 -0400 (EDT)
> So applied, thanks.
Nevermind, eventually got a build failure:
ERROR: "knav_queue_open" [drivers/net/ethernet/ti/keystone_netcp.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
make: *** [Makefile:1276: modules] Error 2
Reverted.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: Allow more drivers with COMPILE_TEST
From: Florian Fainelli @ 2018-05-16 19:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fugang.duan, andrew, linux-kernel
In-Reply-To: <20180516.150746.403203754959197656.davem@davemloft.net>
On 05/16/2018 12:07 PM, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Wed, 16 May 2018 15:06:59 -0400 (EDT)
>
>> So applied, thanks.
>
> Nevermind, eventually got a build failure:
>
> ERROR: "knav_queue_open" [drivers/net/ethernet/ti/keystone_netcp.ko] undefined!
> make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
> make: *** [Makefile:1276: modules] Error 2
Snap, ok, let me do some more serious build testing with different
architectures here.
Sorry about that.
--
Florian
^ permalink raw reply
* [RFC PATCH] net: hns3: hns3_pci_sriov_configure() can be static
From: kbuild test robot @ 2018-05-16 19:47 UTC (permalink / raw)
To: Salil Mehta
Cc: kbuild-all, davem, salil.mehta, yisen.zhuang, lipeng321,
mehta.salil, netdev, linux-kernel, linuxarm
In-Reply-To: <20180515182014.42196-10-salil.mehta@huawei.com>
Fixes: fdb793670a00 ("net: hns3: Add support of .sriov_configure in HNS3 driver")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index e85ff38..3617b9d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1579,7 +1579,7 @@ static void hns3_remove(struct pci_dev *pdev)
* Enable or change the number of VFs. Called when the user updates the number
* of VFs in sysfs.
**/
-int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
+static int hns3_pci_sriov_configure(struct pci_dev *pdev, int num_vfs)
{
int ret;
^ permalink raw reply related
* Re: [PATCH net-next 09/10] net: hns3: Add support of .sriov_configure in HNS3 driver
From: kbuild test robot @ 2018-05-16 19:47 UTC (permalink / raw)
To: Salil Mehta
Cc: kbuild-all, davem, salil.mehta, yisen.zhuang, lipeng321,
mehta.salil, netdev, linux-kernel, linuxarm
In-Reply-To: <20180515182014.42196-10-salil.mehta@huawei.com>
Hi Peng,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Salil-Mehta/Misc-Bug-Fixes-and-clean-ups-for-HNS3-Driver/20180516-211239
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:266:16: sparse: expression using sizeof(void)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:266:16: sparse: expression using sizeof(void)
>> drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:1582:5: sparse: symbol 'hns3_pci_sriov_configure' was not declared. Should it be static?
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2513:21: sparse: expression using sizeof(void)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2706:22: sparse: expression using sizeof(void)
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c:2706:22: sparse: expression using sizeof(void)
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH 0/3] Add R8A77980 GEther support
From: Sergei Shtylyov @ 2018-05-16 19:52 UTC (permalink / raw)
To: netdev, devicetree, David S. Miller, Rob Herring
Cc: Mark Rutland, linux-renesas-soc
Hello!
Here's a set of 3 patches against DaveM's 'net-next.git' repo. They (gradually)
add R8A77980 GEther support to the 'sh_eth' driver, starting with couple new
register bits/values introduced with this chip, and ending with adding a new
'struct sh_eth_cpu_data' instance connected to the new DT "compatible" prop
value...
[1/1] sh_eth: add RGMII support
[2/3] sh_eth: add EDMR.NBST support
[3/3] sh_eth: add R8A77980 support
MBR, Sergei
^ permalink raw reply
* [PATCH 1/3] sh_eth: add RGMII support
From: Sergei Shtylyov @ 2018-05-16 19:56 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <087c91a3-a451-6de7-5e0f-a835f8cc98f1@cogentembedded.com>
The R-Car V3H (AKA R8A77980) GEther controller adds support for the RGMII
PHY interface mode as a new value for the RMII_MII register.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 3 +++
1 file changed, 3 insertions(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -466,6 +466,9 @@ static void sh_eth_select_mii(struct net
u32 value;
switch (mdp->phy_interface) {
+ case PHY_INTERFACE_MODE_RGMII:
+ value = 0x3;
+ break;
case PHY_INTERFACE_MODE_GMII:
value = 0x2;
break;
^ permalink raw reply
* [PATCH 2/3] sh_eth: add EDMR.NBST support
From: Sergei Shtylyov @ 2018-05-16 19:58 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: linux-renesas-soc
In-Reply-To: <087c91a3-a451-6de7-5e0f-a835f8cc98f1@cogentembedded.com>
The R-Car V3H (AKA R8A77980) GEther controller adds the DMA burst mode bit
(NBST) in EDMR and the manual tells to always set it before doing any DMA.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 4 ++++
drivers/net/ethernet/renesas/sh_eth.h | 2 ++
2 files changed, 6 insertions(+)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -1434,6 +1434,10 @@ static int sh_eth_dev_init(struct net_de
sh_eth_write(ndev, mdp->cd->trscer_err_mask, TRSCER);
+ /* DMA transfer burst mode */
+ if (mdp->cd->nbst)
+ sh_eth_modify(ndev, EDMR, EDMR_NBST, EDMR_NBST);
+
if (mdp->cd->bculr)
sh_eth_write(ndev, 0x800, BCULR); /* Burst sycle set */
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -184,6 +184,7 @@ enum GECMR_BIT {
/* EDMR */
enum DMAC_M_BIT {
+ EDMR_NBST = 0x80,
EDMR_EL = 0x40, /* Litte endian */
EDMR_DL1 = 0x20, EDMR_DL0 = 0x10,
EDMR_SRST_GETHER = 0x03,
@@ -505,6 +506,7 @@ struct sh_eth_cpu_data {
unsigned bculr:1; /* EtherC have BCULR */
unsigned tsu:1; /* EtherC have TSU */
unsigned hw_swap:1; /* E-DMAC have DE bit in EDMR */
+ unsigned nbst:1; /* E-DMAC has NBST bit in EDMR */
unsigned rpadir:1; /* E-DMAC have RPADIR */
unsigned no_trimd:1; /* E-DMAC DO NOT have TRIMD */
unsigned no_ade:1; /* E-DMAC DO NOT have ADE bit in EESR */
^ permalink raw reply
* [PATCH 3/3] sh_eth: add R8A77980 support
From: Sergei Shtylyov @ 2018-05-16 20:00 UTC (permalink / raw)
To: netdev, devicetree, David S. Miller, Rob Herring
Cc: Mark Rutland, linux-renesas-soc
In-Reply-To: <087c91a3-a451-6de7-5e0f-a835f8cc98f1@cogentembedded.com>
Finally, add support for the DT probing of the R-Car V3H (AKA R8A77980) --
it's the only R-Car gen3 SoC having the GEther controller -- others have
only EtherAVB...
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Documentation/devicetree/bindings/net/sh_eth.txt | 1
drivers/net/ethernet/renesas/sh_eth.c | 44 +++++++++++++++++++++++
2 files changed, 45 insertions(+)
Index: net-next/Documentation/devicetree/bindings/net/sh_eth.txt
===================================================================
--- net-next.orig/Documentation/devicetree/bindings/net/sh_eth.txt
+++ net-next/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -14,6 +14,7 @@ Required properties:
"renesas,ether-r8a7791" if the device is a part of R8A7791 SoC.
"renesas,ether-r8a7793" if the device is a part of R8A7793 SoC.
"renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
+ "renesas,gether-r8a77980" if the device is a part of R8A77980 SoC.
"renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
"renesas,rcar-gen1-ether" for a generic R-Car Gen1 device.
"renesas,rcar-gen2-ether" for a generic R-Car Gen2 or RZ/G1
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -753,6 +753,49 @@ static struct sh_eth_cpu_data rcar_gen2_
.rmiimode = 1,
.magic = 1,
};
+
+/* R8A77980 */
+static struct sh_eth_cpu_data r8a77980_data = {
+ .soft_reset = sh_eth_soft_reset_gether,
+
+ .set_duplex = sh_eth_set_duplex,
+ .set_rate = sh_eth_set_rate_gether,
+
+ .register_type = SH_ETH_REG_GIGABIT,
+
+ .edtrr_trns = EDTRR_TRNS_GETHER,
+ .ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD | ECSR_MPD,
+ .ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP |
+ ECSIPR_MPDIP,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
+
+ .tx_check = EESR_FTC | EESR_CD | EESR_RTO,
+ .eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
+ EESR_RFE | EESR_RDE | EESR_RFRMER |
+ EESR_TFE | EESR_TDE | EESR_ECI,
+ .fdr_value = 0x0000070f,
+
+ .apr = 1,
+ .mpr = 1,
+ .tpauser = 1,
+ .bculr = 1,
+ .hw_swap = 1,
+ .nbst = 1,
+ .rpadir = 1,
+ .rpadir_value = 2 << 16,
+ .no_trimd = 1,
+ .no_ade = 1,
+ .xdfar_rw = 1,
+ .hw_checksum = 1,
+ .select_mii = 1,
+ .magic = 1,
+ .cexcr = 1,
+};
#endif /* CONFIG_OF */
static void sh_eth_set_rate_sh7724(struct net_device *ndev)
@@ -3134,6 +3177,7 @@ static const struct of_device_id sh_eth_
{ .compatible = "renesas,ether-r8a7791", .data = &rcar_gen2_data },
{ .compatible = "renesas,ether-r8a7793", .data = &rcar_gen2_data },
{ .compatible = "renesas,ether-r8a7794", .data = &rcar_gen2_data },
+ { .compatible = "renesas,gether-r8a77980", .data = &r8a77980_data },
{ .compatible = "renesas,ether-r7s72100", .data = &r7s72100_data },
{ .compatible = "renesas,rcar-gen1-ether", .data = &rcar_gen1_data },
{ .compatible = "renesas,rcar-gen2-ether", .data = &rcar_gen2_data },
^ permalink raw reply
* Re: [RFC bpf-next 00/11] Add socket lookup support
From: Alexei Starovoitov @ 2018-05-16 20:04 UTC (permalink / raw)
To: Joe Stringer; +Cc: daniel, netdev, ast, john fastabend, tgraf, Martin KaFai Lau
In-Reply-To: <CAOftzPhtPtZsqjT=Vrd-04qXdZKWJhPhuQ2maeJmK-os0nzdJw@mail.gmail.com>
On Wed, May 16, 2018 at 12:05:06PM -0700, Joe Stringer wrote:
> >
> > A few open points:
> > * Currently, the lookup interface only returns either a valid socket or a NULL
> > pointer. This means that if there is any kind of issue with the tuple, such
> > as it provides an unsupported protocol number, or the socket can't be found,
> > then we are unable to differentiate these cases from one another. One natural
> > approach to improve this could be to return an ERR_PTR from the
> > bpf_sk_lookup() helper. This would be more complicated but maybe it's
> > worthwhile.
>
> This suggestion would add a lot of complexity, and there's not many
> legitimately different error cases. There's:
> * Unsupported socket type
> * Cannot find netns
> * Tuple argument is the wrong size
> * Can't find socket
>
> If we split the helpers into protocol-specific types, the first one
> would be addressed. The last one is addressed by returning NULL. It
> seems like a reasonable compromise to me to return NULL also in the
> middle two cases as well, and rely on the BPF writer to provide valid
> arguments.
>
> > * No ordering is defined between sockets. If the tuple could find multiple
> > sockets, then it will arbitrarily return one. It is up to the caller to
> > handle this. If we wish to handle this more reliably in future, we could
> > encode an ordering preference in the flags field.
>
> Doesn't need to be addressed with this series, there is scope for
> addressing these cases when the use case arises.
Thanks for summarizing the conf call discussion.
Looking forward to non-rfc patches :)
^ permalink raw reply
* Re: [PATCH bpf-next v6 2/4] bpf: sockmap, add hash map support
From: Daniel Borkmann @ 2018-05-16 20:08 UTC (permalink / raw)
To: Y Song; +Cc: John Fastabend, Alexei Starovoitov, netdev, David Miller
In-Reply-To: <CAH3MdRVRSFtcNb=cAk+NeOS=UzTt0tuPkV4W-TtD1D_e6ihYYQ@mail.gmail.com>
On 05/15/2018 11:09 PM, Y Song wrote:
> On Tue, May 15, 2018 at 12:01 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 05/14/2018 07:00 PM, John Fastabend wrote:
[...]
>>> enum bpf_prog_type {
>>> @@ -1855,6 +1856,52 @@ struct bpf_stack_build_id {
>>> * Egress device index on success, 0 if packet needs to continue
>>> * up the stack for further processing or a negative error in case
>>> * of failure.
>>> + * int bpf_sock_hash_update(struct bpf_sock_ops_kern *skops, struct bpf_map *map, void *key, u64 flags)
>>
>> When you rebase please fix this up properly next time and add a newline in between
>> the helpers. I fixed this up while applying.
>
> I guess the tools/include/uapi/linux/bpf.h may also need fixup to be
> in sync with main bpf.h.
Yep agree, just fixed it up, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] samples/bpf: Decrement ttl in fib forwarding example
From: Daniel Borkmann @ 2018-05-16 20:09 UTC (permalink / raw)
To: David Ahern, netdev, borkmann, ast
In-Reply-To: <20180515232052.28004-1-dsahern@gmail.com>
On 05/16/2018 01:20 AM, David Ahern wrote:
> Only consider forwarding packets if ttl in received packet is > 1 and
> decrement ttl before handing off to bpf_redirect_map.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Looks good, applied to bpf-next, thanks David!
^ 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