* [PATCH net-next] cxgb4: Mask out interrupts that are not enabled.
From: Vishal Kulkarni @ 2019-02-17 4:15 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, dt, Vishal Kulkarni
There are rare cases where a PL_INT_CAUSE bit may end up getting
set when the corresponding PL_INT_ENABLE bit isn't set.
Signed-off-by: Vishal Kulkarni <vishal@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 27af347..49e4374 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -4962,7 +4962,13 @@ static void pl_intr_handler(struct adapter *adap)
*/
int t4_slow_intr_handler(struct adapter *adapter)
{
- u32 cause = t4_read_reg(adapter, PL_INT_CAUSE_A);
+ /* There are rare cases where a PL_INT_CAUSE bit may end up getting
+ * set when the corresponding PL_INT_ENABLE bit isn't set. It's
+ * easiest just to mask that case here.
+ */
+ u32 raw_cause = t4_read_reg(adapter, PL_INT_CAUSE_A);
+ u32 enable = t4_read_reg(adapter, PL_INT_ENABLE_A);
+ u32 cause = raw_cause & enable;
if (!(cause & GLBL_INTR_MASK))
return 0;
@@ -5014,7 +5020,7 @@ int t4_slow_intr_handler(struct adapter *adapter)
ulptx_intr_handler(adapter);
/* Clear the interrupts just processed for which we are the master. */
- t4_write_reg(adapter, PL_INT_CAUSE_A, cause & GLBL_INTR_MASK);
+ t4_write_reg(adapter, PL_INT_CAUSE_A, raw_cause & GLBL_INTR_MASK);
(void)t4_read_reg(adapter, PL_INT_CAUSE_A); /* flush */
return 1;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net-next] iptunnel: NULL pointer deref for ip_md_tunnel_xmit
From: wenxu @ 2019-02-17 3:48 UTC (permalink / raw)
To: Alan Maguire, davem
Cc: naresh.kamboju, kuznet, yoshfuji, ast, daniel, kafai,
songliubraving, yhs, netdev
In-Reply-To: <alpine.LRH.2.20.1902150937450.3593@dhcp-10-175-220-187.vpn.oracle.com>
On 2019/2/15 下午5:38, Alan Maguire wrote:
> Naresh Kamboju noted the following oops during execution of selftest
> tools/testing/selftests/bpf/test_tunnel.sh on x86_64:
>
> [ 274.120445] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000000
> [ 274.128285] #PF error: [INSTR]
> [ 274.131351] PGD 8000000414a0e067 P4D 8000000414a0e067 PUD 3b6334067 PMD 0
> [ 274.138241] Oops: 0010 [#1] SMP PTI
> [ 274.141734] CPU: 1 PID: 11464 Comm: ping Not tainted
> 5.0.0-rc4-next-20190129 #1
> [ 274.149046] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
> 2.0b 07/27/2017
> [ 274.156526] RIP: 0010: (null)
> [ 274.160280] Code: Bad RIP value.
> [ 274.163509] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
> [ 274.168726] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
> [ 274.175851] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
> [ 274.182974] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
> [ 274.190098] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
> [ 274.197222] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
> [ 274.204346] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
> knlGS:0000000000000000
> [ 274.212424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 274.218162] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
> [ 274.225292] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 274.232416] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 274.239541] Call Trace:
> [ 274.241988] ? tnl_update_pmtu+0x296/0x3b0
> [ 274.246085] ip_md_tunnel_xmit+0x1bc/0x520
> [ 274.250176] gre_fb_xmit+0x330/0x390
> [ 274.253754] gre_tap_xmit+0x128/0x180
> [ 274.257414] dev_hard_start_xmit+0xb7/0x300
> [ 274.261598] sch_direct_xmit+0xf6/0x290
> [ 274.265430] __qdisc_run+0x15d/0x5e0
> [ 274.269007] __dev_queue_xmit+0x2c5/0xc00
> [ 274.273011] ? dev_queue_xmit+0x10/0x20
> [ 274.276842] ? eth_header+0x2b/0xc0
> [ 274.280326] dev_queue_xmit+0x10/0x20
> [ 274.283984] ? dev_queue_xmit+0x10/0x20
> [ 274.287813] arp_xmit+0x1a/0xf0
> [ 274.290952] arp_send_dst.part.19+0x46/0x60
> [ 274.295138] arp_solicit+0x177/0x6b0
> [ 274.298708] ? mod_timer+0x18e/0x440
> [ 274.302281] neigh_probe+0x57/0x70
> [ 274.305684] __neigh_event_send+0x197/0x2d0
> [ 274.309862] neigh_resolve_output+0x18c/0x210
> [ 274.314212] ip_finish_output2+0x257/0x690
> [ 274.318304] ip_finish_output+0x219/0x340
> [ 274.322314] ? ip_finish_output+0x219/0x340
> [ 274.326493] ip_output+0x76/0x240
> [ 274.329805] ? ip_fragment.constprop.53+0x80/0x80
> [ 274.334510] ip_local_out+0x3f/0x70
> [ 274.337992] ip_send_skb+0x19/0x40
> [ 274.341391] ip_push_pending_frames+0x33/0x40
> [ 274.345740] raw_sendmsg+0xc15/0x11d0
> [ 274.349403] ? __might_fault+0x85/0x90
> [ 274.353151] ? _copy_from_user+0x6b/0xa0
> [ 274.357070] ? rw_copy_check_uvector+0x54/0x130
> [ 274.361604] inet_sendmsg+0x42/0x1c0
> [ 274.365179] ? inet_sendmsg+0x42/0x1c0
> [ 274.368937] sock_sendmsg+0x3e/0x50
> [ 274.372460] ___sys_sendmsg+0x26f/0x2d0
> [ 274.376293] ? lock_acquire+0x95/0x190
> [ 274.380043] ? __handle_mm_fault+0x7ce/0xb70
> [ 274.384307] ? lock_acquire+0x95/0x190
> [ 274.388053] ? __audit_syscall_entry+0xdd/0x130
> [ 274.392586] ? ktime_get_coarse_real_ts64+0x64/0xc0
> [ 274.397461] ? __audit_syscall_entry+0xdd/0x130
> [ 274.401989] ? trace_hardirqs_on+0x4c/0x100
> [ 274.406173] __sys_sendmsg+0x63/0xa0
> [ 274.409744] ? __sys_sendmsg+0x63/0xa0
> [ 274.413488] __x64_sys_sendmsg+0x1f/0x30
> [ 274.417405] do_syscall_64+0x55/0x190
> [ 274.421064] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 274.426113] RIP: 0033:0x7ff4ae0e6e87
> [ 274.429686] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00
> 00 00 00 8b 05 ca d9 2b 00 48 63 d2 48 63 ff 85 c0 75 10 b8 2e 00 00
> 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 53 48 89 f3 48 83 ec 10 48 89 7c
> 24 08
> [ 274.448422] RSP: 002b:00007ffcd9b76db8 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002e
> [ 274.455978] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 00007ff4ae0e6e87
> [ 274.463104] RDX: 0000000000000000 RSI: 00000000006092e0 RDI: 0000000000000003
> [ 274.470228] RBP: 0000000000000000 R08: 00007ffcd9bc40a0 R09: 00007ffcd9bc4080
> [ 274.477349] R10: 000000000000060a R11: 0000000000000246 R12: 0000000000000003
> [ 274.484475] R13: 0000000000000016 R14: 00007ffcd9b77fa0 R15: 00007ffcd9b78da4
> [ 274.491602] Modules linked in: cls_bpf sch_ingress iptable_filter
> ip_tables algif_hash af_alg x86_pkg_temp_thermal fuse [last unloaded:
> test_bpf]
> [ 274.504634] CR2: 0000000000000000
> [ 274.507976] ---[ end trace 196d18386545eae1 ]---
> [ 274.512588] RIP: 0010: (null)
> [ 274.516334] Code: Bad RIP value.
> [ 274.519557] RSP: 0018:ffffbc9681f83540 EFLAGS: 00010286
> [ 274.524775] RAX: 0000000000000000 RBX: ffffdc967fa80a18 RCX: 0000000000000000
> [ 274.531921] RDX: ffff9db2ee08b540 RSI: 000000000000000e RDI: ffffdc967fa809a0
> [ 274.539082] RBP: ffffbc9681f83580 R08: ffff9db2c4d62690 R09: 000000000000000c
> [ 274.546205] R10: 0000000000000000 R11: ffff9db2ee08b540 R12: ffff9db31ce7c000
> [ 274.553329] R13: 0000000000000001 R14: 000000000000000c R15: ffff9db3179cf400
> [ 274.560456] FS: 00007ff4ae7c5740(0000) GS:ffff9db31fa80000(0000)
> knlGS:0000000000000000
> [ 274.568541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 274.574277] CR2: ffffffffffffffd6 CR3: 00000004574da004 CR4: 00000000003606e0
> [ 274.581403] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 274.588535] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 274.595658] Kernel panic - not syncing: Fatal exception in interrupt
> [ 274.602046] Kernel Offset: 0x14400000 from 0xffffffff81000000
> (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 274.612827] ---[ end Kernel panic - not syncing: Fatal exception in
> interrupt ]---
> [ 274.620387] ------------[ cut here ]------------
>
> I'm also seeing the same failure on x86_64, and it reproduces
> consistently.
>
> From poking around it looks like the skb's dst entry is being used
> to calculate the mtu in:
>
> mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> ...but because that dst_entry has an "ops" value set to md_dst_ops,
> the various ops (including mtu) are not set:
>
> crash> struct sk_buff._skb_refdst ffff928f87447700 -x
> _skb_refdst = 0xffffcd6fbf5ea590
> crash> struct dst_entry.ops 0xffffcd6fbf5ea590
> ops = 0xffffffffa0193800
> crash> struct dst_ops.mtu 0xffffffffa0193800
> mtu = 0x0
> crash>
>
> I confirmed that the dst entry also has dst->input set to
> dst_md_discard, so it looks like it's an entry that's been
> initialized via __metadata_dst_init alright.
>
> I think the fix here is to use skb_valid_dst(skb) - it checks
> for DST_METADATA also, and with that fix in place, the
> problem - which was previously 100% reproducible - disappears.
>
> The below patch resolves the panic and all bpf tunnel tests pass
> without incident.
>
> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
>
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
> net/ipv4/ip_tunnel.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index 893f013..5dcf50c 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -515,9 +515,10 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
> mtu = dst_mtu(&rt->dst) - dev->hard_header_len
> - sizeof(struct iphdr) - tunnel_hlen;
> else
> - mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
> + mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu;
>
> - skb_dst_update_pmtu(skb, mtu);
> + if (skb_valid_dst(skb))
> + skb_dst_update_pmtu(skb, mtu);
>
> if (skb->protocol == htons(ETH_P_IP)) {
> if (!skb_is_gso(skb) &&
> @@ -530,9 +531,11 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
> }
> #if IS_ENABLED(CONFIG_IPV6)
> else if (skb->protocol == htons(ETH_P_IPV6)) {
> - struct rt6_info *rt6 = (struct rt6_info *)skb_dst(skb);
> + struct rt6_info *rt6;
> __be32 daddr;
>
> + rt6 = skb_valid_dst(skb) ? (struct rt6_info *)skb_dst(skb) :
> + NULL;
> daddr = md ? dst : tunnel->parms.iph.daddr;
>
> if (rt6 && mtu < dst_mtu(skb_dst(skb)) &&
Acked-by: wenxu@ucloud.cn
^ permalink raw reply
* Re: [PATCH net-next] ip_tunnel: Fix DST_METADATA dst_entry handle in tnl_update_pmtu
From: wenxu @ 2019-02-17 3:45 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, rong.a.chen, Network Development,
Stephen Rothwell, LKP
In-Reply-To: <41cd7ba4-7e87-3a3e-ad77-6caf0b46cbd1@ucloud.cn>
On 2019/2/17 上午11:35, wenxu wrote:
> On 2019/2/17 上午12:34, Alexei Starovoitov wrote:
>> On Sat, Feb 16, 2019 at 2:11 AM <wenxu@ucloud.cn> wrote:
>>> From: wenxu <wenxu@ucloud.cn>
>>>
>>> BUG report in selftests: bpf: test_tunnel.sh
>>>
>>> Testing IPIP tunnel...
>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
>>> PGD 0 P4D 0
>>> Oops: 0010 [#1] SMP PTI
>>> CPU: 0 PID: 16822 Comm: ping Not tainted 5.0.0-rc3-00352-gc8b34e6 #1
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
>>> RIP: 0010: (null)
>>> Code: Bad RIP value.
>>> RSP: 0018:ffffc9000104f9c8 EFLAGS: 00010286
>>> RAX: 0000000000000000 RBX: ffffe8ffffc071a8 RCX: 0000000000000000
>>> RDX: ffff888054e33000 RSI: ffff88807796f500 RDI: ffffe8ffffc07130
>>> RBP: ffff88807796f500 R08: ffff88806da4f0a0 R09: 0000000000000000
>>> R10: 0000000000000004 R11: ffff888054e33000 R12: 0000000000000054
>>> R13: ffff88805e714000 R14: ffff88806da4f0a0 R15: 0000000000000000
>>> FS: 00007f4c00431500(0000) GS:ffff88813fc00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: ffffffffffffffd6 CR3: 000000008276e000 CR4: 00000000000406f0
>>> Call Trace:
>>> ? tnl_update_pmtu+0x21b/0x250 [ip_tunnel]
>>> ? ip_md_tunnel_xmit+0x1b7/0xdc0 [ip_tunnel]
>>> ? ipip_tunnel_xmit+0x90/0xc0 [ipip]
>>> ? dev_hard_start_xmit+0x98/0x210
>>> ? __dev_queue_xmit+0x6a9/0x8e0
>>>
>>> The bpf program set tunnel_key through bpf_skb_set_tunnel_key which will
>>> drop the old dst_entry and create a DST_METADATA dst_entry. It will lead
>>> the tunnel_update_pmtu operator the dst_entry incorrect. So It should be
>>> check the dst_entry is valid.
>>>
>>> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
>>> Signed-off-by: wenxu <wenxu@ucloud.cn>
>> different fix for this issue was sent earlier:
>> https://patchwork.ozlabs.org/patch/1042687/
>> I think it's more complete than this one.
>>
> sorry for didn't saw the patch before. But I think the patch I provide more simpler and also complete for fix this problem
>
>
>
sorry for skip this patch. Thx！
^ permalink raw reply
* pull-request: bpf-next 2019-02-16
From: Alexei Starovoitov @ 2019-02-17 3:42 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, kernel-team
Hi David,
The following pull-request contains BPF updates for your *net-next* tree.
The main changes are:
1) numerous libbpf API improvements, from Andrii, Andrey, Yonghong.
2) test all bpf progs in alu32 mode, from Jiong.
3) skb->sk access and bpf_sk_fullsock(), bpf_tcp_sock() helpers, from Martin.
4) support for IP encap in lwt bpf progs, from Peter.
5) remove XDP_QUERY_XSK_UMEM dead code, from Jan.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 71bd106d2567675668e253cba3960e3c4bf2e80e:
net: fixed-phy: Add fixed_phy_register_with_gpiod() API (2019-02-07 18:11:58 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
for you to fetch changes up to 5aab392c55c96f9bb26d9294f965f156a87ee81c:
tools/libbpf: support bigger BTF data sizes (2019-02-16 18:47:18 -0800)
----------------------------------------------------------------
Alexei Starovoitov (5):
Merge branch 'btf-api-extensions'
Merge branch 'skb_sk-sk_fullsock-tcp_sock'
Merge branch 'bpf-prog-build'
Merge branch 'lwt_encap_ip'
Merge branch 'libbpf-cleanup'
Andrey Ignatov (2):
libbpf: Introduce bpf_map__resize
libbpf: Introduce bpf_object__btf
Andrii Nakryiko (8):
tools/bpf: add missing strings.h include
btf: separate btf creation and loading
btf: expose API to work with raw btf data
btf: expose API to work with raw btf_ext data
tools/bpf: remove btf__get_strings() superseded by raw data API
tools/bpf: replace bzero with memset
tools: sync uapi/linux/if_link.h header
tools/libbpf: support bigger BTF data sizes
Jakub Kicinski (1):
bpf: offload: add priv field for drivers
Jan Sokolowski (1):
net: bpf: remove XDP_QUERY_XSK_UMEM enumerator
Jiong Wang (4):
selftests: bpf: add "alu32" to .gitignore
selftests: bpf: extend sub-register mode compilation to all bpf object files
selftests: bpf: centre kernel bpf objects under new subdir "progs"
selftests: bpf: relax sub-register mode compilation criteria
Martin KaFai Lau (8):
bpf: Fix narrow load on a bpf_sock returned from sk_lookup()
bpf: Add a bpf_sock pointer to __sk_buff and a bpf_sk_fullsock helper
bpf: Add state, dst_ip4, dst_ip6 and dst_port to bpf_sock
bpf: Refactor sock_ops_convert_ctx_access
bpf: Add struct bpf_tcp_sock and BPF_FUNC_tcp_sock
bpf: Sync bpf.h to tools/
bpf: Add skb->sk, bpf_sk_fullsock and bpf_tcp_sock tests to test_verifer
bpf: Add test_sock_fields for skb->sk and bpf_tcp_sock
Peter Oskolkov (10):
bpf: add plumbing for BPF_LWT_ENCAP_IP in bpf_lwt_push_encap
bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap
bpf: handle GSO in bpf_lwt_push_encap
ipv6_stub: add ipv6_route_input stub/proxy.
bpf: add handling of BPF_LWT_REROUTE to lwt_bpf.c
bpf: sync <kdir>/include/.../bpf.h with tools/include/.../bpf.h
selftests: bpf: add test_lwt_ip_encap selftest
bpf: fix memory leak in bpf_lwt_xmit_reroute
bpf: make LWTUNNEL_BPF dependent on INET
selftests: bpf: test_lwt_ip_encap: add negative tests.
Prashant Bhole (1):
tools: bpftool: doc, add text about feature-subcommand
Yonghong Song (1):
tools/bpf: add log_level to bpf_load_program_attr
drivers/net/ethernet/intel/i40e/i40e_main.c | 3 -
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 28 --
drivers/net/ethernet/intel/i40e/i40e_xsk.h | 2 -
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 -
.../net/ethernet/intel/ixgbe/ixgbe_txrx_common.h | 2 -
drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 17 -
drivers/net/ethernet/netronome/nfp/bpf/main.c | 2 +-
drivers/net/ethernet/netronome/nfp/bpf/offload.c | 4 +-
drivers/net/netdevsim/bpf.c | 5 +-
include/linux/bpf.h | 45 +-
include/linux/netdevice.h | 7 +-
include/net/addrconf.h | 1 +
include/net/lwtunnel.h | 2 +
include/uapi/linux/bpf.h | 98 +++-
kernel/bpf/offload.c | 10 +-
kernel/bpf/verifier.c | 168 +++++--
net/Kconfig | 2 +-
net/core/filter.c | 544 ++++++++++++++-------
net/core/lwt_bpf.c | 265 +++++++++-
net/ipv6/addrconf_core.c | 6 +
net/ipv6/af_inet6.c | 7 +
tools/bpf/bpftool/Documentation/bpftool.rst | 4 +-
tools/include/uapi/linux/bpf.h | 98 +++-
tools/include/uapi/linux/if_link.h | 1 +
tools/lib/bpf/bpf.c | 69 +--
tools/lib/bpf/bpf.h | 1 +
tools/lib/bpf/btf.c | 182 +++----
tools/lib/bpf/btf.h | 6 +-
tools/lib/bpf/libbpf.c | 25 +-
tools/lib/bpf/libbpf.h | 4 +
tools/lib/bpf/libbpf.map | 6 +-
tools/testing/selftests/bpf/.gitignore | 1 +
tools/testing/selftests/bpf/Makefile | 52 +-
tools/testing/selftests/bpf/bpf_helpers.h | 4 +
tools/testing/selftests/bpf/bpf_util.h | 9 +
tools/testing/selftests/bpf/{ => progs}/bpf_flow.c | 0
.../selftests/bpf/{ => progs}/connect4_prog.c | 0
.../selftests/bpf/{ => progs}/connect6_prog.c | 0
.../testing/selftests/bpf/{ => progs}/dev_cgroup.c | 0
.../selftests/bpf/{ => progs}/get_cgroup_id_kern.c | 0
.../selftests/bpf/{ => progs}/netcnt_prog.c | 0
.../selftests/bpf/{ => progs}/sample_map_ret0.c | 0
.../selftests/bpf/{ => progs}/sample_ret0.c | 0
.../selftests/bpf/{ => progs}/sendmsg4_prog.c | 0
.../selftests/bpf/{ => progs}/sendmsg6_prog.c | 0
.../selftests/bpf/{ => progs}/socket_cookie_prog.c | 0
.../selftests/bpf/{ => progs}/sockmap_parse_prog.c | 0
.../bpf/{ => progs}/sockmap_tcp_msg_prog.c | 0
.../bpf/{ => progs}/sockmap_verdict_prog.c | 0
.../selftests/bpf/{ => progs}/test_adjust_tail.c | 0
.../selftests/bpf/{ => progs}/test_btf_haskv.c | 0
.../selftests/bpf/{ => progs}/test_btf_nokv.c | 0
.../bpf/{ => progs}/test_get_stack_rawtp.c | 0
.../testing/selftests/bpf/{ => progs}/test_l4lb.c | 0
.../selftests/bpf/{ => progs}/test_l4lb_noinline.c | 0
.../bpf/{ => progs}/test_lirc_mode2_kern.c | 0
.../selftests/bpf/progs/test_lwt_ip_encap.c | 85 ++++
.../selftests/bpf/{ => progs}/test_lwt_seg6local.c | 0
.../selftests/bpf/{ => progs}/test_map_in_map.c | 0
.../selftests/bpf/{ => progs}/test_map_lock.c | 0
.../selftests/bpf/{ => progs}/test_obj_id.c | 0
.../selftests/bpf/{ => progs}/test_pkt_access.c | 0
.../selftests/bpf/{ => progs}/test_pkt_md_access.c | 0
.../selftests/bpf/{ => progs}/test_queue_map.c | 0
.../bpf/{ => progs}/test_select_reuseport_kern.c | 0
.../bpf/{ => progs}/test_sk_lookup_kern.c | 0
.../bpf/{ => progs}/test_skb_cgroup_id_kern.c | 0
.../selftests/bpf/progs/test_sock_fields_kern.c | 152 ++++++
.../selftests/bpf/{ => progs}/test_sockhash_kern.c | 0
.../selftests/bpf/{ => progs}/test_sockmap_kern.c | 0
.../selftests/bpf/{ => progs}/test_spin_lock.c | 0
.../selftests/bpf/{ => progs}/test_stack_map.c | 0
.../bpf/{ => progs}/test_stacktrace_build_id.c | 0
.../bpf/{ => progs}/test_stacktrace_map.c | 0
.../selftests/bpf/{ => progs}/test_tcp_estats.c | 0
.../selftests/bpf/{ => progs}/test_tcpbpf_kern.c | 0
.../bpf/{ => progs}/test_tcpnotify_kern.c | 0
.../selftests/bpf/{ => progs}/test_tracepoint.c | 0
.../selftests/bpf/{ => progs}/test_tunnel_kern.c | 0
tools/testing/selftests/bpf/{ => progs}/test_xdp.c | 0
.../selftests/bpf/{ => progs}/test_xdp_meta.c | 0
.../selftests/bpf/{ => progs}/test_xdp_noinline.c | 0
.../selftests/bpf/{ => progs}/test_xdp_redirect.c | 0
.../selftests/bpf/{ => progs}/test_xdp_vlan.c | 0
.../testing/selftests/bpf/{ => progs}/xdp_dummy.c | 0
tools/testing/selftests/bpf/test_btf.c | 39 +-
tools/testing/selftests/bpf/test_lwt_ip_encap.sh | 376 ++++++++++++++
tools/testing/selftests/bpf/test_sock.c | 9 +-
tools/testing/selftests/bpf/test_sock_fields.c | 327 +++++++++++++
.../testing/selftests/bpf/verifier/ref_tracking.c | 4 +-
tools/testing/selftests/bpf/verifier/sock.c | 384 +++++++++++++++
tools/testing/selftests/bpf/verifier/unpriv.c | 2 +-
92 files changed, 2576 insertions(+), 485 deletions(-)
rename tools/testing/selftests/bpf/{ => progs}/bpf_flow.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/connect4_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/connect6_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/dev_cgroup.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/get_cgroup_id_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/netcnt_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sample_map_ret0.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sample_ret0.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sendmsg4_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sendmsg6_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/socket_cookie_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sockmap_parse_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sockmap_tcp_msg_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/sockmap_verdict_prog.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_adjust_tail.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_btf_haskv.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_btf_nokv.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_get_stack_rawtp.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_l4lb.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_l4lb_noinline.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_lirc_mode2_kern.c (100%)
create mode 100644 tools/testing/selftests/bpf/progs/test_lwt_ip_encap.c
rename tools/testing/selftests/bpf/{ => progs}/test_lwt_seg6local.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_map_in_map.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_map_lock.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_obj_id.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_pkt_access.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_pkt_md_access.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_queue_map.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_select_reuseport_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_sk_lookup_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_skb_cgroup_id_kern.c (100%)
create mode 100644 tools/testing/selftests/bpf/progs/test_sock_fields_kern.c
rename tools/testing/selftests/bpf/{ => progs}/test_sockhash_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_sockmap_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_spin_lock.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_stack_map.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_stacktrace_build_id.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_stacktrace_map.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_tcp_estats.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_tcpbpf_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_tcpnotify_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_tracepoint.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_tunnel_kern.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_xdp.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_xdp_meta.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_xdp_noinline.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_xdp_redirect.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/test_xdp_vlan.c (100%)
rename tools/testing/selftests/bpf/{ => progs}/xdp_dummy.c (100%)
create mode 100755 tools/testing/selftests/bpf/test_lwt_ip_encap.sh
create mode 100644 tools/testing/selftests/bpf/test_sock_fields.c
create mode 100644 tools/testing/selftests/bpf/verifier/sock.c
^ permalink raw reply
* Re: [PATCH net-next] ip_tunnel: Fix DST_METADATA dst_entry handle in tnl_update_pmtu
From: wenxu @ 2019-02-17 3:35 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David S. Miller, rong.a.chen, Network Development,
Stephen Rothwell, LKP
In-Reply-To: <CAADnVQLnjFREuRCO2+fDzgiiGd3tbR3924NV7tAinoQbmdHL-g@mail.gmail.com>
On 2019/2/17 上午12:34, Alexei Starovoitov wrote:
> On Sat, Feb 16, 2019 at 2:11 AM <wenxu@ucloud.cn> wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> BUG report in selftests: bpf: test_tunnel.sh
>>
>> Testing IPIP tunnel...
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
>> PGD 0 P4D 0
>> Oops: 0010 [#1] SMP PTI
>> CPU: 0 PID: 16822 Comm: ping Not tainted 5.0.0-rc3-00352-gc8b34e6 #1
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
>> RIP: 0010: (null)
>> Code: Bad RIP value.
>> RSP: 0018:ffffc9000104f9c8 EFLAGS: 00010286
>> RAX: 0000000000000000 RBX: ffffe8ffffc071a8 RCX: 0000000000000000
>> RDX: ffff888054e33000 RSI: ffff88807796f500 RDI: ffffe8ffffc07130
>> RBP: ffff88807796f500 R08: ffff88806da4f0a0 R09: 0000000000000000
>> R10: 0000000000000004 R11: ffff888054e33000 R12: 0000000000000054
>> R13: ffff88805e714000 R14: ffff88806da4f0a0 R15: 0000000000000000
>> FS: 00007f4c00431500(0000) GS:ffff88813fc00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: ffffffffffffffd6 CR3: 000000008276e000 CR4: 00000000000406f0
>> Call Trace:
>> ? tnl_update_pmtu+0x21b/0x250 [ip_tunnel]
>> ? ip_md_tunnel_xmit+0x1b7/0xdc0 [ip_tunnel]
>> ? ipip_tunnel_xmit+0x90/0xc0 [ipip]
>> ? dev_hard_start_xmit+0x98/0x210
>> ? __dev_queue_xmit+0x6a9/0x8e0
>>
>> The bpf program set tunnel_key through bpf_skb_set_tunnel_key which will
>> drop the old dst_entry and create a DST_METADATA dst_entry. It will lead
>> the tunnel_update_pmtu operator the dst_entry incorrect. So It should be
>> check the dst_entry is valid.
>>
>> Fixes: c8b34e680a09 ("ip_tunnel: Add tnl_update_pmtu in ip_md_tunnel_xmit")
>> Signed-off-by: wenxu <wenxu@ucloud.cn>
> different fix for this issue was sent earlier:
> https://patchwork.ozlabs.org/patch/1042687/
> I think it's more complete than this one.
>
sorry for didn't saw the patch before. But I think the patch I provide more simpler and also complete for fix this problem
^ permalink raw reply
* pull-request: bpf 2019-02-16
From: Alexei Starovoitov @ 2019-02-17 3:14 UTC (permalink / raw)
To: davem; +Cc: daniel, netdev, kernel-team
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) fix lockdep false positive in bpf_get_stackid(), from Alexei.
2) several AF_XDP fixes, from Bjorn, Magnus, Davidlohr.
3) fix narrow load from struct bpf_sock, from Martin.
4) mips JIT fixes, from Paul.
5) gso handling fix in bpf helpers, from Willem.
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 ccc8ca9b90acb45a3309f922b2591b07b4e070ec:
net/smc: fix byte_order for rx_curs_confirmed (2019-02-08 22:33:25 -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 1910faebf61d85a5b7138c0c1c600672e41f82a3:
MIPS: eBPF: Remove REG_32BIT_ZERO_EX (2019-02-16 01:10:06 +0100)
----------------------------------------------------------------
Alexei Starovoitov (1):
bpf: fix lockdep false positive in stackmap
Björn Töpel (1):
xsk: do not remove umem from netdevice on fall-back to copy-mode
Davidlohr Bueso (1):
xsk: share the mmap_sem for page pinning
Magnus Karlsson (1):
xsk: add missing smp_rmb() in xsk_mmap
Martin KaFai Lau (1):
bpf: Fix narrow load on a bpf_sock returned from sk_lookup()
Paul Burton (2):
MIPS: eBPF: Always return sign extended 32b values
MIPS: eBPF: Remove REG_32BIT_ZERO_EX
Willem de Bruijn (1):
bpf: only adjust gso_size on bytestream protocols
arch/mips/net/ebpf_jit.c | 24 ++++++++++++------------
include/linux/skbuff.h | 6 ++++++
kernel/bpf/stackmap.c | 8 +++++++-
kernel/bpf/verifier.c | 11 +++++++----
net/core/filter.c | 12 ++++--------
net/xdp/xdp_umem.c | 11 ++++++-----
net/xdp/xsk.c | 4 ++++
7 files changed, 46 insertions(+), 30 deletions(-)
^ permalink raw reply
* Re: [PATCH RFC] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Florian Fainelli @ 2019-02-17 3:05 UTC (permalink / raw)
To: Nikolay Aleksandrov, netdev
Cc: roopa, wkok, anuradhak, bridge, linus.luessing, davem, stephen
In-Reply-To: <20190215130427.29824-1-nikolay@cumulusnetworks.com>
On 2/15/2019 5:04 AM, Nikolay Aleksandrov wrote:
> The behaviour since b00589af3b04 ("bridge: disable snooping if there is
> no querier") is wrong, we shouldn't be flooding multicast traffic when
> there is an mdb entry and we know where it should be forwarded to when
> multicast snooping is enabled. This patch changes the behaviour to not
> flood known unicast traffic.
You mean multicast traffic in the last part of the sentence, right?
> I'll give two obviously broken cases:
> - most obvious: static mdb created by the user with snooping enabled
> - user-space daemon controlling the mdb table (e.g. MLAG)
>
> Every user would expect to have traffic forwarded only to the configured
> mdb destination when snooping is enabled, instead now to get that one
> needs to enable both snooping and querier. Enabling querier on all
> switches could be problematic and is not a good solution, for example
> as summarized by our multicast experts:
> "every switch would send an IGMP query for any random multicast traffic it
> received across the entire domain and it would send it forever as long as a
> host exists wanting that stream even if it has no downstream/directly
> connected receivers"
>
> Sending as an RFC to get the discussion going, but I'm strongly for
> removing this behaviour and would like to send this patch officially.
>
> We could make this behaviour possible via a knob if necessary, but
> it really should not be the default.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
> ---
> net/bridge/br_device.c | 3 +--
> net/bridge/br_input.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
> index 013323b6dbe4..2aa8a6509924 100644
> --- a/net/bridge/br_device.c
> +++ b/net/bridge/br_device.c
> @@ -96,8 +96,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
> }
>
> mdst = br_mdb_get(br, skb, vid);
> - if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) &&
> - br_multicast_querier_exists(br, eth_hdr(skb)))
> + if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb))
> br_multicast_flood(mdst, skb, false, true);
> else
> br_flood(br, skb, BR_PKT_MULTICAST, false, true);
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index 5ea7e56119c1..aae78095cf67 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -136,8 +136,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
> switch (pkt_type) {
> case BR_PKT_MULTICAST:
> mdst = br_mdb_get(br, skb, vid);
> - if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) &&
> - br_multicast_querier_exists(br, eth_hdr(skb))) {
> + if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) {
> if ((mdst && mdst->host_joined) ||
> br_multicast_is_router(br)) {
> local_rcv = true;
>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next] tools/libbpf: support bigger BTF data sizes
From: Alexei Starovoitov @ 2019-02-17 2:51 UTC (permalink / raw)
To: Andrii Nakryiko
Cc: andrii.nakryiko, netdev, bpf, kernel-team, yhs, ast, kafai,
daniel, acme
In-Reply-To: <20190216035218.342185-1-andriin@fb.com>
On Fri, Feb 15, 2019 at 07:52:18PM -0800, Andrii Nakryiko wrote:
> While it's understandable why kernel limits number of BTF types to 65535
> and size of string section to 64KB, in libbpf as user-space library it's
> too restrictive. E.g., pahole converting DWARF to BTF type information
> for Linux kernel generates more than 3 million BTF types and more than
> 3MB of strings, before deduplication. So to allow btf__dedup() to do its
> work, we need to be able to load bigger BTF sections using btf__new().
>
> Singed-off-by: Andrii Nakryiko <andriin@fb.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: phy: marvell10g: check for newly set aneg in mv3310_config_aneg
From: Florian Fainelli @ 2019-02-17 2:49 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <249c09b1-e4b2-6d72-b0cc-018fef336a4b@gmail.com>
On 2/16/2019 11:53 AM, Heiner Kallweit wrote:
> Even if the advertisement registers content didn't change, we may have
> just switched to aneg, and therefore have to trigger an aneg restart.
> This matches the behavior of genphy_config_aneg().
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 3/4] net: phy: marvell10g: use genphy_c45_an_config_an
From: Florian Fainelli @ 2019-02-17 2:47 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <2ad2dd35-45f5-9720-d2ae-0ee104a7d782@gmail.com>
On 2/16/2019 11:52 AM, Heiner Kallweit wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Use new function genphy_c45_config_aneg() in mv3310_config_aneg().
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> [hkallweit1@gmail.com: patch splitted]
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/marvell10g.c | 22 +---------------------
> 1 file changed, 1 insertion(+), 21 deletions(-)
>
> diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
> index 4a6ae63ab..03fa50087 100644
> --- a/drivers/net/phy/marvell10g.c
> +++ b/drivers/net/phy/marvell10g.c
> @@ -274,13 +274,7 @@ static int mv3310_config_aneg(struct phy_device *phydev)
> if (phydev->autoneg == AUTONEG_DISABLE)
> return genphy_c45_pma_setup_forced(phydev);
>
> - linkmode_and(phydev->advertising, phydev->advertising,
> - phydev->supported);
> -
> - ret = phy_modify_mmd_changed(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
> - ADVERTISE_ALL | ADVERTISE_100BASE4 |
> - ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
> - linkmode_adv_to_mii_adv_t(phydev->advertising));
> + ret = genphy_c45_an_config_an(phydev);
> if (ret < 0)
> return ret;
> if (ret > 0)
> @@ -294,20 +288,6 @@ static int mv3310_config_aneg(struct phy_device *phydev)
> if (ret > 0)
> changed = true;
>
> - /* 10G control register */
> - if (linkmode_test_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT,
> - phydev->advertising))
> - reg = MDIO_AN_10GBT_CTRL_ADV10G;
> - else
> - reg = 0;
This is not strictly equivalent though because marvell10g only checks
for the 10000baseT_Full bit set whereas genphy_c45_an_config_an() calls
linkmode_adv_to_mii_10gbt_adv_t() which you recently updated to also
check for 2.5G and 5G. This sounds about the right decision, but I
wonder if Russell did this for a reason (like not able to test 2500baseT
and 5000baseT?)
> -
> - ret = phy_modify_mmd_changed(phydev, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
> - MDIO_AN_10GBT_CTRL_ADV10G, reg);
> - if (ret < 0)
> - return ret;
> - if (ret > 0)
> - changed = true;
> -
> if (changed)
> ret = genphy_c45_restart_aneg(phydev);
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next] selftests: bpf: test_lwt_ip_encap: add negative tests.
From: Alexei Starovoitov @ 2019-02-17 2:46 UTC (permalink / raw)
To: David Ahern
Cc: Peter Oskolkov, Alexei Starovoitov, Daniel Borkmann, netdev,
Peter Oskolkov
In-Reply-To: <b8a76f3d-93e8-1287-05e0-a671a3991cbe@gmail.com>
On Sat, Feb 16, 2019 at 04:13:12PM -0700, David Ahern wrote:
> On 2/15/19 4:49 PM, Peter Oskolkov wrote:
> > @@ -178,7 +205,7 @@ set -e # exit on error
> > # configure IPv4 GRE device in NS3, and a route to it via the "bottom" route
> > ip -netns ${NS3} tunnel add gre_dev mode gre remote ${IPv4_1} local ${IPv4_GRE} ttl 255
> > ip -netns ${NS3} link set gre_dev up
> > - ip -netns ${NS3} addr add ${IPv4_GRE} dev gre_dev
> > + ip -netns ${NS3} addr add ${IPv4_GRE} nodad dev gre_dev
>
> nodad is only effective for IPv6.
>
> other than that LGTM. Thanks for the update.
>
> Reviewed-by: David Ahern <dsahern@gmail.com>
Applied as-is.
Pls send a follow up if you feel strongly about it.
Thanks
^ permalink raw reply
* Re: [PATCH net-next 2/4] net: phy: add genphy_c45_an_config_an
From: Florian Fainelli @ 2019-02-17 2:44 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <a5b17bc8-1aab-053b-dee8-c412215a70c8@gmail.com>
On 2/16/2019 11:51 AM, Heiner Kallweit wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> C45 configuration of 10/100 and multi-giga bit auto negotiation
> advertisement is standardized. Configuration of 1000Base-T however
> appears to be vendor specific. Move the generic code out of the
> Marvell driver into the common phy-c45.c file.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> [hkallweit1@gmail.com: use new helper linkmode_adv_to_mii_10gbt_adv_t and split patch]
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy-c45.c | 44 +++++++++++++++++++++++++++++++++++++++
> include/linux/phy.h | 1 +
> 2 files changed, 45 insertions(+)
>
> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
> index 0374c50b1..bea1b0c6e 100644
> --- a/drivers/net/phy/phy-c45.c
> +++ b/drivers/net/phy/phy-c45.c
> @@ -78,6 +78,50 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
> }
> EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
>
> +/**
> + * genphy_c45_an_config_an - configure advertisement registers
Nit: are not the two "an" redundant" here? Unless the first one means
something different in which case naming this:
genphy_c45_an_config_aneg() would be clearer?
> + * @phydev: target phy_device struct
> + *
> + * Configure advertisement registers based on modes set in phydev->advertising
> + *
> + * Returns negative errno code on failure, 0 if advertisement didn't change,
> + * or 1 if advertised modes changed.
> + */
> +int genphy_c45_an_config_an(struct phy_device *phydev)
> +{
> + int changed = 0, ret;
> + u32 adv;
> +
> + linkmode_and(phydev->advertising, phydev->advertising,
> + phydev->supported);
> +
> + adv = linkmode_adv_to_mii_adv_t(phydev->advertising);
> +
> + ret = phy_modify_mmd(phydev, MDIO_MMD_AN, MDIO_AN_ADVERTISE,
> + ADVERTISE_ALL | ADVERTISE_100BASE4 |
> + ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM,
> + adv);
> + if (ret < 0)
> + return ret;
> + if (ret > 0)
> + changed = 1;
'changed' is essentially a short hand for 'ret >= 0' given it is
initialized to 0 by default and only assigned 1 if 'ret > 0', and since
you do early returns in case 'ret < 0', you might as well drop 'changed'
entirely?
Other than that and the naming:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: phy: add helper linkmode_adv_to_mii_10gbt_adv_t
From: Florian Fainelli @ 2019-02-17 2:38 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <789f6af7-47a2-1c8c-0c4c-d1f49524e08f@gmail.com>
On 2/16/2019 11:50 AM, Heiner Kallweit wrote:
> Add a helper linkmode_adv_to_mii_10gbt_adv_t(), similar to
> linkmode_adv_to_mii_adv_t.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v2 net-next 2/2] net: phy: marvell10g: improve mv3310_config_aneg
From: Florian Fainelli @ 2019-02-17 2:37 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <6827daf4-3ee0-c537-2b97-493bcc2a48ab@gmail.com>
On 2/16/2019 11:44 AM, Heiner Kallweit wrote:
> Now that genphy_c45_pma_setup_forced() makes sure the "aneg enabled"
> bit is cleared, the call to genphy_c45_an_disable_aneg() isn't needed
> any longer. And the code pattern is now the same as in
> genphy_config_aneg().
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Florian Fainelli @ 2019-02-17 2:37 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller,
Russell King - ARM Linux
Cc: netdev@vger.kernel.org
In-Reply-To: <0ac9be2a-ce73-8938-f25b-6dd1a169a1a7@gmail.com>
On 2/16/2019 11:44 AM, Heiner Kallweit wrote:
> When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
> still be set, therefore clear it. This is also in line with what
> genphy_setup_forced() does for Clause 22.
>
> v2:
> - fix typo
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: phy: use mii_10gbt_stat_mod_linkmode_lpa_t in genphy_c45_read_lpa
From: Florian Fainelli @ 2019-02-17 2:35 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <05e7f5fd-5783-f576-b164-2a64239ff6d7@gmail.com>
On 2/16/2019 8:26 AM, Heiner Kallweit wrote:
> Use mii_10gbt_stat_mod_linkmode_lpa_t() in genphy_c45_read_lpa() to
> simplify the code.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] net: phy: add helper mii_10gbt_stat_mod_linkmode_lpa_t
From: Florian Fainelli @ 2019-02-17 2:35 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <ebde74fb-2d0e-365c-f04c-288ce6d60368@gmail.com>
On 2/16/2019 8:26 AM, Heiner Kallweit wrote:
> Similar to the existing helpers for the Clause 22 registers add helper
> mii_10gbt_stat_mod_linkmode_lpa_t.
>
> Note that this helper is defined in linux/mdio.h, not like the
> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
> includes linux/mii.h before defining the C45 register constants.
Nit: this also processes 2.5G and 5G but I can't suggest a better name,
so this is as good as any.
>
> v2:
> - remove helpers that don't have users in this series
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [net-next, PATCH v2] net: stmmac: use correct define to get rx timestamp on GMAC4
From: David Miller @ 2019-02-17 2:15 UTC (permalink / raw)
To: alexandre.torgue
Cc: peppe.cavallaro, joabreu, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <1550160224-8927-1-git-send-email-alexandre.torgue@st.com>
From: Alexandre Torgue <alexandre.torgue@st.com>
Date: Thu, 14 Feb 2019 17:03:44 +0100
> In dwmac4_wrback_get_rx_timestamp_status we looking for a RX timestamp.
> For that receive descriptors are handled and so we should use defines
> related to receive descriptors. It'll no change the functional behavior
> as RDES3_RDES1_VALID=TDES3_RS1V=BIT(26) but it makes code easier to read.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net/tls: Move protocol constants from cipher context to tls context
From: David Miller @ 2019-02-17 2:14 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson, doronrk
In-Reply-To: <20190214070913.14647-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Thu, 14 Feb 2019 07:11:35 +0000
> Each tls context maintains two cipher contexts (one each for tx and rx
> directions). For each tls session, the constants such as protocol
> version, ciphersuite, iv size, associated data size etc are same for
> both the directions and need to be stored only once per tls context.
> Hence these are moved from 'struct cipher_context' to 'struct
> tls_prot_info' and stored only once in 'struct tls_context'.
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: clean up vcc_seq_next()
From: David Miller @ 2019-02-17 2:14 UTC (permalink / raw)
To: dan.carpenter; +Cc: joe, netdev, kernel-janitors
In-Reply-To: <20190214065635.GA21768@kadam>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu, 14 Feb 2019 09:56:35 +0300
> It's confusing to call PTR_ERR(v). The PTR_ERR() function is basically
> a fancy cast to long so it makes you wonder, was IS_ERR() intended? But
> that doesn't make sense because vcc_walk() doesn't return error
> pointers.
>
> This patch doesn't affect runtime, it's just a cleanup.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sock: consistent handling of extreme SO_SNDBUF/SO_RCVBUF values
From: David Miller @ 2019-02-17 2:10 UTC (permalink / raw)
To: gnault; +Cc: netdev, linux-api, edumazet, mleitner, pabeni
In-Reply-To: <2cb69b6987b6e23f8b8c1aa8dc524efa6bd53191.1550026643.git.gnault@redhat.com>
From: Guillaume Nault <gnault@redhat.com>
Date: Wed, 13 Feb 2019 04:30:34 +0100
> SO_SNDBUF and SO_RCVBUF (and their *BUFFORCE version) may overflow or
> underflow their input value. This patch aims at providing explicit
> handling of these extreme cases, to get a clear behaviour even with
> values bigger than INT_MAX / 2 or lower than INT_MIN / 2.
...
> Signed-off-by: Guillaume Nault <gnault@redhat.com>
Thank you so much for writing such a detailed commit message.
Applied.
^ permalink raw reply
* Re: [PATCH bpf-next] selftests: bpf: test_lwt_ip_encap: add negative tests.
From: David Ahern @ 2019-02-16 23:13 UTC (permalink / raw)
To: Peter Oskolkov, Alexei Starovoitov, Daniel Borkmann, netdev
Cc: Peter Oskolkov
In-Reply-To: <20190215234933.208398-1-posk@google.com>
On 2/15/19 4:49 PM, Peter Oskolkov wrote:
> @@ -178,7 +205,7 @@ set -e # exit on error
> # configure IPv4 GRE device in NS3, and a route to it via the "bottom" route
> ip -netns ${NS3} tunnel add gre_dev mode gre remote ${IPv4_1} local ${IPv4_GRE} ttl 255
> ip -netns ${NS3} link set gre_dev up
> - ip -netns ${NS3} addr add ${IPv4_GRE} dev gre_dev
> + ip -netns ${NS3} addr add ${IPv4_GRE} nodad dev gre_dev
nodad is only effective for IPv6.
other than that LGTM. Thanks for the update.
Reviewed-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Heiner Kallweit @ 2019-02-16 22:45 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Andrew Lunn, Florian Fainelli, David Miller,
netdev@vger.kernel.org
In-Reply-To: <20190216224320.kwefivz2kpzqnmqm@shell.armlinux.org.uk>
On 16.02.2019 23:43, Russell King - ARM Linux admin wrote:
> On Sat, Feb 16, 2019 at 08:10:24PM +0100, Heiner Kallweit wrote:
>> When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
>> still be set, therefore clear it. This is also in line with what
>> genphy_setup_forced() does for Clause 22.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy-c45.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
>> index bef126344..0374c50b1 100644
>> --- a/drivers/net/phy/phy-c45.c
>> +++ b/drivers/net/phy/phy-c45.c
>> @@ -71,6 +71,10 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
>> return ret;
>>
>> return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
>> + if (ret < 0)
>
> This patch does not make sense.
>
Right, was a typo. Interestingly the compiler didn't complain.
I sent a v2 already.
>> + return ret;
>> +
>> + return genphy_c45_an_disable_aneg(phydev);
>> }
>> EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
>>
>> --
>> 2.20.1
>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: disable aneg in genphy_c45_pma_setup_forced
From: Russell King - ARM Linux admin @ 2019-02-16 22:43 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Florian Fainelli, David Miller,
netdev@vger.kernel.org
In-Reply-To: <27bb134f-eb4e-e43a-5d9d-2c551a22428c@gmail.com>
On Sat, Feb 16, 2019 at 08:10:24PM +0100, Heiner Kallweit wrote:
> When genphy_c45_pma_setup_forced() is called the "aneg enabled" bit may
> still be set, therefore clear it. This is also in line with what
> genphy_setup_forced() does for Clause 22.
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy-c45.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/phy/phy-c45.c b/drivers/net/phy/phy-c45.c
> index bef126344..0374c50b1 100644
> --- a/drivers/net/phy/phy-c45.c
> +++ b/drivers/net/phy/phy-c45.c
> @@ -71,6 +71,10 @@ int genphy_c45_pma_setup_forced(struct phy_device *phydev)
> return ret;
>
> return phy_write_mmd(phydev, MDIO_MMD_PMAPMD, MDIO_CTRL2, ctrl2);
> + if (ret < 0)
This patch does not make sense.
> + return ret;
> +
> + return genphy_c45_an_disable_aneg(phydev);
> }
> EXPORT_SYMBOL_GPL(genphy_c45_pma_setup_forced);
>
> --
> 2.20.1
>
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* ax25: fix possible use-after-free
From: f6bvp @ 2019-02-16 22:33 UTC (permalink / raw)
To: netdev
Patch applied successfully on Linux draws-f6bvp 4.14.79-v7+ #1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU/Linux
However ax25_route_lock_use and ax25_route_lock_unuse() are not declared and compile failed.
make : on entre dans le répertoire « /usr/src/linux-headers-4.14.79-v7+ »
CC [M] /usr/src/linux-4.14.y/net/ax25/ax25_ip.o
/usr/src/linux-4.14.y/net/ax25/ax25_ip.c: In function ‘ax25_ip_xmit’:
/usr/src/linux-4.14.y/net/ax25/ax25_ip.c:117:2: error: implicit declaration of function ‘ax25_route_lock_use’ [-Werror=implicit-function-declaration]
ax25_route_lock_use();
^~~~~~~~~~~~~~~~~~~
/usr/src/linux-4.14.y/net/ax25/ax25_ip.c:211:2: error: implicit declaration of function ‘ax25_route_lock_unuse’ [-Werror=implicit-function-declaration]
ax25_route_lock_unuse();
^~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:328 : la recette pour la cible « /usr/src/linux-4.14.y/net/ax25/ax25_ip.o » a echouee
make[1]: *** [/usr/src/linux-4.14.y/net/ax25/ax25_ip.o] Erreur 1
Makefile:1527 : la recette pour la cible « _module_/usr/src/linux-4.14.y/net/ax25 » a echouee
make: *** [_module_/usr/src/linux-4.14.y/net/ax25] Erreur 2
make : on quitte le repertoire « /usr/src/linux-headers-4.14.79-v7+ »
Bernard, f6bvp
^ 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