* Re: [PATCH] ath10k: remove redundant pointers 'dev' and 'noa'
From: Kalle Valo @ 2018-07-30 17:54 UTC (permalink / raw)
To: Colin King
Cc: linux-wireless, netdev, kernel-janitors, linux-kernel, ath10k,
David S . Miller
In-Reply-To: <20180709123446.14796-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> Pointers dev and noa are being assigned but are never used hence they
> are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: variable 'dev' set but not used [-Wunused-but-set-variable]
> warning: variable 'noa' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e6712aa1244f ath10k: remove redundant pointers 'dev' and 'noa'
--
https://patchwork.kernel.org/patch/10514521/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [net-next 10/13] net/mlx5e: Add support for XDP_REDIRECT in device-out side
From: Jesper Dangaard Brouer @ 2018-07-30 16:20 UTC (permalink / raw)
To: Tariq Toukan
Cc: Saeed Mahameed, David S. Miller, netdev, Eugenia Emantayev,
brouer, Toke Høiland-Jørgensen
In-Reply-To: <66f0a6c6-eb81-b348-2e1a-1fb8c98f73d7@mellanox.com>
On Mon, 30 Jul 2018 16:09:47 +0300
Tariq Toukan <tariqt@mellanox.com> wrote:
> On 30/07/2018 4:06 PM, Jesper Dangaard Brouer wrote:
> >
> > On Mon, 30 Jul 2018 14:10:21 +0200 Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> >
> >> On Thu, 26 Jul 2018 15:56:44 -0700 Saeed Mahameed <saeedm@mellanox.com> wrote:
> >>
> >>> +int mlx5e_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames,
> >>> + u32 flags)
> >>> +{
> > [...]
> >>> + xdpi.dma_addr = dma_map_single(sq->pdev, xdpf->data, xdpf->len,
> >>> + DMA_TO_DEVICE);
> >>> + if (unlikely(dma_mapping_error(sq->pdev, xdpi.dma_addr))) {
> >>> + drops++;
> >>
> >> I think you are missing a xdp_return_frame_rx_napi(xdpf) here.
> >
> > I see it already got applied... I'll send a fixup later...
> >
>
> Yes it is applied, I can do it myself. Just let me know what you prefer.
I can take care of this. I already have a patch ready. And I'm eager
to test these patches and compare the performance to the results Toke
and I got for the article based on your earlier patches[1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/hawk/net-next-xdp.git/log/?h=xdp_paper01
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] ath5k: remove redundant pointer rf
From: Kalle Valo @ 2018-07-30 17:56 UTC (permalink / raw)
To: Colin King
Cc: Jiri Slaby, Nick Kossifidis, Luis R . Rodriguez, David S . Miller,
linux-wireless, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180709124138.14996-1-colin.king@canonical.com>
Colin King <colin.king@canonical.com> wrote:
> Pointer rf is being assigned but is never used hence it is redundant
> and can be removed.
>
> Cleans up two clang warnings:
> warning: variable 'rf' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e8c38062efc6 ath5k: remove redundant pointer rf
--
https://patchwork.kernel.org/patch/10514529/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] phy: Move "device present" masks earlier in file
From: David Miller @ 2018-07-30 16:23 UTC (permalink / raw)
To: rpjday; +Cc: netdev, andrew, f.fainelli
In-Reply-To: <alpine.LFD.2.21.1807271526270.22062@localhost.localdomain>
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
Date: Fri, 27 Jul 2018 15:32:20 -0400 (EDT)
> Move the "device present" mask bits up immediately after the MMD
> device definitions, since it makes no sense to have them further down
> in the file.
>
> This is purely a cosmetic change for readability.
>
> Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Sorry, but this actually kills readability.
This area of this header file is a series of collections of register
bit definitions. One for each register.
You are moving the device present register definitions out of that
area.
It makes no sense at all.
I'm not applying this, sorry.
^ permalink raw reply
* Re: [PATCH] ath10k: htt_tx: move lock into id_get function
From: Kalle Valo @ 2018-07-30 17:59 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: David S. Miller, ath10k, linux-wireless, netdev, linux-kernel,
Nicholas Mc Guire
In-Reply-To: <1531589900-29220-1-git-send-email-hofrat@osadl.org>
Nicholas Mc Guire <hofrat@osadl.org> wrote:
> This is only code refactoring as all call sites of
> ath10k_htt_tx_alloc_msdu_id() take the same lock it can be moved into the
> id_get function and the assertion dropped.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e82f57c8b970 ath10k: htt_tx: move lock into id_get function
--
https://patchwork.kernel.org/patch/10524837/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] ath10k: htt_tx: move lock into id_get function
From: Kalle Valo @ 2018-07-30 17:59 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: netdev, linux-wireless, linux-kernel, ath10k, Nicholas Mc Guire,
David S. Miller
In-Reply-To: <1531589900-29220-1-git-send-email-hofrat@osadl.org>
Nicholas Mc Guire <hofrat@osadl.org> wrote:
> This is only code refactoring as all call sites of
> ath10k_htt_tx_alloc_msdu_id() take the same lock it can be moved into the
> id_get function and the assertion dropped.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
e82f57c8b970 ath10k: htt_tx: move lock into id_get function
--
https://patchwork.kernel.org/patch/10524837/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2 6/7] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Andrew Lunn @ 2018-07-30 18:04 UTC (permalink / raw)
To: Arun Parameswaran
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <d19bb673-9088-bbee-ce9f-f2a4d8f404bf@broadcom.com>
> > Hi Arun
> >
> > There is a devm_mdiobus_alloc() which could make the cleanup on error
> > simple.
> >
> Should I do this as a separate patch ?
A separate patch is easier to review. And if something breaks, a git
bisect gives you a better idea what actually broke it, if you have
lots of small patches.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v5 3/4] net/tc: introduce TC_ACT_REINSERT.
From: David Miller @ 2018-07-30 16:31 UTC (permalink / raw)
To: jiri
Cc: pabeni, netdev, jhs, xiyou.wangcong, daniel, marcelo.leitner,
eyal.birger
In-Reply-To: <20180730124013.GF2058@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 30 Jul 2018 14:40:13 +0200
> Oh, another nitpick: The changelog should go under "---" line. That way,
> the maintainer does not have to deal with it during apply (git apply
> will cut it out).
I actually like the changelog to be _IN_ the commit message.
It's useful information that helps someone investigating history
in the tree later.
Please do not tell people to pull changelogs out of the commit
message, thank you. I've been telling them to do the exact
opposite.
^ permalink raw reply
* Re: [PATCH net-next v5 0/4] TC: refactor act_mirred packets re-injection
From: David Miller @ 2018-07-30 16:31 UTC (permalink / raw)
To: pabeni
Cc: netdev, jhs, xiyou.wangcong, jiri, daniel, marcelo.leitner,
eyal.birger
In-Reply-To: <cover.1532934532.git.pabeni@redhat.com>
From: Paolo Abeni <pabeni@redhat.com>
Date: Mon, 30 Jul 2018 14:30:41 +0200
> This series is aimed at improving the act_mirred redirect performances.
> Such action is used by OVS to represent TC S/W flows, and it's current largest
> bottle-neck is the need for a skb_clone() for each packet.
>
> The first 2 patches introduce some cleanup and safeguards to allow extending
> tca_result - we will use it to store RCU protected redirect information - and
> introduce a clear separation between user-space accessible tcfa_action
> values and internal values accessible only by the kernel.
> Then a new tcfa_action value is introduced: TC_ACT_REINJECT, similar to
> TC_ACT_REDIRECT, but preserving the mirred semantic. Such value is not
> accessible from user-space.
> The last patch exploits the newly introduced infrastructure in the act_mirred
> action, to avoid a skb_clone, when possible.
>
> Overall this the above gives a ~10% performance improvement in forwarding tput,
> when using the TC S/W datapath.
...
Series applied, thank you.
^ permalink raw reply
* KASAN: use-after-free Read in vhost_transport_send_pkt
From: syzbot @ 2018-07-30 18:15 UTC (permalink / raw)
To: jasowang, kvm, linux-kernel, mst, netdev, stefanha,
syzkaller-bugs, virtualization
Hello,
syzbot found the following crash on:
HEAD commit: acb1872577b3 Linux 4.18-rc7
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14eb932c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=2dc0cd7c2eefb46f
dashboard link: https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+bd391451452fb0b93039@syzkaller.appspotmail.com
netlink: 'syz-executor5': attribute type 2 has an invalid length.
binder: 28577:28588 transaction failed 29189/-22, size 0-0 line 2852
==================================================================
BUG: KASAN: use-after-free in debug_spin_lock_before
kernel/locking/spinlock_debug.c:83 [inline]
BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c0/0x200
kernel/locking/spinlock_debug.c:112
Read of size 4 at addr ffff880194d0ec6c by task syz-executor4/28583
CPU: 1 PID: 28583 Comm: syz-executor4 Not tainted 4.18.0-rc7+ #169
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x1c0/0x200 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x39/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
vhost_transport_send_pkt+0x12e/0x380 drivers/vhost/vsock.c:223
virtio_transport_send_pkt_info+0x31d/0x460
net/vmw_vsock/virtio_transport_common.c:190
virtio_transport_connect+0x17c/0x220
net/vmw_vsock/virtio_transport_common.c:588
vsock_stream_connect+0x4fb/0xfc0 net/vmw_vsock/af_vsock.c:1197
__sys_connect+0x37d/0x4c0 net/socket.c:1673
__do_sys_connect net/socket.c:1684 [inline]
__se_sys_connect net/socket.c:1681 [inline]
__x64_sys_connect+0x73/0xb0 net/socket.c:1681
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x456a09
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa4aee5bc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 00007fa4aee5c6d4 RCX: 0000000000456a09
RDX: 0000000000000010 RSI: 0000000020000200 RDI: 0000000000000016
RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004ca838 R14: 00000000004c25fb R15: 0000000000000000
Allocated by task 28583:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
__do_kmalloc_node mm/slab.c:3682 [inline]
__kmalloc_node+0x47/0x70 mm/slab.c:3689
kmalloc_node include/linux/slab.h:555 [inline]
kvmalloc_node+0xb9/0xf0 mm/util.c:423
kvmalloc include/linux/mm.h:573 [inline]
vhost_vsock_dev_open+0xa2/0x5a0 drivers/vhost/vsock.c:511
misc_open+0x3ca/0x560 drivers/char/misc.c:141
chrdev_open+0x25a/0x770 fs/char_dev.c:417
do_dentry_open+0x818/0xe40 fs/open.c:794
vfs_open+0x139/0x230 fs/open.c:908
do_last fs/namei.c:3399 [inline]
path_openat+0x174a/0x4e10 fs/namei.c:3540
do_filp_open+0x255/0x380 fs/namei.c:3574
do_sys_open+0x584/0x760 fs/open.c:1101
__do_sys_openat fs/open.c:1128 [inline]
__se_sys_openat fs/open.c:1122 [inline]
__x64_sys_openat+0x9d/0x100 fs/open.c:1122
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 28579:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xd9/0x260 mm/slab.c:3813
kvfree+0x61/0x70 mm/util.c:442
vhost_vsock_free drivers/vhost/vsock.c:499 [inline]
vhost_vsock_dev_release+0x4fd/0x750 drivers/vhost/vsock.c:604
__fput+0x355/0x8b0 fs/file_table.c:209
____fput+0x15/0x20 fs/file_table.c:243
task_work_run+0x1ec/0x2a0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:192 [inline]
exit_to_usermode_loop+0x313/0x370 arch/x86/entry/common.c:166
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x6be/0x820 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff880194d05f80
which belongs to the cache kmalloc-65536 of size 65536
The buggy address is located 36076 bytes inside of
65536-byte region [ffff880194d05f80, ffff880194d15f80)
The buggy address belongs to the page:
page:ffffea0006534000 count:1 mapcount:0 mapping:ffff8801dac02500 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea0006599808 ffff8801dac01e48 ffff8801dac02500
raw: 0000000000000000 ffff880194d05f80 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff880194d0eb00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880194d0eb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880194d0ec00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880194d0ec80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880194d0ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH] bpf: verifier: BPF_MOV don't mark dst reg if src == dst
From: Edward Cree @ 2018-07-30 16:40 UTC (permalink / raw)
To: Daniel Borkmann, Arthur Fabre
Cc: Alexei Starovoitov, Alexei Starovoitov, Network Development
In-Reply-To: <64b39825-3f74-15f6-6212-057c96a84999@iogearbox.net>
On 30/07/18 13:03, Daniel Borkmann wrote:
> On 07/30/2018 12:58 PM, Arthur Fabre wrote:
>> The check_alu_op() call handles 32bit and 64bit cases, but then in the
>> 32bit case
>> mark_reg_unknown() is called, discarding all the dst register state.
>> I think this is equivalent to keeping a copy of dst and always marking
>> dst as unknown.
>>
>> I think we could actually always use check_reg_arg() with DST_OP_NO_MARK:
>>
>> In the 32bit case, we call mark_reg_unknown() anyways.
>>
>> In the 64bit case, we copy src to dst, so marking dst as unknown is pointless.
>>
>> For plain BPF, we call __mark_reg_known() anyways.
> For imms this approach would be buggy since we leave a stale reg->off behind
> which is uncleared from previous reg state. So for them the mark_reg_unknown()
> is useful in the sense that it clears all reg state whereas __mark_reg_known()
> might only initialize a subset of it.
I guess the right thing is to change the existing call to DST_OP_NO_MARK,
and then in the "case: R = imm" branch add another check_reg_arg(DST_OP)
(or maybe just a mark_reg_unknown()).
-Ed
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] net/sched: user-space can't set unknown tcfa_action values
From: Paolo Abeni @ 2018-07-30 16:41 UTC (permalink / raw)
To: Jamal Hadi Salim, netdev
Cc: Cong Wang, Jiri Pirko, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger, David S. Miller
In-Reply-To: <f455f493-c106-aa93-b92a-2aa94c969d31@mojatatu.com>
On Mon, 2018-07-30 at 10:03 -0400, Jamal Hadi Salim wrote:
> On 30/07/18 08:30 AM, Paolo Abeni wrote:
> > }
> >
> > + if (!tcf_action_valid(a->tcfa_action)) {
> > + NL_SET_ERR_MSG(extack, "invalid action value, using TC_ACT_UNSPEC instead");
> > + a->tcfa_action = TC_ACT_UNSPEC;
> > + }
> > +
> > return a;
> >
>
>
> I think it would make a lot more sense to just reject the entry than
> changing it underneath the user to a default value. Least element of
> suprise.
I fear that would break existing (bad) users ?!? This way, such users
are notified they are doing something uncorrect, but still continue to
work.
The patch can be changed to reject bad actions, if there is agreement,
but it would not look as the safest way to me.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net-next v7] net/tls: Use socket data_ready callback on record availability
From: David Miller @ 2018-07-30 16:42 UTC (permalink / raw)
To: vakul.garg; +Cc: netdev, borisp, aviadye, davejwatson
In-Reply-To: <20180730103833.6585-1-vakul.garg@nxp.com>
From: Vakul Garg <vakul.garg@nxp.com>
Date: Mon, 30 Jul 2018 16:08:33 +0530
> On receipt of a complete tls record, use socket's saved data_ready
> callback instead of state_change callback. In function tls_queue(),
> the TLS record is queued in encrypted state. But the decryption
> happen inline when tls_sw_recvmsg() or tls_sw_splice_read() get invoked.
> So it should be ok to notify the waiting context about the availability
> of data as soon as we could collect a full TLS record. For new data
> availability notification, sk_data_ready callback is more appropriate.
> It points to sock_def_readable() which wakes up specifically for EPOLLIN
> event. This is in contrast to the socket callback sk_state_change which
> points to sock_def_wakeup() which issues a wakeup unconditionally
> (without event mask).
>
> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
> ---
> v6->v7: Improved the commit message to contain the detailed reasoning.
> (The same analysis was shared on the mail list.)
Applied.
^ permalink raw reply
* Re: [PATCH net] net/ipv6: fix metrics leak
From: David Miller @ 2018-07-30 16:46 UTC (permalink / raw)
To: sd; +Cc: netdev, dsahern
In-Reply-To: <e19b81fff08014ff9bf20412f41bb2cf460ae6ed.1532960405.git.sd@queasysnail.net>
From: Sabrina Dubroca <sd@queasysnail.net>
Date: Mon, 30 Jul 2018 16:23:10 +0200
> Since commit d4ead6b34b67 ("net/ipv6: move metrics from dst to
> rt6_info"), ipv6 metrics are shared and refcounted. rt6_set_from()
> assigns the rt->from pointer and increases the refcount on from's
> metrics. This reference is never released.
>
> Introduce the fib6_metrics_release() helper and use it to release the
> metrics.
>
> Fixes: d4ead6b34b67 ("net/ipv6: move metrics from dst to rt6_info")
> Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Looks good, applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/5] A test for mirror-to-gretap with team in UL packet path
From: David Miller @ 2018-07-30 16:48 UTC (permalink / raw)
To: petrm; +Cc: netdev, linux-kselftest, shuah
In-Reply-To: <cover.1532961216.git.petrm@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Date: Mon, 30 Jul 2018 16:37:17 +0200
> This patchset adds a test for "tc action mirred mirror" where the
> mirrored-to device is a gretap, and underlay path contains a team
> device.
>
> In patch #1 require_command() is added, which should henceforth be used
> to declare dependence on a certain tool.
>
> In patch #2, two new functions, team_create() and team_destroy(), are
> added to lib.sh.
>
> The newly-added test uses arping, which isn't necessarily available.
> Therefore patch #3 introduces $ARPING, and a preexisting test is fixed
> to require_command $ARPING.
>
> In patches #4 and #5, two new tests are added. In both cases, a team
> device is on egress path of a mirrored packet in a mirror-to-gretap
> scenario. In the first one, the team device is in loadbalance mode, in
> the second one it's in lacp mode. (The difference in modes necessitates
> a different testing strategy, hence two test cases instead of just
> parameterizing one.)
I always like seeing new test cases. :)
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 6/7] net: phy: Add support to configure clock in Broadcom iProc mdio mux
From: Arun Parameswaran @ 2018-07-30 16:49 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Florian Fainelli, Rob Herring, Mark Rutland,
Ray Jui, Scott Branden, Catalin Marinas, Will Deacon, netdev,
devicetree, linux-arm-kernel, linux-kernel,
bcm-kernel-feedback-list
In-Reply-To: <20180728212224.GF4792@lunn.ch>
Hi Andrew,
On 18-07-28 02:22 PM, Andrew Lunn wrote:
>> @@ -198,10 +219,22 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
>> return PTR_ERR(md->base);
>> }
>>
>> + md->core_clk = devm_clk_get(&pdev->dev, NULL);
>> + if (IS_ERR(md->core_clk)) {
>> + md->core_clk = NULL;
>> + } else {
>> + rc = clk_prepare_enable(md->core_clk);
>> + if (rc) {
>> + dev_err(&pdev->dev, "failed to enable core clk\n");
>> + return rc;
>> + }
>> + }
>> +
>> md->mii_bus = mdiobus_alloc();
>> if (!md->mii_bus) {
>> dev_err(&pdev->dev, "mdiomux bus alloc failed\n");
>> - return -ENOMEM;
>> + rc = -ENOMEM;
>> + goto out;
>
> Hi Arun
>
> There is a devm_mdiobus_alloc() which could make the cleanup on error
> simple.
>
Should I do this as a separate patch ?
Thanks
Arun
>> }
>>
>> bus = md->mii_bus;
>> @@ -217,7 +250,7 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
>> rc = mdiobus_register(bus);
>> if (rc) {
>> dev_err(&pdev->dev, "mdiomux registration failed\n");
>> - goto out;
>> + goto out_alloc;
>> }
>>
>> platform_set_drvdata(pdev, md);
>> @@ -236,8 +269,11 @@ static int mdio_mux_iproc_probe(struct platform_device *pdev)
>>
>> out_register:
>> mdiobus_unregister(bus);
>> -out:
>> +out_alloc:
>> mdiobus_free(bus);
>> +out:
>> + if (md->core_clk)
>> + clk_disable_unprepare(md->core_clk);
>> return rc;
>> }
>
> Andrew
>
^ permalink raw reply
* Re: [PATCH net-next v5 3/4] net/tc: introduce TC_ACT_REINSERT.
From: Jiri Pirko @ 2018-07-30 16:49 UTC (permalink / raw)
To: David Miller
Cc: pabeni, netdev, jhs, xiyou.wangcong, daniel, marcelo.leitner,
eyal.birger
In-Reply-To: <20180730.093100.1043667653536689097.davem@davemloft.net>
Mon, Jul 30, 2018 at 06:31:00PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Mon, 30 Jul 2018 14:40:13 +0200
>
>> Oh, another nitpick: The changelog should go under "---" line. That way,
>> the maintainer does not have to deal with it during apply (git apply
>> will cut it out).
>
>I actually like the changelog to be _IN_ the commit message.
>
>It's useful information that helps someone investigating history
>in the tree later.
>
>Please do not tell people to pull changelogs out of the commit
>message, thank you. I've been telling them to do the exact
>opposite.
Oups. Interesting. So the changelog stays in the commit message, right?
I noticed that in the past but thought it was an accident. Sorry about
that. I owe you just another beer :)
^ permalink raw reply
* Re: [PATCH net-next v5 3/4] net/tc: introduce TC_ACT_REINSERT.
From: David Miller @ 2018-07-30 16:56 UTC (permalink / raw)
To: jiri
Cc: pabeni, netdev, jhs, xiyou.wangcong, daniel, marcelo.leitner,
eyal.birger
In-Reply-To: <20180730164923.GD10626@nanopsycho>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 30 Jul 2018 18:49:23 +0200
> So the changelog stays in the commit message, right?
Yes.
^ permalink raw reply
* Re: [PATCH rdma-next 00/27] Flow actions to mutate packets
From: Jason Gunthorpe @ 2018-07-30 17:09 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi,
Mark Bloch, Or Gerlitz, Saeed Mahameed, linux-netdev
In-Reply-To: <20180729125905.31989-1-leon@kernel.org>
On Sun, Jul 29, 2018 at 03:58:38PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Hi,
>
> This is PATCH variant of RFC posted in previous week to the ML.
> https://patchwork.ozlabs.org/cover/944184/
>
> Changelog:
> RFC -> v0:
> * Patch 1 a new patch which refactors the logic
> when getting a flow namespace.
> * Patch 2 was split into two.
> * Patch 3: Fixed a typo in commit message
> * Patch 5: Updated commit message
> * Patch 7: Updated commit message
> Renamed:
> - MLX5_FLOW_CONTEXT_ACTION_PACKET_REFORMAT_ID to
> MLX5_FLOW_CONTEXT_ACTION_PACKET_REFORMAT
> - packet_reformat_id to reformat_id in struct mlx5_flow_act
> - packet_reformat_id to encap_id in struct mlx5_esw_flow_attr
> - packet_reformat_id to encap_id in struct mlx5e_encap_entry
> - PACKET_REFORMAT to REFORMAT when printing trace points
> * Patch 9: Updated commit message
> Updated function declaration in mlx5_core.h, could of lead
> to compile error on bisection.
> * Patch 11: Disallow egress rules insertion when in switchdev mode
> * Patch 12: A new patch to deal with passing enum values using
> the IOCTL infrastructure.
> * Patch 13: Use new enum value attribute when passing enum
> mlx5_ib_uapi_flow_table_type
> * Patch 15: Don't set encap flags on flow tables if in switchdev mode
> * Patch 17: Use new enum value attribute when passing enum
> mlx5_ib_uapi_flow_table_type and enum
> mlx5_ib_uapi_flow_action_packet_reformat_type
> * Patch 19: Allow creation of both
> MLX5_IB_UAPI_FLOW_ACTION_PACKET_REFORMAT_TYPE_L2_TO_L3_TUNNEL
> and MLX5_IB_UAPI_FLOW_ACTION_PACKET_REFORMAT_TYPE_L3_TUNNEL_TO_L2 packet
> reformat actions.
> * Patch 20: A new patch which allows attaching packet reformat
> actions to flow tables on NIC RX.
>
> Thanks
>
> From Mark:
> This series exposes the ability to create flow actions which can
> mutate packet headers. We do that by exposing two new verbs:
> * modify header - can change existing packet headers. packet
> * reformat - can encapsulate or decapsulate a packet.
> Once created a flow action must be attached to a steering
> rule for it to take effect.
Mark, this got a bit big in terms of patch count, however most of the
patches fit on one screen and the overall line count isn't too bad.
Can this be split somehow?
Thanks,
Jason
^ permalink raw reply
* Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message
From: Andrew Lunn @ 2018-07-30 18:54 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, linux-kernel, Jiri Pirko, David Miller, Florian Fainelli,
Roopa Prabhu, Jakub Kicinski, John W. Linville
In-Reply-To: <67d3b68a50e95db9612cc96e42a52ce332f716a9.1532953989.git.mkubecek@suse.cz>
> +/* Internal kernel helper to query a device ethtool_link_settings.
> + *
> + * Backward compatibility note: for compatibility with legacy drivers
> + * that implement only the ethtool_cmd API, this has to work with both
> + * drivers implementing get_link_ksettings API and drivers
> + * implementing get_settings API. When drivers implement get_settings
> + * and report ethtool_cmd deprecated fields
> + * (transceiver/maxrxpkt/maxtxpkt), these fields are silently ignored
> + * because the resulting struct ethtool_link_settings does not report them.
~/linux/drivers$ grep -r [.]get_settings *
net/ethernet/8390/etherh.c: .get_settings = etherh_get_settings,
I don't think it is worth adding support for .get_settings for just
one driver. It is better to just convert that driver to the new API.
Andrew
^ permalink raw reply
* Microsoft Ignite - 2018
From: Lisa Parker @ 2018-07-30 17:14 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
Hi,
I hope you and your team must be well prepared for the event Microsoft
Ignite - held on 09/24/2018 - 09/28/2018.
I am checking in, if you would like to drive more traffic to your booth? If
yes, we can help you with the current registered attendee list with the
complete contact information (including emails and phone numbers).
Please feel free to get back to me if you are interested in getting more
information on the total count and pricing options.
Best Wishes,
Lisa Parker
Events Specialist
If you are no longer interested, please replay back with "unsubscribe" as
sub line
[-- Attachment #2: Type: text/html, Size: 3629 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message
From: Andrew Lunn @ 2018-07-30 19:06 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, linux-kernel, Jiri Pirko, David Miller, Florian Fainelli,
Roopa Prabhu, Jakub Kicinski, John W. Linville
In-Reply-To: <67d3b68a50e95db9612cc96e42a52ce332f716a9.1532953989.git.mkubecek@suse.cz>
> + ETHA_SETTINGS_MDIO_SUPPORT (bitfield32) MDIO support flags
Now might be a good time to drop this. The mdio drivers don't have
this information. There is no API between the MAC driver and the MDIO
driver to ask for it. Only a couple of drivers which ignore the kernel
MDIO code set this.
Andrew
^ permalink raw reply
* Re: [RFC PATCH net-next v2 10/17] ethtool: implement GET_SETTINGS message
From: Andrew Lunn @ 2018-07-30 19:09 UTC (permalink / raw)
To: Michal Kubecek
Cc: netdev, linux-kernel, Jiri Pirko, David Miller, Florian Fainelli,
Roopa Prabhu, Jakub Kicinski, John W. Linville
In-Reply-To: <67d3b68a50e95db9612cc96e42a52ce332f716a9.1532953989.git.mkubecek@suse.cz>
> +Response contents:
> +
> + ETHA_SETTINGS_LINK (u32) link state
> + [ETHA_SETTINGS_LINK] = { .type = NLA_FLAG },
Is this correct?
The link is either up or down. So a u32 seems a bit big.
Andrew
^ permalink raw reply
* Re: [PATCH rdma-next 00/27] Flow actions to mutate packets
From: Mark Bloch @ 2018-07-30 17:37 UTC (permalink / raw)
To: Jason Gunthorpe, Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi(SW),
Or Gerlitz, Saeed Mahameed, linux-netdev
In-Reply-To: <20180730170958.GK15118@mellanox.com>
On 7/30/2018 10:10 AM, Jason Gunthorpe wrote:
> On Sun, Jul 29, 2018 at 03:58:38PM +0300, Leon Romanovsky wrote:
>> From: Leon Romanovsky <leonro@mellanox.com>
>>
>> Hi,
>>
>> This is PATCH variant of RFC posted in previous week to the ML.
>> https://patchwork.ozlabs.org/cover/944184/
>>
>> Changelog:
>> RFC -> v0:
>> * Patch 1 a new patch which refactors the logic
>> when getting a flow namespace.
>> * Patch 2 was split into two.
>> * Patch 3: Fixed a typo in commit message
>> * Patch 5: Updated commit message
>> * Patch 7: Updated commit message
>> Renamed:
>> - MLX5_FLOW_CONTEXT_ACTION_PACKET_REFORMAT_ID to
>> MLX5_FLOW_CONTEXT_ACTION_PACKET_REFORMAT
>> - packet_reformat_id to reformat_id in struct mlx5_flow_act
>> - packet_reformat_id to encap_id in struct mlx5_esw_flow_attr
>> - packet_reformat_id to encap_id in struct mlx5e_encap_entry
>> - PACKET_REFORMAT to REFORMAT when printing trace points
>> * Patch 9: Updated commit message
>> Updated function declaration in mlx5_core.h, could of lead
>> to compile error on bisection.
>> * Patch 11: Disallow egress rules insertion when in switchdev mode
>> * Patch 12: A new patch to deal with passing enum values using
>> the IOCTL infrastructure.
>> * Patch 13: Use new enum value attribute when passing enum
>> mlx5_ib_uapi_flow_table_type
>> * Patch 15: Don't set encap flags on flow tables if in switchdev mode
>> * Patch 17: Use new enum value attribute when passing enum
>> mlx5_ib_uapi_flow_table_type and enum
>> mlx5_ib_uapi_flow_action_packet_reformat_type
>> * Patch 19: Allow creation of both
>> MLX5_IB_UAPI_FLOW_ACTION_PACKET_REFORMAT_TYPE_L2_TO_L3_TUNNEL
>> and MLX5_IB_UAPI_FLOW_ACTION_PACKET_REFORMAT_TYPE_L3_TUNNEL_TO_L2 packet
>> reformat actions.
>> * Patch 20: A new patch which allows attaching packet reformat
>> actions to flow tables on NIC RX.
>>
>> Thanks
>>
>> From Mark:
>> This series exposes the ability to create flow actions which can
>> mutate packet headers. We do that by exposing two new verbs:
>> * modify header - can change existing packet headers. packet
>> * reformat - can encapsulate or decapsulate a packet.
>> Once created a flow action must be attached to a steering
>> rule for it to take effect.
>
> Mark, this got a bit big in terms of patch count, however most of the
> patches fit on one screen and the overall line count isn't too bad.
Yes, there is a lot of code refactoring inside mlx5 drivers but overall
the code is very simple. The difference from the RFC is mainly renames
and commit messages and the last 6 patches which add support for flow action
to mlx5 create flow, that wasn't posted with the RFC as the mlx5 create flow
code wasn't merged yet.
>
> Can this be split somehow?
>
It can be split into 3 series like this:
Refactoring mlx5_core + rename + creation of flow actions:
patch [01/27]: net/mlx5: Cleanup flow namespace getter switch logic
patch [02/27]: net/mlx5: Add proper NIC TX steering flow tables support
patch [03/27]: net/mlx5: Export modify header alloc/dealloc functions
patch [04/27]: net/mlx5: Add support for more namespaces when allocating modify header
patch [05/27]: net/mlx5: Break encap/decap into two separated flow table creation flags
patch [06/27]: net/mlx5: Move header encap type to IFC header file
patch [07/27]: {net, RDMA}/mlx5: Rename encap to reformat packet
patch [08/27]: net/mlx5: Expose new packet reformat capabilities
patch [09/27]: net/mlx5: Pass a namespace for packet reformat ID allocation
patch [10/27]: net/mlx5: Export packet reformat alloc/dealloc functions
patch [12/27]: RDMA/uverbs: Add UVERBS_ATTR_CONST_IN to the specs language
patch [13/27]: RDMA/mlx5: Add a new flow action verb, modify header
patch [16/27]: RDMA/uverbs: Add generic function to fill in flow action object
patch [17/27]: RDMA/mlx5: Add new flow action verb, packet reformat
patch [19/27]: RDMA/mlx5: Extend packet reformat verbs
Enable attaching modify header and packet reformat flow actions via verbs create flow:
patch [11/27]: RDMA/mlx5: Add NIC TX steering support
patch [14/27]: RDMA/mlx5: Enable attaching modify header to steering flows
patch [15/27]: RDMA/mlx5: Enable decap and packet reformat on flow tables
patch [18/27]: RDMA/mlx5: Enable attaching DECAP action to steering flows
patch [20/27]: RDMA/mlx5: Enable reformat on NIC RX if supported
patch [21/27]: RDMA/mlx5: Enable attaching packet reformat action to steering flows
Enable attaching modify header and packet reformat flow actions via mlx5 create flow:
patch [22/27]: IB/uverbs: Add IDRs array attribute type to ioctl() interface
patch [23/27]: RDMA/mlx5: Refactor flow action parsing to be more generic
patch [24/27]: RDMA/mlx5: Refactor DEVX flow creation
patch [25/27]: RDMA/mlx5: Add flow actions support to DEVX create flow
patch [26/27]: RDMA/mlx5: Add NIC TX namespace when getting a flow table
patch [27/27]: RDMA/mlx5: Allow creating a matcher for a NIC TX flow table
> Thanks,
> Jason
>
Mark
^ permalink raw reply
* Re: [PATCH 00/18] xfrm: Add compat layer
From: Dmitry Safonov @ 2018-07-30 17:39 UTC (permalink / raw)
To: David Miller
Cc: nharold, fw, steffen.klassert, linux-kernel, herbert, 0x7f454c46,
netdev, luto, ard.biesheuvel, hpa, mingo, john.stultz,
kirill.shutemov, oleg, sboyd, rostedt, tglx, x86, linux-efi, akpm,
gregkh, mchehab+samsung, shuah, linux-kselftest, eparis, kadlec,
pablo, paul, coreteam, linux-audit, netfilter-devel, fan.du
In-Reply-To: <20180728.141812.1026007723536955024.davem@davemloft.net>
On Sat, 2018-07-28 at 14:18 -0700, David Miller wrote:
> From: Dmitry Safonov <dima@arista.com>
> Date: Sat, 28 Jul 2018 17:26:55 +0100
>
> > Well, I think, I'll rework my patches set according to critics and
> > separate compat xfrm layer. I've already a selftest to check that
> 32/64
> > bit xfrm works - so the most time-taking part is done.
>
> The way you've done the compat structures using __packed is only
> going
> to work on x86, just FYI.
Thanks for pointing, so I'll probably cover it under something like
HAS_COMPAT_XFRM.
(if there isn't any better idea).
> The "32-bit alignment for 64-bit objects" thing x86 has is very much
> not universal amongst ABIs having 32-bit and 64-bit variants.
--
Thanks,
Dmitry
^ 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