* Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?
From: Willem de Bruijn @ 2017-09-13 15:05 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Shmulik Ladkani, netfilter-devel, Pablo Neira Ayuso,
Network Development, Willem de Bruijn, Rafael Buchbinder,
Shmulik Ladkani, eyal
In-Reply-To: <nycvar.YFH.7.76.1709131613520.8761@n3.vanv.qr>
On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>
> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>>
>>One way to fix is to have iptables open the object (using the stored
>>xt_bpf_info_v1->path), gaining a new process local fd for the object,
>>just after getting the rules from IPT_SO_GET_ENTRIES.
>>However we didn't see any other extensions doing something like that in
>>iptables.
The binary should call bpf_obj_get on the filepath each time. These are
not regular files, but references to a pinned object in the bpf filesystem.
Blindly passing back the fd received from the kernel is clearly wrong. I'm
really surprised that I did not run into this problem when I wrote the
feature.
>>
>>Another way to solve is to fix the ABI (or have a v2 one), that does NOT
>>pass the fd from userspace, only the path of the pinned object.
>>Then, 'bpf_mt_check_v1' will open the file from the given path in order
>>to get the bpf_prog.
>
> But a path has a similar problem like a file descriptor - it is local to a
> certain mount namespace.
Because these are pinned objects in the bpf filesystem, and there is
only one of those, it may be possible to lookup the object in the kernel
without relying on a process-local view of mount points.
>
> To load "large" blobs into the kernel, a pointer to user memory is a possible
> option. The downside is that such extra data is not retrievable from the kernel
> via the iptables setsockopts anymore - one could work around it with procfs, or
> just let it be.
>
> https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_geoip.c
> line 64+.
^ permalink raw reply
* Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels
From: Jorgen S. Hansen @ 2017-09-13 15:07 UTC (permalink / raw)
To: Michal Hocko
Cc: Aditya Sarwade, Thomas Hellstrom, LKML, netdev@vger.kernel.org,
Masik Petr, Ben Hutchings, Sasha Levin, Stable tree
In-Reply-To: <20170912090852.qshtrioffwexkslw@dhcp22.suse.cz>
> On Sep 12, 2017, at 11:08 AM, Michal Hocko <mhocko@kernel.org> wrote:
>
> Hi,
> we are seeing the following splat with Debian 3.16 stable kernel
>
> BUG: scheduling while atomic: MATLAB/26771/0x00000100
> Modules linked in: veeamsnap(O) hmac cbc cts nfsv4 dns_resolver rpcsec_gss_krb5 nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc vmw_vso$
> CPU: 0 PID: 26771 Comm: MATLAB Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt20-1+deb8u3
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015
> ffff88315c1e4c20 ffffffff8150db3f ffff88193f803dc8 ffffffff8150acdf
> ffffffff815103a2 0000000000012f00 ffff8819423dbfd8 0000000000012f00
> ffff88315c1e4c20 ffff88193f803dc8 ffff88193f803d50 ffff88193f803dc0
> Call Trace:
> <IRQ> [<ffffffff8150db3f>] ? dump_stack+0x41/0x51
> [<ffffffff8150acdf>] ? __schedule_bug+0x48/0x55
> [<ffffffff815103a2>] ? __schedule+0x5d2/0x700
> [<ffffffff8150f9b9>] ? schedule_timeout+0x229/0x2a0
> [<ffffffff8109ba70>] ? select_task_rq_fair+0x390/0x700
> [<ffffffff8109f780>] ? check_preempt_wakeup+0x120/0x1d0
> [<ffffffff81510eb8>] ? wait_for_completion+0xa8/0x120
> [<ffffffff81096de0>] ? wake_up_state+0x10/0x10
> [<ffffffff810c3da0>] ? call_rcu_bh+0x20/0x20
> [<ffffffff810c180b>] ? wait_rcu_gp+0x4b/0x60
> [<ffffffff810c17b0>] ? ftrace_raw_output_rcu_utilization+0x40/0x40
> [<ffffffffa02ca6f5>] ? vmci_event_unsubscribe+0x75/0xb0 [vmw_vmci]
> [<ffffffffa031f5cd>] ? vmci_transport_destruct+0x1d/0xe0 [vmw_vsock_vmci_transport]
> [<ffffffffa03167e3>] ? vsock_sk_destruct+0x13/0x60 [vsock]
> [<ffffffff81409f7a>] ? __sk_free+0x1a/0x130
> [<ffffffffa0320218>] ? vmci_transport_recv_stream_cb+0x1e8/0x2d0 [vmw_vsock_vmci_transport]
> [<ffffffffa02c9cba>] ? vmci_datagram_invoke_guest_handler+0xaa/0xd0 [vmw_vmci]
> [<ffffffffa02cab51>] ? vmci_dispatch_dgs+0xc1/0x200 [vmw_vmci]
> [<ffffffff8106c294>] ? tasklet_action+0xf4/0x100
> [<ffffffff8106c681>] ? __do_softirq+0xf1/0x290
> [<ffffffff8106ca55>] ? irq_exit+0x95/0xa0
> [<ffffffff81516b22>] ? do_IRQ+0x52/0xe0
> [<ffffffff8151496d>] ? common_interrupt+0x6d/0x6d
>
> AFAICS this has been fixed by 4ef7ea9195ea ("VSOCK: sock_put wasn't safe
> to call in interrupt context") but this patch hasn't been backported to
> stable trees. It applies cleanly on top of 3.16 stable tree but I am not
> familiar with the code to send the backport to the stable maintainer
> directly.
>
> Could you double check that the patch below (just a blind cherry-pick)
> is correct and it doesn't need additional patches on top?
Hi,
The patch below has been used to fix the above issue by other distros - among them Redhat for the 3.10 kernel, so it should work for 3.16 as well. In addition to the patch above, there are two other patches that need to be applied on top for the fix to be correct:
8566b86ab9f0f45bc6f7dd422b21de9d0cf5415a "VSOCK: Fix lockdep issue."
and
8ab18d71de8b07d2c4d6f984b718418c09ea45c5 "VSOCK: Detach QP check should filter out non matching QPs."
Thanks,
Jorgen
>
> Ben could you take this to your stable 3.16 branch if the patch is correct?
>
> I am CCing Sasha for 4.1 stable tree as well. I haven't checked whether
> pre 3.16 kernels are affected as well.
> ---
> commit fac774c40b5c512113b6373cad498f35bee7a409
> Author: Jorgen Hansen <jhansen@vmware.com>
> Date: Wed Oct 21 04:53:56 2015 -0700
>
> VSOCK: sock_put wasn't safe to call in interrupt context
>
> commit 4ef7ea9195ea73262cd9730fb54e1eb726da157b upstream.
>
> In the vsock vmci_transport driver, sock_put wasn't safe to call
> in interrupt context, since that may call the vsock destructor
> which in turn calls several functions that should only be called
> from process context. This change defers the callling of these
> functions to a worker thread. All these functions were
> deallocation of resources related to the transport itself.
>
> Furthermore, an unused callback was removed to simplify the
> cleanup.
>
> Multiple customers have been hitting this issue when using
> VMware tools on vSphere 2015.
>
> Also added a version to the vmci transport module (starting from
> 1.0.2.0-k since up until now it appears that this module was
> sharing version with vsock that is currently at 1.0.1.0-k).
>
> Reviewed-by: Aditya Asarwade <asarwade@vmware.com>
> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
> index 9bb63ffec4f2..aed136d27b01 100644
> --- a/net/vmw_vsock/vmci_transport.c
> +++ b/net/vmw_vsock/vmci_transport.c
> @@ -40,13 +40,11 @@
>
> static int vmci_transport_recv_dgram_cb(void *data, struct vmci_datagram *dg);
> static int vmci_transport_recv_stream_cb(void *data, struct vmci_datagram *dg);
> -static void vmci_transport_peer_attach_cb(u32 sub_id,
> - const struct vmci_event_data *ed,
> - void *client_data);
> static void vmci_transport_peer_detach_cb(u32 sub_id,
> const struct vmci_event_data *ed,
> void *client_data);
> static void vmci_transport_recv_pkt_work(struct work_struct *work);
> +static void vmci_transport_cleanup(struct work_struct *work);
> static int vmci_transport_recv_listen(struct sock *sk,
> struct vmci_transport_packet *pkt);
> static int vmci_transport_recv_connecting_server(
> @@ -75,6 +73,10 @@ struct vmci_transport_recv_pkt_info {
> struct vmci_transport_packet pkt;
> };
>
> +static LIST_HEAD(vmci_transport_cleanup_list);
> +static DEFINE_SPINLOCK(vmci_transport_cleanup_lock);
> +static DECLARE_WORK(vmci_transport_cleanup_work, vmci_transport_cleanup);
> +
> static struct vmci_handle vmci_transport_stream_handle = { VMCI_INVALID_ID,
> VMCI_INVALID_ID };
> static u32 vmci_transport_qp_resumed_sub_id = VMCI_INVALID_ID;
> @@ -791,44 +793,6 @@ static int vmci_transport_recv_stream_cb(void *data, struct vmci_datagram *dg)
> return err;
> }
>
> -static void vmci_transport_peer_attach_cb(u32 sub_id,
> - const struct vmci_event_data *e_data,
> - void *client_data)
> -{
> - struct sock *sk = client_data;
> - const struct vmci_event_payload_qp *e_payload;
> - struct vsock_sock *vsk;
> -
> - e_payload = vmci_event_data_const_payload(e_data);
> -
> - vsk = vsock_sk(sk);
> -
> - /* We don't ask for delayed CBs when we subscribe to this event (we
> - * pass 0 as flags to vmci_event_subscribe()). VMCI makes no
> - * guarantees in that case about what context we might be running in,
> - * so it could be BH or process, blockable or non-blockable. So we
> - * need to account for all possible contexts here.
> - */
> - local_bh_disable();
> - bh_lock_sock(sk);
> -
> - /* XXX This is lame, we should provide a way to lookup sockets by
> - * qp_handle.
> - */
> - if (vmci_handle_is_equal(vmci_trans(vsk)->qp_handle,
> - e_payload->handle)) {
> - /* XXX This doesn't do anything, but in the future we may want
> - * to set a flag here to verify the attach really did occur and
> - * we weren't just sent a datagram claiming it was.
> - */
> - goto out;
> - }
> -
> -out:
> - bh_unlock_sock(sk);
> - local_bh_enable();
> -}
> -
> static void vmci_transport_handle_detach(struct sock *sk)
> {
> struct vsock_sock *vsk;
> @@ -871,28 +835,38 @@ static void vmci_transport_peer_detach_cb(u32 sub_id,
> const struct vmci_event_data *e_data,
> void *client_data)
> {
> - struct sock *sk = client_data;
> + struct vmci_transport *trans = client_data;
> const struct vmci_event_payload_qp *e_payload;
> - struct vsock_sock *vsk;
>
> e_payload = vmci_event_data_const_payload(e_data);
> - vsk = vsock_sk(sk);
> - if (vmci_handle_is_invalid(e_payload->handle))
> - return;
> -
> - /* Same rules for locking as for peer_attach_cb(). */
> - local_bh_disable();
> - bh_lock_sock(sk);
>
> /* XXX This is lame, we should provide a way to lookup sockets by
> * qp_handle.
> */
> - if (vmci_handle_is_equal(vmci_trans(vsk)->qp_handle,
> - e_payload->handle))
> - vmci_transport_handle_detach(sk);
> + if (vmci_handle_is_invalid(e_payload->handle) ||
> + vmci_handle_is_equal(trans->qp_handle, e_payload->handle))
> + return;
>
> - bh_unlock_sock(sk);
> - local_bh_enable();
> + /* We don't ask for delayed CBs when we subscribe to this event (we
> + * pass 0 as flags to vmci_event_subscribe()). VMCI makes no
> + * guarantees in that case about what context we might be running in,
> + * so it could be BH or process, blockable or non-blockable. So we
> + * need to account for all possible contexts here.
> + */
> + spin_lock_bh(&trans->lock);
> + if (!trans->sk)
> + goto out;
> +
> + /* Apart from here, trans->lock is only grabbed as part of sk destruct,
> + * where trans->sk isn't locked.
> + */
> + bh_lock_sock(trans->sk);
> +
> + vmci_transport_handle_detach(trans->sk);
> +
> + bh_unlock_sock(trans->sk);
> + out:
> + spin_unlock_bh(&trans->lock);
> }
>
> static void vmci_transport_qp_resumed_cb(u32 sub_id,
> @@ -1181,7 +1155,7 @@ vmci_transport_recv_connecting_server(struct sock *listener,
> */
> err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_DETACH,
> vmci_transport_peer_detach_cb,
> - pending, &detach_sub_id);
> + vmci_trans(vpending), &detach_sub_id);
> if (err < VMCI_SUCCESS) {
> vmci_transport_send_reset(pending, pkt);
> err = vmci_transport_error_to_vsock_error(err);
> @@ -1321,7 +1295,6 @@ vmci_transport_recv_connecting_client(struct sock *sk,
> || vmci_trans(vsk)->qpair
> || vmci_trans(vsk)->produce_size != 0
> || vmci_trans(vsk)->consume_size != 0
> - || vmci_trans(vsk)->attach_sub_id != VMCI_INVALID_ID
> || vmci_trans(vsk)->detach_sub_id != VMCI_INVALID_ID) {
> skerr = EPROTO;
> err = -EINVAL;
> @@ -1389,7 +1362,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
> struct vsock_sock *vsk;
> struct vmci_handle handle;
> struct vmci_qp *qpair;
> - u32 attach_sub_id;
> u32 detach_sub_id;
> bool is_local;
> u32 flags;
> @@ -1399,7 +1371,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
>
> vsk = vsock_sk(sk);
> handle = VMCI_INVALID_HANDLE;
> - attach_sub_id = VMCI_INVALID_ID;
> detach_sub_id = VMCI_INVALID_ID;
>
> /* If we have gotten here then we should be past the point where old
> @@ -1444,23 +1415,15 @@ static int vmci_transport_recv_connecting_client_negotiate(
> goto destroy;
> }
>
> - /* Subscribe to attach and detach events first.
> + /* Subscribe to detach events first.
> *
> * XXX We attach once for each queue pair created for now so it is easy
> * to find the socket (it's provided), but later we should only
> * subscribe once and add a way to lookup sockets by queue pair handle.
> */
> - err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_ATTACH,
> - vmci_transport_peer_attach_cb,
> - sk, &attach_sub_id);
> - if (err < VMCI_SUCCESS) {
> - err = vmci_transport_error_to_vsock_error(err);
> - goto destroy;
> - }
> -
> err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_DETACH,
> vmci_transport_peer_detach_cb,
> - sk, &detach_sub_id);
> + vmci_trans(vsk), &detach_sub_id);
> if (err < VMCI_SUCCESS) {
> err = vmci_transport_error_to_vsock_error(err);
> goto destroy;
> @@ -1496,7 +1459,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
> vmci_trans(vsk)->produce_size = vmci_trans(vsk)->consume_size =
> pkt->u.size;
>
> - vmci_trans(vsk)->attach_sub_id = attach_sub_id;
> vmci_trans(vsk)->detach_sub_id = detach_sub_id;
>
> vmci_trans(vsk)->notify_ops->process_negotiate(sk);
> @@ -1504,9 +1466,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
> return 0;
>
> destroy:
> - if (attach_sub_id != VMCI_INVALID_ID)
> - vmci_event_unsubscribe(attach_sub_id);
> -
> if (detach_sub_id != VMCI_INVALID_ID)
> vmci_event_unsubscribe(detach_sub_id);
>
> @@ -1607,9 +1566,11 @@ static int vmci_transport_socket_init(struct vsock_sock *vsk,
> vmci_trans(vsk)->qp_handle = VMCI_INVALID_HANDLE;
> vmci_trans(vsk)->qpair = NULL;
> vmci_trans(vsk)->produce_size = vmci_trans(vsk)->consume_size = 0;
> - vmci_trans(vsk)->attach_sub_id = vmci_trans(vsk)->detach_sub_id =
> - VMCI_INVALID_ID;
> + vmci_trans(vsk)->detach_sub_id = VMCI_INVALID_ID;
> vmci_trans(vsk)->notify_ops = NULL;
> + INIT_LIST_HEAD(&vmci_trans(vsk)->elem);
> + vmci_trans(vsk)->sk = &vsk->sk;
> + vmci_trans(vsk)->lock = __SPIN_LOCK_UNLOCKED(vmci_trans(vsk)->lock);
> if (psk) {
> vmci_trans(vsk)->queue_pair_size =
> vmci_trans(psk)->queue_pair_size;
> @@ -1629,29 +1590,57 @@ static int vmci_transport_socket_init(struct vsock_sock *vsk,
> return 0;
> }
>
> -static void vmci_transport_destruct(struct vsock_sock *vsk)
> +static void vmci_transport_free_resources(struct list_head *transport_list)
> {
> - if (vmci_trans(vsk)->attach_sub_id != VMCI_INVALID_ID) {
> - vmci_event_unsubscribe(vmci_trans(vsk)->attach_sub_id);
> - vmci_trans(vsk)->attach_sub_id = VMCI_INVALID_ID;
> - }
> + while (!list_empty(transport_list)) {
> + struct vmci_transport *transport =
> + list_first_entry(transport_list, struct vmci_transport,
> + elem);
> + list_del(&transport->elem);
>
> - if (vmci_trans(vsk)->detach_sub_id != VMCI_INVALID_ID) {
> - vmci_event_unsubscribe(vmci_trans(vsk)->detach_sub_id);
> - vmci_trans(vsk)->detach_sub_id = VMCI_INVALID_ID;
> - }
> + if (transport->detach_sub_id != VMCI_INVALID_ID) {
> + vmci_event_unsubscribe(transport->detach_sub_id);
> + transport->detach_sub_id = VMCI_INVALID_ID;
> + }
>
> - if (!vmci_handle_is_invalid(vmci_trans(vsk)->qp_handle)) {
> - vmci_qpair_detach(&vmci_trans(vsk)->qpair);
> - vmci_trans(vsk)->qp_handle = VMCI_INVALID_HANDLE;
> - vmci_trans(vsk)->produce_size = 0;
> - vmci_trans(vsk)->consume_size = 0;
> + if (!vmci_handle_is_invalid(transport->qp_handle)) {
> + vmci_qpair_detach(&transport->qpair);
> + transport->qp_handle = VMCI_INVALID_HANDLE;
> + transport->produce_size = 0;
> + transport->consume_size = 0;
> + }
> +
> + kfree(transport);
> }
> +}
> +
> +static void vmci_transport_cleanup(struct work_struct *work)
> +{
> + LIST_HEAD(pending);
> +
> + spin_lock_bh(&vmci_transport_cleanup_lock);
> + list_replace_init(&vmci_transport_cleanup_list, &pending);
> + spin_unlock_bh(&vmci_transport_cleanup_lock);
> + vmci_transport_free_resources(&pending);
> +}
> +
> +static void vmci_transport_destruct(struct vsock_sock *vsk)
> +{
> + /* Ensure that the detach callback doesn't use the sk/vsk
> + * we are about to destruct.
> + */
> + spin_lock_bh(&vmci_trans(vsk)->lock);
> + vmci_trans(vsk)->sk = NULL;
> + spin_unlock_bh(&vmci_trans(vsk)->lock);
>
> if (vmci_trans(vsk)->notify_ops)
> vmci_trans(vsk)->notify_ops->socket_destruct(vsk);
>
> - kfree(vsk->trans);
> + spin_lock_bh(&vmci_transport_cleanup_lock);
> + list_add(&vmci_trans(vsk)->elem, &vmci_transport_cleanup_list);
> + spin_unlock_bh(&vmci_transport_cleanup_lock);
> + schedule_work(&vmci_transport_cleanup_work);
> +
> vsk->trans = NULL;
> }
>
> @@ -2148,6 +2137,9 @@ module_init(vmci_transport_init);
>
> static void __exit vmci_transport_exit(void)
> {
> + cancel_work_sync(&vmci_transport_cleanup_work);
> + vmci_transport_free_resources(&vmci_transport_cleanup_list);
> +
> if (!vmci_handle_is_invalid(vmci_transport_stream_handle)) {
> if (vmci_datagram_destroy_handle(
> vmci_transport_stream_handle) != VMCI_SUCCESS)
> @@ -2166,6 +2158,7 @@ module_exit(vmci_transport_exit);
>
> MODULE_AUTHOR("VMware, Inc.");
> MODULE_DESCRIPTION("VMCI transport for Virtual Sockets");
> +MODULE_VERSION("1.0.2.0-k");
> MODULE_LICENSE("GPL v2");
> MODULE_ALIAS("vmware_vsock");
> MODULE_ALIAS_NETPROTO(PF_VSOCK);
> diff --git a/net/vmw_vsock/vmci_transport.h b/net/vmw_vsock/vmci_transport.h
> index ce6c9623d5f0..2ad46f39649f 100644
> --- a/net/vmw_vsock/vmci_transport.h
> +++ b/net/vmw_vsock/vmci_transport.h
> @@ -119,10 +119,12 @@ struct vmci_transport {
> u64 queue_pair_size;
> u64 queue_pair_min_size;
> u64 queue_pair_max_size;
> - u32 attach_sub_id;
> u32 detach_sub_id;
> union vmci_transport_notify notify;
> struct vmci_transport_notify_ops *notify_ops;
> + struct list_head elem;
> + struct sock *sk;
> + spinlock_t lock; /* protects sk. */
> };
>
> int vmci_transport_register(void);
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* Re: [PATCH 10/10] fs:btrfs: return -ENOMEM on allocation failure.
From: David Sterba @ 2017-09-13 15:13 UTC (permalink / raw)
To: Allen Pais
Cc: linux-kernel, nouveau, linux-crypto, dri-devel,
MPT-FusionLinux.pdl, linux-scsi, netdev, megaraidlinux.pdl,
target-devel, linux-fbdev, linux-btrfs
In-Reply-To: <1505287939-14106-10-git-send-email-allen.lkml@gmail.com>
On Wed, Sep 13, 2017 at 01:02:19PM +0530, Allen Pais wrote:
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
> ---
> fs/btrfs/check-integrity.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
> index 7d5a9b5..efa4c23 100644
> --- a/fs/btrfs/check-integrity.c
> +++ b/fs/btrfs/check-integrity.c
> @@ -2913,7 +2913,7 @@ int btrfsic_mount(struct btrfs_fs_info *fs_info,
> state = kvzalloc(sizeof(*state), GFP_KERNEL);
> if (!state) {
> pr_info("btrfs check-integrity: allocation failed!\n");
> - return -1;
> + return -ENOMEM;
Makes sense, also please fix the -1 a few lines below that also result
from failed memory allocation, indirectly from btrfsic_dev_state_alloc().
> }
>
> if (!btrfsic_is_initialized) {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: scheduling while atomic from vmci_transport_recv_stream_cb in 3.16 kernels
From: Michal Hocko @ 2017-09-13 15:19 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: Aditya Sarwade, Thomas Hellstrom, LKML, netdev@vger.kernel.org,
Masik Petr, Ben Hutchings, Sasha Levin, Stable tree
In-Reply-To: <B8A42FAB-9E16-4943-98F3-86FC8F195069@vmware.com>
On Wed 13-09-17 15:07:26, Jorgen S. Hansen wrote:
>
> > On Sep 12, 2017, at 11:08 AM, Michal Hocko <mhocko@kernel.org> wrote:
> >
> > Hi,
> > we are seeing the following splat with Debian 3.16 stable kernel
> >
> > BUG: scheduling while atomic: MATLAB/26771/0x00000100
> > Modules linked in: veeamsnap(O) hmac cbc cts nfsv4 dns_resolver rpcsec_gss_krb5 nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc vmw_vso$
> > CPU: 0 PID: 26771 Comm: MATLAB Tainted: G O 3.16.0-4-amd64 #1 Debian 3.16.7-ckt20-1+deb8u3
> > Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015
> > ffff88315c1e4c20 ffffffff8150db3f ffff88193f803dc8 ffffffff8150acdf
> > ffffffff815103a2 0000000000012f00 ffff8819423dbfd8 0000000000012f00
> > ffff88315c1e4c20 ffff88193f803dc8 ffff88193f803d50 ffff88193f803dc0
> > Call Trace:
> > <IRQ> [<ffffffff8150db3f>] ? dump_stack+0x41/0x51
> > [<ffffffff8150acdf>] ? __schedule_bug+0x48/0x55
> > [<ffffffff815103a2>] ? __schedule+0x5d2/0x700
> > [<ffffffff8150f9b9>] ? schedule_timeout+0x229/0x2a0
> > [<ffffffff8109ba70>] ? select_task_rq_fair+0x390/0x700
> > [<ffffffff8109f780>] ? check_preempt_wakeup+0x120/0x1d0
> > [<ffffffff81510eb8>] ? wait_for_completion+0xa8/0x120
> > [<ffffffff81096de0>] ? wake_up_state+0x10/0x10
> > [<ffffffff810c3da0>] ? call_rcu_bh+0x20/0x20
> > [<ffffffff810c180b>] ? wait_rcu_gp+0x4b/0x60
> > [<ffffffff810c17b0>] ? ftrace_raw_output_rcu_utilization+0x40/0x40
> > [<ffffffffa02ca6f5>] ? vmci_event_unsubscribe+0x75/0xb0 [vmw_vmci]
> > [<ffffffffa031f5cd>] ? vmci_transport_destruct+0x1d/0xe0 [vmw_vsock_vmci_transport]
> > [<ffffffffa03167e3>] ? vsock_sk_destruct+0x13/0x60 [vsock]
> > [<ffffffff81409f7a>] ? __sk_free+0x1a/0x130
> > [<ffffffffa0320218>] ? vmci_transport_recv_stream_cb+0x1e8/0x2d0 [vmw_vsock_vmci_transport]
> > [<ffffffffa02c9cba>] ? vmci_datagram_invoke_guest_handler+0xaa/0xd0 [vmw_vmci]
> > [<ffffffffa02cab51>] ? vmci_dispatch_dgs+0xc1/0x200 [vmw_vmci]
> > [<ffffffff8106c294>] ? tasklet_action+0xf4/0x100
> > [<ffffffff8106c681>] ? __do_softirq+0xf1/0x290
> > [<ffffffff8106ca55>] ? irq_exit+0x95/0xa0
> > [<ffffffff81516b22>] ? do_IRQ+0x52/0xe0
> > [<ffffffff8151496d>] ? common_interrupt+0x6d/0x6d
> >
> > AFAICS this has been fixed by 4ef7ea9195ea ("VSOCK: sock_put wasn't safe
> > to call in interrupt context") but this patch hasn't been backported to
> > stable trees. It applies cleanly on top of 3.16 stable tree but I am not
> > familiar with the code to send the backport to the stable maintainer
> > directly.
> >
> > Could you double check that the patch below (just a blind cherry-pick)
> > is correct and it doesn't need additional patches on top?
>
> Hi,
>
> The patch below has been used to fix the above issue by other distros
> - among them Redhat for the 3.10 kernel, so it should work for 3.16 as
> well.
Thanks for the confirmation. I do not see 4ef7ea9195ea ("VSOCK: sock_put
wasn't safe to call in interrupt context") in 3.10 stable branch
though.
> In addition to the patch above, there are two other patches that
> need to be applied on top for the fix to be correct:
>
> 8566b86ab9f0f45bc6f7dd422b21de9d0cf5415a "VSOCK: Fix lockdep issue."
>
> and
>
> 8ab18d71de8b07d2c4d6f984b718418c09ea45c5 "VSOCK: Detach QP check should filter out non matching QPs."
Good to know. I will send all three patches cherry-picked on top of the
current 3.16 stable branch. Could you have a look please?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH net] be2net: fix TSO6/GSO issue causing TX-stall on Lancer/BEx
From: Suresh Reddy @ 2017-09-13 15:12 UTC (permalink / raw)
To: netdev
In-Reply-To: <Suresh.Reddy@broadcom.com>
IPv6 TSO requests with extension hdrs are a problem to the
Lancer and BEx chips. Workaround is to disable TSO6 feature
for such packets.
Also in Lancer chips, MSS less than 256 was resulting in TX stall.
Fix this by disabling GSO when MSS less than 256.
Signed-off-by: Suresh Reddy <suresh.reddy@broadcom.com>
---
drivers/net/ethernet/emulex/benet/be.h | 8 ++++++++
drivers/net/ethernet/emulex/benet/be_main.c | 14 ++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index 674cf9d..8984c49 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -930,6 +930,14 @@ static inline bool is_ipv4_pkt(struct sk_buff *skb)
return skb->protocol == htons(ETH_P_IP) && ip_hdr(skb)->version == 4;
}
+static inline bool is_ipv6_ext_hdr(struct sk_buff *skb)
+{
+ if (ip_hdr(skb)->version == 6)
+ return ipv6_ext_hdr(ipv6_hdr(skb)->nexthdr);
+ else
+ return false;
+}
+
#define be_error_recovering(adapter) \
(adapter->flags & BE_FLAGS_TRY_RECOVERY)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 319eee3..0e3d9f39 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -5089,6 +5089,20 @@ static netdev_features_t be_features_check(struct sk_buff *skb,
struct be_adapter *adapter = netdev_priv(dev);
u8 l4_hdr = 0;
+ if (skb_is_gso(skb)) {
+ /* IPv6 TSO requests with extension hdrs are a problem
+ * to Lancer and BE3 HW. Disable TSO6 feature.
+ */
+ if (!skyhawk_chip(adapter) && is_ipv6_ext_hdr(skb))
+ features &= ~NETIF_F_TSO6;
+
+ /* Lancer cannot handle the packet with MSS less than 256.
+ * Disable the GSO support in such cases
+ */
+ if (lancer_chip(adapter) && skb_shinfo(skb)->gso_size < 256)
+ features &= ~NETIF_F_GSO_MASK;
+ }
+
/* The code below restricts offload features for some tunneled and
* Q-in-Q packets.
* Offload features for normal (non tunnel) packets are unchanged.
--
1.8.3.1
^ permalink raw reply related
* HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Denys Fedoryshchenko @ 2017-09-13 15:20 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hi,
I noticed after increasing bandwidth over some amount HTB started to
throttle classes it should not throttle.
Also estimated rate in htb totally wrong, while byte counters is
correct.
Is there any overflow or something?
X520 card (but XL710 same)
br1 8000.90e2ba86c38c no eth3.1777
eth3.777
br2 8000.90e2ba86c38d no eth3.360
eth3.361
Inbound traffic is coming over one vlan, leaving another vlan.
Shaper is just bunch of classes and u32 filters, with few fw filters.
qdisc is pie
I put totally high values to not reach them, tried to change
quantum/burst/cburst but... stats below.
First, "root" class is 1:1 showing rate 18086Mbit, which is physically
impossible.
Class 1:111 showing 5355Mbit, while real traffic is ~1.5Gbit
shaper /etc # tc -s -d class show dev eth3.777 classid 1:111;sleep 5;tc
-s -d class show dev eth3.777 classid 1:111
class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 6487632263 bytes 5235525 pkt (dropped 0, overlimits 0 requeues 0)
rate 5529Mbit 557534pps backlog 0b 0p requeues 0
lended: 2423323 borrowed: 0 giants: 0
tokens: 124 ctokens: -1
class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 7438601731 bytes 6003811 pkt (dropped 0, overlimits 0 requeues 0)
rate 5631Mbit 568214pps backlog 36624b 8p requeues 0
lended: 2772486 borrowed: 0 giants: 0
tokens: 124 ctokens: -1
(7438601731-6487632263)/5*8 = 1.521.551.148
And most important some classes suffering, while they should not (not
reaching limits)
class htb 1:95 parent 1:1 leaf 95: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 13556762059 bytes 17474559 pkt (dropped 16017, overlimits 0
requeues 0)
rate 2524Mbit 414197pps backlog 31969245b 34513p requeues 0
lended: 13995723 borrowed: 0 giants: 0
tokens: 111 ctokens: -2
Full classes stats:
class htb 1:100 parent 1:1 leaf 100: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 116 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
rate 8bit 0pps backlog 0b 0p requeues 0
lended: 2 borrowed: 0 giants: 0
tokens: 124 ctokens: -1
class htb 1:120 parent 1:1 leaf 120: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 531230043 bytes 782130 pkt (dropped 0, overlimits 0 requeues 0)
rate 132274Kbit 25240pps backlog 0b 0p requeues 0
lended: 540693 borrowed: 0 giants: 0
tokens: 109 ctokens: -2
class htb 1:50 parent 1:1 leaf 50: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 773472109 bytes 587335 pkt (dropped 0, overlimits 0 requeues 0)
rate 215929Kbit 20503pps backlog 0b 0p requeues 0
lended: 216614 borrowed: 0 giants: 0
tokens: 91 ctokens: -4
class htb 1:70 parent 1:1 leaf 70: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 1574768 bytes 6194 pkt (dropped 0, overlimits 0 requeues 0)
rate 406272bit 214pps backlog 0b 0p requeues 0
lended: 5758 borrowed: 0 giants: 0
tokens: 101 ctokens: -3
class htb 1:90 parent 1:1 leaf 90: prio 0 quantum 50000 rate 1Kbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 3206 bytes 53 pkt (dropped 0, overlimits 0 requeues 0)
rate 848bit 1pps backlog 0b 0p requeues 0
lended: 53 borrowed: 0 giants: 0
class htb 1:110 parent 1:1 leaf 110: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 17205952113 bytes 12926008 pkt (dropped 239, overlimits 0 requeues
0)
rate 4433Mbit 416825pps backlog 5847785b 2394p requeues 0
lended: 7021696 borrowed: 0 giants: 0
tokens: 91 ctokens: -4
class htb 1:45 root leaf 45: prio 0 quantum 50000 rate 80Mbit ceil
80Mbit linklayer ethernet burst 10000b/1 mpu 0b cburst 10000b/1 mpu 0b
level 0
Sent 2586 bytes 45 pkt (dropped 0, overlimits 0 requeues 0)
rate 456bit 1pps backlog 0b 0p requeues 0
lended: 45 borrowed: 0 giants: 0
tokens: 15540 ctokens: 15540
class htb 1:1 root rate 100Gbit ceil 100Gbit linklayer ethernet burst
0b/1 mpu 0b cburst 0b/1 mpu 0b level 7
Sent 72277215121 bytes 72693012 pkt (dropped 0, overlimits 0 requeues
0)
rate 18086Mbit 2304729pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: -4 ctokens: -4
class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 21977384237 bytes 17697345 pkt (dropped 391, overlimits 0 requeues
0)
rate 5355Mbit 543216pps backlog 41746345b 14743p requeues 0
lended: 8837667 borrowed: 0 giants: 0
tokens: 124 ctokens: -1
class htb 1:200 parent 1:1 leaf 200: prio 0 quantum 50000 rate 10Gbit
ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 9209112058 bytes 10941655 pkt (dropped 5396413, overlimits 0
requeues 0)
rate 2142Mbit 326938pps backlog 20798724b 25717p requeues 0
lended: 9926866 borrowed: 0 giants: 0
tokens: 108 ctokens: -2
class htb 1:20 parent 1:1 leaf 20: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 1504918577 bytes 1170037 pkt (dropped 0, overlimits 0 requeues 0)
rate 413892Kbit 40322pps backlog 0b 0p requeues 0
lended: 497069 borrowed: 0 giants: 0
tokens: 92 ctokens: -4
class htb 1:40 parent 1:1 leaf 40: prio 0 quantum 50000 rate 1Gbit ceil
1Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 10000b/1 mpu 0b
level 0
Sent 8638241052 bytes 9526035 pkt (dropped 0, overlimits 0 requeues 0)
rate 2442Mbit 333804pps backlog 0b 0p requeues 0
lended: 6947694 borrowed: 0 giants: 0
tokens: 1064 ctokens: 1064
class htb 1:60 parent 1:1 leaf 60: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 3124889750 bytes 6972789 pkt (dropped 5833, overlimits 0 requeues
0)
rate 824981Kbit 233296pps backlog 616b 3p requeues 0
lended: 6701559 borrowed: 0 giants: 0
tokens: 122 ctokens: -1
class htb 1:25 parent 1:1 leaf 25: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 3275 bytes 57 pkt (dropped 0, overlimits 0 requeues 0)
rate 504bit 1pps backlog 0b 0p requeues 0
lended: 57 borrowed: 0 giants: 0
tokens: 123 ctokens: -1
class htb 1:80 parent 1:1 leaf 80: prio 0 quantum 50000 rate 10Gbit ceil
100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu 0b
level 0
Sent 2598 bytes 45 pkt (dropped 0, overlimits 0 requeues 0)
rate 672bit 1pps backlog 0b 0p requeues 0
lended: 45 borrowed: 0 giants: 0
tokens: 124 ctokens: -1
tc -s -d qdisc show dev eth3.777
qdisc htb 1: root refcnt 2 r2q 10 default 200 direct_packets_stat 6858
ver 3.17 direct_qlen 1000
Sent 185271955178 bytes 186767377 pkt (dropped 14248387, overlimits 0
requeues 0)
backlog 62369772b 68728p requeues 0
qdisc pie 120: parent 1:120 limit 40000p target 200.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 1532094051 bytes 2108158 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 1424069 overlimit 0 dropped 0 maxq 96 ecn_mark 0
qdisc pie 95: parent 1:95 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 24359099839 bytes 31531160 pkt (dropped 36527, overlimits 0
requeues 0)
backlog 27116831b 28680p requeues 0
prob 0.000000 delay 82019us avg_dq_rate 96252441
pkts_in 25249681 overlimit 2107 dropped 36527 maxq 39999 ecn_mark 0
qdisc pie 80: parent 1:80 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 19695 bytes 317 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 317 overlimit 0 dropped 0 maxq 1 ecn_mark 0
qdisc pie 111: parent 1:111 limit 40000p target 200.0ms tupdate 300.0ms
alpha 2 beta 20
Sent 57513872600 bytes 46387754 pkt (dropped 0, overlimits 0 requeues
0)
backlog 126218b 49p requeues 0
prob 0.000000 delay 227us avg_dq_rate 184143066
qdisc pie 100: parent 1:100 limit 40000p target 200.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 494 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 9 overlimit 0 dropped 0 maxq 0 ecn_mark 0
qdisc pie 60: parent 1:60 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 8749993535 bytes 18718111 pkt (dropped 0, overlimits 0 requeues 0)
backlog 7875b 14p requeues 0
prob 0.000000 delay 98us avg_dq_rate 0
pkts_in 17978754 overlimit 0 dropped 0 maxq 281 ecn_mark 0
qdisc pie 25: parent 1:25 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 9412 bytes 135 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 135 overlimit 0 dropped 0 maxq 0 ecn_mark 0
qdisc pie 200: parent 1:200 limit 40000p target 50.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 22224392951 bytes 26861660 pkt (dropped 14211817, overlimits 0
requeues 0)
backlog 35124441b 39999p requeues 0
prob 0.000071 delay 23747us avg_dq_rate 66040039
pkts_in 25266532 overlimit 14160730 dropped 14211817 maxq 39999 ecn_mark
0
qdisc pie 90: parent 1:90 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 7396 bytes 134 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 134 overlimit 0 dropped 0 maxq 0 ecn_mark 0
qdisc pie 40: parent 1:40 limit 40000p target 200.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 21316494470 bytes 23786396 pkt (dropped 0, overlimits 0 requeues
0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 2085892079
pkts_in 17465291 overlimit 0 dropped 0 maxq 184 ecn_mark 0
qdisc pie 110: parent 1:110 limit 40000p target 200.0ms tupdate 300.0ms
alpha 2 beta 20
Sent 44081304635 bytes 33108042 pkt (dropped 0, overlimits 0 requeues
0)
backlog 0b 0p requeues 0
prob 0.000000 delay 47us avg_dq_rate 201721191
pkts_in 17602600 overlimit 0 dropped 0 maxq 157 ecn_mark 0
qdisc pie 70: parent 1:70 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 4992265 bytes 16959 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 15448 overlimit 0 dropped 0 maxq 3 ecn_mark 0
qdisc pie 20: parent 1:20 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20
Sent 3475884019 bytes 2717342 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 1186311 overlimit 0 dropped 0 maxq 41 ecn_mark 0
qdisc pie 50: parent 1:50 limit 40000p target 250.0ms tupdate 30.0ms
alpha 2 beta 20 ecn
Sent 1994354891 bytes 1511636 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
prob 0.000000 delay 0us avg_dq_rate 0
pkts_in 561648 overlimit 0 dropped 0 maxq 27 ecn_mark 0
More info about setup:
shaper /etc # ethtool -k eth3
Features for eth3:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: on [fixed]
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on [fixed]
tx-gre-segmentation: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: on
tx-ipxip6-segmentation: on
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off
hw-tc-offload: off
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
shaper /etc # ethtool -k eth3.777
Features for eth3.777:
rx-checksumming: off [fixed]
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: on
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [requested on]
tcp-segmentation-offload: off
tx-tcp-segmentation: off
tx-tcp-ecn-segmentation: off
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: off
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: on [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: on
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: on
tx-esp-segmentation: off [fixed]
fcoe-mtu: off [requested on]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
shaper /etc # ethtool -i eth3
driver: ixgbe
version: 5.0.0-k
firmware-version: 0x2b2c0001
expansion-rom-version:
bus-info: 0000:06:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
mpstat -P ALL 10
Linux 4.12.9-build-0132 (shaper) 09/13/17 _x86_64_ (32 CPU)
18:15:55 CPU %usr %nice %sys %iowait %irq %soft %steal
%guest %idle
18:16:05 all 0.00 0.00 0.00 0.00 0.00 0.63 0.00
0.00 99.37
18:16:05 0 0.00 0.00 0.13 0.00 0.00 0.13 0.00
0.00 99.73
18:16:05 1 0.00 0.00 0.00 0.00 0.00 1.34 0.00
0.00 98.66
18:16:05 2 0.00 0.00 0.00 0.00 0.00 1.32 0.00
0.00 98.68
18:16:05 3 0.00 0.00 0.00 0.00 0.00 1.81 0.00
0.00 98.19
18:16:05 4 0.00 0.00 0.00 0.00 0.00 1.78 0.00
0.00 98.22
18:16:05 5 0.00 0.00 0.00 0.00 0.00 1.77 0.00
0.00 98.23
18:16:05 6 0.00 0.00 0.00 0.00 0.00 1.77 0.00
0.00 98.23
18:16:05 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 8 0.00 0.00 0.00 0.00 0.00 0.15 0.00
0.00 99.85
18:16:05 9 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 10 0.00 0.00 0.00 0.00 0.00 0.15 0.00
0.00 99.85
18:16:05 11 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 12 0.00 0.00 0.00 0.00 0.00 0.48 0.00
0.00 99.52
18:16:05 13 0.00 0.00 0.00 0.00 0.00 0.59 0.00
0.00 99.41
18:16:05 14 0.00 0.00 0.00 0.00 0.00 1.30 0.00
0.00 98.70
18:16:05 15 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 16 0.00 0.00 0.00 0.00 0.00 0.12 0.00
0.00 99.88
18:16:05 17 0.00 0.00 0.00 0.00 0.00 0.82 0.00
0.00 99.18
18:16:05 18 0.00 0.00 0.00 0.00 0.00 0.71 0.00
0.00 99.29
18:16:05 19 0.00 0.00 0.00 0.00 0.00 0.71 0.00
0.00 99.29
18:16:05 20 0.00 0.00 0.00 0.00 0.00 0.72 0.00
0.00 99.28
18:16:05 21 0.00 0.00 0.00 0.00 0.00 0.59 0.00
0.00 99.41
18:16:05 22 0.00 0.00 0.00 0.00 0.00 1.30 0.00
0.00 98.70
18:16:05 23 0.00 0.00 0.00 0.00 0.00 1.18 0.00
0.00 98.82
18:16:05 24 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 25 0.00 0.00 0.00 0.00 0.00 0.84 0.00
0.00 99.16
18:16:05 26 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 27 0.00 0.00 0.00 0.00 0.00 0.85 0.00
0.00 99.15
18:16:05 28 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 29 0.00 0.00 0.12 0.00 0.00 0.12 0.00
0.00 99.76
18:16:05 30 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
18:16:05 31 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 100.00
^ permalink raw reply
* [PATCH stable-3.16 1/3] VSOCK: sock_put wasn't safe to call in interrupt context
From: Michal Hocko @ 2017-09-13 15:23 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: Aditya Sarwade, Thomas Hellstrom, Petr Masik, Ben Hutchings,
Sasha Levin, netdev, Stable tree, LKML
In-Reply-To: <20170913151939.gf7n6rvvjtz47tz7@dhcp22.suse.cz>
From: Jorgen Hansen <jhansen@vmware.com>
commit 4ef7ea9195ea73262cd9730fb54e1eb726da157b upstream.
In the vsock vmci_transport driver, sock_put wasn't safe to call
in interrupt context, since that may call the vsock destructor
which in turn calls several functions that should only be called
from process context. This change defers the callling of these
functions to a worker thread. All these functions were
deallocation of resources related to the transport itself.
Furthermore, an unused callback was removed to simplify the
cleanup.
Multiple customers have been hitting this issue when using
VMware tools on vSphere 2015.
Also added a version to the vmci transport module (starting from
1.0.2.0-k since up until now it appears that this module was
sharing version with vsock that is currently at 1.0.1.0-k).
Reviewed-by: Aditya Asarwade <asarwade@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
net/vmw_vsock/vmci_transport.c | 173 ++++++++++++++++++++---------------------
net/vmw_vsock/vmci_transport.h | 4 +-
2 files changed, 86 insertions(+), 91 deletions(-)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 9bb63ffec4f2..aed136d27b01 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -40,13 +40,11 @@
static int vmci_transport_recv_dgram_cb(void *data, struct vmci_datagram *dg);
static int vmci_transport_recv_stream_cb(void *data, struct vmci_datagram *dg);
-static void vmci_transport_peer_attach_cb(u32 sub_id,
- const struct vmci_event_data *ed,
- void *client_data);
static void vmci_transport_peer_detach_cb(u32 sub_id,
const struct vmci_event_data *ed,
void *client_data);
static void vmci_transport_recv_pkt_work(struct work_struct *work);
+static void vmci_transport_cleanup(struct work_struct *work);
static int vmci_transport_recv_listen(struct sock *sk,
struct vmci_transport_packet *pkt);
static int vmci_transport_recv_connecting_server(
@@ -75,6 +73,10 @@ struct vmci_transport_recv_pkt_info {
struct vmci_transport_packet pkt;
};
+static LIST_HEAD(vmci_transport_cleanup_list);
+static DEFINE_SPINLOCK(vmci_transport_cleanup_lock);
+static DECLARE_WORK(vmci_transport_cleanup_work, vmci_transport_cleanup);
+
static struct vmci_handle vmci_transport_stream_handle = { VMCI_INVALID_ID,
VMCI_INVALID_ID };
static u32 vmci_transport_qp_resumed_sub_id = VMCI_INVALID_ID;
@@ -791,44 +793,6 @@ static int vmci_transport_recv_stream_cb(void *data, struct vmci_datagram *dg)
return err;
}
-static void vmci_transport_peer_attach_cb(u32 sub_id,
- const struct vmci_event_data *e_data,
- void *client_data)
-{
- struct sock *sk = client_data;
- const struct vmci_event_payload_qp *e_payload;
- struct vsock_sock *vsk;
-
- e_payload = vmci_event_data_const_payload(e_data);
-
- vsk = vsock_sk(sk);
-
- /* We don't ask for delayed CBs when we subscribe to this event (we
- * pass 0 as flags to vmci_event_subscribe()). VMCI makes no
- * guarantees in that case about what context we might be running in,
- * so it could be BH or process, blockable or non-blockable. So we
- * need to account for all possible contexts here.
- */
- local_bh_disable();
- bh_lock_sock(sk);
-
- /* XXX This is lame, we should provide a way to lookup sockets by
- * qp_handle.
- */
- if (vmci_handle_is_equal(vmci_trans(vsk)->qp_handle,
- e_payload->handle)) {
- /* XXX This doesn't do anything, but in the future we may want
- * to set a flag here to verify the attach really did occur and
- * we weren't just sent a datagram claiming it was.
- */
- goto out;
- }
-
-out:
- bh_unlock_sock(sk);
- local_bh_enable();
-}
-
static void vmci_transport_handle_detach(struct sock *sk)
{
struct vsock_sock *vsk;
@@ -871,28 +835,38 @@ static void vmci_transport_peer_detach_cb(u32 sub_id,
const struct vmci_event_data *e_data,
void *client_data)
{
- struct sock *sk = client_data;
+ struct vmci_transport *trans = client_data;
const struct vmci_event_payload_qp *e_payload;
- struct vsock_sock *vsk;
e_payload = vmci_event_data_const_payload(e_data);
- vsk = vsock_sk(sk);
- if (vmci_handle_is_invalid(e_payload->handle))
- return;
-
- /* Same rules for locking as for peer_attach_cb(). */
- local_bh_disable();
- bh_lock_sock(sk);
/* XXX This is lame, we should provide a way to lookup sockets by
* qp_handle.
*/
- if (vmci_handle_is_equal(vmci_trans(vsk)->qp_handle,
- e_payload->handle))
- vmci_transport_handle_detach(sk);
+ if (vmci_handle_is_invalid(e_payload->handle) ||
+ vmci_handle_is_equal(trans->qp_handle, e_payload->handle))
+ return;
- bh_unlock_sock(sk);
- local_bh_enable();
+ /* We don't ask for delayed CBs when we subscribe to this event (we
+ * pass 0 as flags to vmci_event_subscribe()). VMCI makes no
+ * guarantees in that case about what context we might be running in,
+ * so it could be BH or process, blockable or non-blockable. So we
+ * need to account for all possible contexts here.
+ */
+ spin_lock_bh(&trans->lock);
+ if (!trans->sk)
+ goto out;
+
+ /* Apart from here, trans->lock is only grabbed as part of sk destruct,
+ * where trans->sk isn't locked.
+ */
+ bh_lock_sock(trans->sk);
+
+ vmci_transport_handle_detach(trans->sk);
+
+ bh_unlock_sock(trans->sk);
+ out:
+ spin_unlock_bh(&trans->lock);
}
static void vmci_transport_qp_resumed_cb(u32 sub_id,
@@ -1181,7 +1155,7 @@ vmci_transport_recv_connecting_server(struct sock *listener,
*/
err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_DETACH,
vmci_transport_peer_detach_cb,
- pending, &detach_sub_id);
+ vmci_trans(vpending), &detach_sub_id);
if (err < VMCI_SUCCESS) {
vmci_transport_send_reset(pending, pkt);
err = vmci_transport_error_to_vsock_error(err);
@@ -1321,7 +1295,6 @@ vmci_transport_recv_connecting_client(struct sock *sk,
|| vmci_trans(vsk)->qpair
|| vmci_trans(vsk)->produce_size != 0
|| vmci_trans(vsk)->consume_size != 0
- || vmci_trans(vsk)->attach_sub_id != VMCI_INVALID_ID
|| vmci_trans(vsk)->detach_sub_id != VMCI_INVALID_ID) {
skerr = EPROTO;
err = -EINVAL;
@@ -1389,7 +1362,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
struct vsock_sock *vsk;
struct vmci_handle handle;
struct vmci_qp *qpair;
- u32 attach_sub_id;
u32 detach_sub_id;
bool is_local;
u32 flags;
@@ -1399,7 +1371,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
vsk = vsock_sk(sk);
handle = VMCI_INVALID_HANDLE;
- attach_sub_id = VMCI_INVALID_ID;
detach_sub_id = VMCI_INVALID_ID;
/* If we have gotten here then we should be past the point where old
@@ -1444,23 +1415,15 @@ static int vmci_transport_recv_connecting_client_negotiate(
goto destroy;
}
- /* Subscribe to attach and detach events first.
+ /* Subscribe to detach events first.
*
* XXX We attach once for each queue pair created for now so it is easy
* to find the socket (it's provided), but later we should only
* subscribe once and add a way to lookup sockets by queue pair handle.
*/
- err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_ATTACH,
- vmci_transport_peer_attach_cb,
- sk, &attach_sub_id);
- if (err < VMCI_SUCCESS) {
- err = vmci_transport_error_to_vsock_error(err);
- goto destroy;
- }
-
err = vmci_event_subscribe(VMCI_EVENT_QP_PEER_DETACH,
vmci_transport_peer_detach_cb,
- sk, &detach_sub_id);
+ vmci_trans(vsk), &detach_sub_id);
if (err < VMCI_SUCCESS) {
err = vmci_transport_error_to_vsock_error(err);
goto destroy;
@@ -1496,7 +1459,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
vmci_trans(vsk)->produce_size = vmci_trans(vsk)->consume_size =
pkt->u.size;
- vmci_trans(vsk)->attach_sub_id = attach_sub_id;
vmci_trans(vsk)->detach_sub_id = detach_sub_id;
vmci_trans(vsk)->notify_ops->process_negotiate(sk);
@@ -1504,9 +1466,6 @@ static int vmci_transport_recv_connecting_client_negotiate(
return 0;
destroy:
- if (attach_sub_id != VMCI_INVALID_ID)
- vmci_event_unsubscribe(attach_sub_id);
-
if (detach_sub_id != VMCI_INVALID_ID)
vmci_event_unsubscribe(detach_sub_id);
@@ -1607,9 +1566,11 @@ static int vmci_transport_socket_init(struct vsock_sock *vsk,
vmci_trans(vsk)->qp_handle = VMCI_INVALID_HANDLE;
vmci_trans(vsk)->qpair = NULL;
vmci_trans(vsk)->produce_size = vmci_trans(vsk)->consume_size = 0;
- vmci_trans(vsk)->attach_sub_id = vmci_trans(vsk)->detach_sub_id =
- VMCI_INVALID_ID;
+ vmci_trans(vsk)->detach_sub_id = VMCI_INVALID_ID;
vmci_trans(vsk)->notify_ops = NULL;
+ INIT_LIST_HEAD(&vmci_trans(vsk)->elem);
+ vmci_trans(vsk)->sk = &vsk->sk;
+ vmci_trans(vsk)->lock = __SPIN_LOCK_UNLOCKED(vmci_trans(vsk)->lock);
if (psk) {
vmci_trans(vsk)->queue_pair_size =
vmci_trans(psk)->queue_pair_size;
@@ -1629,29 +1590,57 @@ static int vmci_transport_socket_init(struct vsock_sock *vsk,
return 0;
}
-static void vmci_transport_destruct(struct vsock_sock *vsk)
+static void vmci_transport_free_resources(struct list_head *transport_list)
{
- if (vmci_trans(vsk)->attach_sub_id != VMCI_INVALID_ID) {
- vmci_event_unsubscribe(vmci_trans(vsk)->attach_sub_id);
- vmci_trans(vsk)->attach_sub_id = VMCI_INVALID_ID;
- }
+ while (!list_empty(transport_list)) {
+ struct vmci_transport *transport =
+ list_first_entry(transport_list, struct vmci_transport,
+ elem);
+ list_del(&transport->elem);
- if (vmci_trans(vsk)->detach_sub_id != VMCI_INVALID_ID) {
- vmci_event_unsubscribe(vmci_trans(vsk)->detach_sub_id);
- vmci_trans(vsk)->detach_sub_id = VMCI_INVALID_ID;
- }
+ if (transport->detach_sub_id != VMCI_INVALID_ID) {
+ vmci_event_unsubscribe(transport->detach_sub_id);
+ transport->detach_sub_id = VMCI_INVALID_ID;
+ }
- if (!vmci_handle_is_invalid(vmci_trans(vsk)->qp_handle)) {
- vmci_qpair_detach(&vmci_trans(vsk)->qpair);
- vmci_trans(vsk)->qp_handle = VMCI_INVALID_HANDLE;
- vmci_trans(vsk)->produce_size = 0;
- vmci_trans(vsk)->consume_size = 0;
+ if (!vmci_handle_is_invalid(transport->qp_handle)) {
+ vmci_qpair_detach(&transport->qpair);
+ transport->qp_handle = VMCI_INVALID_HANDLE;
+ transport->produce_size = 0;
+ transport->consume_size = 0;
+ }
+
+ kfree(transport);
}
+}
+
+static void vmci_transport_cleanup(struct work_struct *work)
+{
+ LIST_HEAD(pending);
+
+ spin_lock_bh(&vmci_transport_cleanup_lock);
+ list_replace_init(&vmci_transport_cleanup_list, &pending);
+ spin_unlock_bh(&vmci_transport_cleanup_lock);
+ vmci_transport_free_resources(&pending);
+}
+
+static void vmci_transport_destruct(struct vsock_sock *vsk)
+{
+ /* Ensure that the detach callback doesn't use the sk/vsk
+ * we are about to destruct.
+ */
+ spin_lock_bh(&vmci_trans(vsk)->lock);
+ vmci_trans(vsk)->sk = NULL;
+ spin_unlock_bh(&vmci_trans(vsk)->lock);
if (vmci_trans(vsk)->notify_ops)
vmci_trans(vsk)->notify_ops->socket_destruct(vsk);
- kfree(vsk->trans);
+ spin_lock_bh(&vmci_transport_cleanup_lock);
+ list_add(&vmci_trans(vsk)->elem, &vmci_transport_cleanup_list);
+ spin_unlock_bh(&vmci_transport_cleanup_lock);
+ schedule_work(&vmci_transport_cleanup_work);
+
vsk->trans = NULL;
}
@@ -2148,6 +2137,9 @@ module_init(vmci_transport_init);
static void __exit vmci_transport_exit(void)
{
+ cancel_work_sync(&vmci_transport_cleanup_work);
+ vmci_transport_free_resources(&vmci_transport_cleanup_list);
+
if (!vmci_handle_is_invalid(vmci_transport_stream_handle)) {
if (vmci_datagram_destroy_handle(
vmci_transport_stream_handle) != VMCI_SUCCESS)
@@ -2166,6 +2158,7 @@ module_exit(vmci_transport_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMCI transport for Virtual Sockets");
+MODULE_VERSION("1.0.2.0-k");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("vmware_vsock");
MODULE_ALIAS_NETPROTO(PF_VSOCK);
diff --git a/net/vmw_vsock/vmci_transport.h b/net/vmw_vsock/vmci_transport.h
index ce6c9623d5f0..2ad46f39649f 100644
--- a/net/vmw_vsock/vmci_transport.h
+++ b/net/vmw_vsock/vmci_transport.h
@@ -119,10 +119,12 @@ struct vmci_transport {
u64 queue_pair_size;
u64 queue_pair_min_size;
u64 queue_pair_max_size;
- u32 attach_sub_id;
u32 detach_sub_id;
union vmci_transport_notify notify;
struct vmci_transport_notify_ops *notify_ops;
+ struct list_head elem;
+ struct sock *sk;
+ spinlock_t lock; /* protects sk. */
};
int vmci_transport_register(void);
--
2.14.1
^ permalink raw reply related
* [PATCH stable-3.16 2/3] VSOCK: Fix lockdep issue.
From: Michal Hocko @ 2017-09-13 15:23 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: Aditya Sarwade, Thomas Hellstrom, Petr Masik, Ben Hutchings,
Sasha Levin, netdev, Stable tree, LKML
In-Reply-To: <20170913152307.20317-1-mhocko@kernel.org>
From: Jorgen Hansen <jhansen@vmware.com>
commit 8566b86ab9f0f45bc6f7dd422b21de9d0cf5415a upstream.
The recent fix for the vsock sock_put issue used the wrong
initializer for the transport spin_lock causing an issue when
running with lockdep checking.
Testing: Verified fix on kernel with lockdep enabled.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
net/vmw_vsock/vmci_transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index aed136d27b01..314312272e08 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -1570,7 +1570,7 @@ static int vmci_transport_socket_init(struct vsock_sock *vsk,
vmci_trans(vsk)->notify_ops = NULL;
INIT_LIST_HEAD(&vmci_trans(vsk)->elem);
vmci_trans(vsk)->sk = &vsk->sk;
- vmci_trans(vsk)->lock = __SPIN_LOCK_UNLOCKED(vmci_trans(vsk)->lock);
+ spin_lock_init(&vmci_trans(vsk)->lock);
if (psk) {
vmci_trans(vsk)->queue_pair_size =
vmci_trans(psk)->queue_pair_size;
--
2.14.1
^ permalink raw reply related
* [PATCH stable-3.16 3/3] VSOCK: Detach QP check should filter out non matching QPs.
From: Michal Hocko @ 2017-09-13 15:23 UTC (permalink / raw)
To: Jorgen S. Hansen
Cc: Aditya Sarwade, Thomas Hellstrom, Petr Masik, Ben Hutchings,
Sasha Levin, netdev, Stable tree, LKML
In-Reply-To: <20170913152307.20317-1-mhocko@kernel.org>
From: Jorgen Hansen <jhansen@vmware.com>
commit 8ab18d71de8b07d2c4d6f984b718418c09ea45c5 upstream.
The check in vmci_transport_peer_detach_cb should only allow a
detach when the qp handle of the transport matches the one in
the detach message.
Testing: Before this change, a detach from a peer on a different
socket would cause an active stream socket to register a detach.
Reviewed-by: George Zhang <georgezhang@vmware.com>
Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Michal Hocko <mhocko@suse.com>
---
net/vmw_vsock/vmci_transport.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
index 314312272e08..c69c990ec4a2 100644
--- a/net/vmw_vsock/vmci_transport.c
+++ b/net/vmw_vsock/vmci_transport.c
@@ -844,7 +844,7 @@ static void vmci_transport_peer_detach_cb(u32 sub_id,
* qp_handle.
*/
if (vmci_handle_is_invalid(e_payload->handle) ||
- vmci_handle_is_equal(trans->qp_handle, e_payload->handle))
+ !vmci_handle_is_equal(trans->qp_handle, e_payload->handle))
return;
/* We don't ask for delayed CBs when we subscribe to this event (we
@@ -2158,7 +2158,7 @@ module_exit(vmci_transport_exit);
MODULE_AUTHOR("VMware, Inc.");
MODULE_DESCRIPTION("VMCI transport for Virtual Sockets");
-MODULE_VERSION("1.0.2.0-k");
+MODULE_VERSION("1.0.3.0-k");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("vmware_vsock");
MODULE_ALIAS_NETPROTO(PF_VSOCK);
--
2.14.1
^ permalink raw reply related
* [patch net] net: sched: fix use-after-free in tcf_action_destroy and tcf_del_walker
From: Jiri Pirko @ 2017-09-13 15:32 UTC (permalink / raw)
To: netdev; +Cc: davem, jhs, xiyou.wangcong, kubakici, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
Recent commit d7fb60b9cafb ("net_sched: get rid of tcfa_rcu") removed
freeing in call_rcu, which changed already existing hard-to-hit
race condition into 100% hit:
[ 598.599825] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[ 598.607782] IP: tcf_action_destroy+0xc0/0x140
Or:
[ 40.858924] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[ 40.862840] IP: tcf_generic_walker+0x534/0x820
Fix this by storing the ops and use them directly for module_put call.
Fixes: a85a970af265 ("net_sched: move tc_action into tcf_common")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/sched/act_api.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index fcd7dc7..da6fa82 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -180,7 +180,7 @@ static int tcf_del_walker(struct tcf_idrinfo *idrinfo, struct sk_buff *skb,
idr_for_each_entry_ext(idr, p, id) {
ret = __tcf_idr_release(p, false, true);
if (ret == ACT_P_DELETED) {
- module_put(p->ops->owner);
+ module_put(ops->owner);
n_i++;
} else if (ret < 0) {
goto nla_put_failure;
@@ -514,13 +514,15 @@ EXPORT_SYMBOL(tcf_action_exec);
int tcf_action_destroy(struct list_head *actions, int bind)
{
+ const struct tc_action_ops *ops;
struct tc_action *a, *tmp;
int ret = 0;
list_for_each_entry_safe(a, tmp, actions, list) {
+ ops = a->ops;
ret = __tcf_idr_release(a, bind, true);
if (ret == ACT_P_DELETED)
- module_put(a->ops->owner);
+ module_put(ops->owner);
else if (ret < 0)
return ret;
}
--
2.9.3
^ permalink raw reply related
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Denys Fedoryshchenko @ 2017-09-13 15:34 UTC (permalink / raw)
To: Linux Kernel Network Developers
In-Reply-To: <4cd23914d8cc2cf5caf78cb5654fb245@nuclearcat.com>
Well, probably i am answering my own question, removing estimator from
classes seems drastically improve situation.
It seems estimator has some issues that cause shaper to behave
incorrectly (throttling traffic while it should not).
But i guess thats a bug?
As i was not able to predict such bottleneck by CPU load measurements.
On 2017-09-13 18:20, Denys Fedoryshchenko wrote:
> Hi,
>
> I noticed after increasing bandwidth over some amount HTB started to
> throttle classes it should not throttle.
> Also estimated rate in htb totally wrong, while byte counters is
> correct.
>
> Is there any overflow or something?
>
> X520 card (but XL710 same)
> br1 8000.90e2ba86c38c no eth3.1777
> eth3.777
> br2 8000.90e2ba86c38d no eth3.360
> eth3.361
>
> Inbound traffic is coming over one vlan, leaving another vlan.
> Shaper is just bunch of classes and u32 filters, with few fw filters.
> qdisc is pie
>
> I put totally high values to not reach them, tried to change
> quantum/burst/cburst but... stats below.
>
> First, "root" class is 1:1 showing rate 18086Mbit, which is
> physically impossible.
>
> Class 1:111 showing 5355Mbit, while real traffic is ~1.5Gbit
>
> shaper /etc # tc -s -d class show dev eth3.777 classid 1:111;sleep
> 5;tc -s -d class show dev eth3.777 classid 1:111
> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 6487632263 bytes 5235525 pkt (dropped 0, overlimits 0 requeues 0)
> rate 5529Mbit 557534pps backlog 0b 0p requeues 0
> lended: 2423323 borrowed: 0 giants: 0
> tokens: 124 ctokens: -1
>
> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 7438601731 bytes 6003811 pkt (dropped 0, overlimits 0 requeues 0)
> rate 5631Mbit 568214pps backlog 36624b 8p requeues 0
> lended: 2772486 borrowed: 0 giants: 0
> tokens: 124 ctokens: -1
>
> (7438601731-6487632263)/5*8 = 1.521.551.148
>
> And most important some classes suffering, while they should not (not
> reaching limits)
> class htb 1:95 parent 1:1 leaf 95: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 13556762059 bytes 17474559 pkt (dropped 16017, overlimits 0
> requeues 0)
> rate 2524Mbit 414197pps backlog 31969245b 34513p requeues 0
> lended: 13995723 borrowed: 0 giants: 0
> tokens: 111 ctokens: -2
>
>
>
>
>
> Full classes stats:
>
> class htb 1:100 parent 1:1 leaf 100: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 116 bytes 2 pkt (dropped 0, overlimits 0 requeues 0)
> rate 8bit 0pps backlog 0b 0p requeues 0
> lended: 2 borrowed: 0 giants: 0
> tokens: 124 ctokens: -1
>
> class htb 1:120 parent 1:1 leaf 120: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 531230043 bytes 782130 pkt (dropped 0, overlimits 0 requeues 0)
> rate 132274Kbit 25240pps backlog 0b 0p requeues 0
> lended: 540693 borrowed: 0 giants: 0
> tokens: 109 ctokens: -2
>
> class htb 1:50 parent 1:1 leaf 50: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 773472109 bytes 587335 pkt (dropped 0, overlimits 0 requeues 0)
> rate 215929Kbit 20503pps backlog 0b 0p requeues 0
> lended: 216614 borrowed: 0 giants: 0
> tokens: 91 ctokens: -4
>
> class htb 1:70 parent 1:1 leaf 70: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 1574768 bytes 6194 pkt (dropped 0, overlimits 0 requeues 0)
> rate 406272bit 214pps backlog 0b 0p requeues 0
> lended: 5758 borrowed: 0 giants: 0
> tokens: 101 ctokens: -3
>
> class htb 1:90 parent 1:1 leaf 90: prio 0 quantum 50000 rate 1Kbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 3206 bytes 53 pkt (dropped 0, overlimits 0 requeues 0)
> rate 848bit 1pps backlog 0b 0p requeues 0
> lended: 53 borrowed: 0 giants: 0
>
> class htb 1:110 parent 1:1 leaf 110: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 17205952113 bytes 12926008 pkt (dropped 239, overlimits 0
> requeues 0)
> rate 4433Mbit 416825pps backlog 5847785b 2394p requeues 0
> lended: 7021696 borrowed: 0 giants: 0
> tokens: 91 ctokens: -4
>
> class htb 1:45 root leaf 45: prio 0 quantum 50000 rate 80Mbit ceil
> 80Mbit linklayer ethernet burst 10000b/1 mpu 0b cburst 10000b/1 mpu 0b
> level 0
> Sent 2586 bytes 45 pkt (dropped 0, overlimits 0 requeues 0)
> rate 456bit 1pps backlog 0b 0p requeues 0
> lended: 45 borrowed: 0 giants: 0
> tokens: 15540 ctokens: 15540
>
> class htb 1:1 root rate 100Gbit ceil 100Gbit linklayer ethernet burst
> 0b/1 mpu 0b cburst 0b/1 mpu 0b level 7
> Sent 72277215121 bytes 72693012 pkt (dropped 0, overlimits 0 requeues
> 0)
> rate 18086Mbit 2304729pps backlog 0b 0p requeues 0
> lended: 0 borrowed: 0 giants: 0
> tokens: -4 ctokens: -4
>
> class htb 1:111 parent 1:1 leaf 111: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 21977384237 bytes 17697345 pkt (dropped 391, overlimits 0
> requeues 0)
> rate 5355Mbit 543216pps backlog 41746345b 14743p requeues 0
> lended: 8837667 borrowed: 0 giants: 0
> tokens: 124 ctokens: -1
>
> class htb 1:200 parent 1:1 leaf 200: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 9209112058 bytes 10941655 pkt (dropped 5396413, overlimits 0
> requeues 0)
> rate 2142Mbit 326938pps backlog 20798724b 25717p requeues 0
> lended: 9926866 borrowed: 0 giants: 0
> tokens: 108 ctokens: -2
>
> class htb 1:20 parent 1:1 leaf 20: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 1504918577 bytes 1170037 pkt (dropped 0, overlimits 0 requeues 0)
> rate 413892Kbit 40322pps backlog 0b 0p requeues 0
> lended: 497069 borrowed: 0 giants: 0
> tokens: 92 ctokens: -4
>
> class htb 1:40 parent 1:1 leaf 40: prio 0 quantum 50000 rate 1Gbit
> ceil 1Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 10000b/1
> mpu 0b level 0
> Sent 8638241052 bytes 9526035 pkt (dropped 0, overlimits 0 requeues 0)
> rate 2442Mbit 333804pps backlog 0b 0p requeues 0
> lended: 6947694 borrowed: 0 giants: 0
> tokens: 1064 ctokens: 1064
>
> class htb 1:60 parent 1:1 leaf 60: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 3124889750 bytes 6972789 pkt (dropped 5833, overlimits 0 requeues
> 0)
> rate 824981Kbit 233296pps backlog 616b 3p requeues 0
> lended: 6701559 borrowed: 0 giants: 0
> tokens: 122 ctokens: -1
>
> class htb 1:25 parent 1:1 leaf 25: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 3275 bytes 57 pkt (dropped 0, overlimits 0 requeues 0)
> rate 504bit 1pps backlog 0b 0p requeues 0
> lended: 57 borrowed: 0 giants: 0
> tokens: 123 ctokens: -1
>
> class htb 1:80 parent 1:1 leaf 80: prio 0 quantum 50000 rate 10Gbit
> ceil 100Gbit linklayer ethernet burst 10000b/1 mpu 0b cburst 0b/1 mpu
> 0b level 0
> Sent 2598 bytes 45 pkt (dropped 0, overlimits 0 requeues 0)
> rate 672bit 1pps backlog 0b 0p requeues 0
> lended: 45 borrowed: 0 giants: 0
> tokens: 124 ctokens: -1
>
> tc -s -d qdisc show dev eth3.777
> qdisc htb 1: root refcnt 2 r2q 10 default 200 direct_packets_stat 6858
> ver 3.17 direct_qlen 1000
> Sent 185271955178 bytes 186767377 pkt (dropped 14248387, overlimits 0
> requeues 0)
> backlog 62369772b 68728p requeues 0
> qdisc pie 120: parent 1:120 limit 40000p target 200.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 1532094051 bytes 2108158 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 1424069 overlimit 0 dropped 0 maxq 96 ecn_mark 0
>
> qdisc pie 95: parent 1:95 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 24359099839 bytes 31531160 pkt (dropped 36527, overlimits 0
> requeues 0)
> backlog 27116831b 28680p requeues 0
> prob 0.000000 delay 82019us avg_dq_rate 96252441
> pkts_in 25249681 overlimit 2107 dropped 36527 maxq 39999 ecn_mark 0
>
> qdisc pie 80: parent 1:80 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 19695 bytes 317 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 317 overlimit 0 dropped 0 maxq 1 ecn_mark 0
>
> qdisc pie 111: parent 1:111 limit 40000p target 200.0ms tupdate
> 300.0ms alpha 2 beta 20
> Sent 57513872600 bytes 46387754 pkt (dropped 0, overlimits 0 requeues
> 0)
> backlog 126218b 49p requeues 0
> prob 0.000000 delay 227us avg_dq_rate 184143066
>
> qdisc pie 100: parent 1:100 limit 40000p target 200.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 494 bytes 9 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 9 overlimit 0 dropped 0 maxq 0 ecn_mark 0
>
> qdisc pie 60: parent 1:60 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 8749993535 bytes 18718111 pkt (dropped 0, overlimits 0 requeues
> 0)
> backlog 7875b 14p requeues 0
> prob 0.000000 delay 98us avg_dq_rate 0
> pkts_in 17978754 overlimit 0 dropped 0 maxq 281 ecn_mark 0
>
> qdisc pie 25: parent 1:25 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 9412 bytes 135 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 135 overlimit 0 dropped 0 maxq 0 ecn_mark 0
>
> qdisc pie 200: parent 1:200 limit 40000p target 50.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 22224392951 bytes 26861660 pkt (dropped 14211817, overlimits 0
> requeues 0)
> backlog 35124441b 39999p requeues 0
> prob 0.000071 delay 23747us avg_dq_rate 66040039
> pkts_in 25266532 overlimit 14160730 dropped 14211817 maxq 39999
> ecn_mark
> 0
>
> qdisc pie 90: parent 1:90 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 7396 bytes 134 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 134 overlimit 0 dropped 0 maxq 0 ecn_mark 0
>
> qdisc pie 40: parent 1:40 limit 40000p target 200.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 21316494470 bytes 23786396 pkt (dropped 0, overlimits 0 requeues
> 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 2085892079
> pkts_in 17465291 overlimit 0 dropped 0 maxq 184 ecn_mark 0
>
> qdisc pie 110: parent 1:110 limit 40000p target 200.0ms tupdate
> 300.0ms alpha 2 beta 20
> Sent 44081304635 bytes 33108042 pkt (dropped 0, overlimits 0 requeues
> 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 47us avg_dq_rate 201721191
> pkts_in 17602600 overlimit 0 dropped 0 maxq 157 ecn_mark 0
>
> qdisc pie 70: parent 1:70 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 4992265 bytes 16959 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 15448 overlimit 0 dropped 0 maxq 3 ecn_mark 0
>
> qdisc pie 20: parent 1:20 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20
> Sent 3475884019 bytes 2717342 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 1186311 overlimit 0 dropped 0 maxq 41 ecn_mark 0
>
> qdisc pie 50: parent 1:50 limit 40000p target 250.0ms tupdate 30.0ms
> alpha 2 beta 20 ecn
> Sent 1994354891 bytes 1511636 pkt (dropped 0, overlimits 0 requeues 0)
> backlog 0b 0p requeues 0
> prob 0.000000 delay 0us avg_dq_rate 0
> pkts_in 561648 overlimit 0 dropped 0 maxq 27 ecn_mark 0
>
>
>
> More info about setup:
> shaper /etc # ethtool -k eth3
> Features for eth3:
> rx-checksumming: on
> tx-checksumming: on
> tx-checksum-ipv4: off [fixed]
> tx-checksum-ip-generic: on
> tx-checksum-ipv6: off [fixed]
> tx-checksum-fcoe-crc: on [fixed]
> tx-checksum-sctp: on
> scatter-gather: on
> tx-scatter-gather: on
> tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off
> tx-tcp-ecn-segmentation: off [fixed]
> tx-tcp-mangleid-segmentation: off
> tx-tcp6-segmentation: off
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off
> rx-vlan-offload: on
> tx-vlan-offload: on
> ntuple-filters: off
> receive-hashing: on
> highdma: on [fixed]
> rx-vlan-filter: on
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: on [fixed]
> tx-gre-segmentation: on
> tx-gre-csum-segmentation: on
> tx-ipxip4-segmentation: on
> tx-ipxip6-segmentation: on
> tx-udp_tnl-segmentation: on
> tx-udp_tnl-csum-segmentation: on
> rx-all: off
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off
> hw-tc-offload: off
> esp-hw-offload: off [fixed]
> esp-tx-csum-hw-offload: off [fixed]
> shaper /etc # ethtool -k eth3.777
> Features for eth3.777:
> rx-checksumming: off [fixed]
> tx-checksumming: on
> tx-checksum-ipv4: off [fixed]
> tx-checksum-ip-generic: on
> tx-checksum-ipv6: off [fixed]
> tx-checksum-fcoe-crc: on
> tx-checksum-sctp: on
> scatter-gather: on
> tx-scatter-gather: on
> tx-scatter-gather-fraglist: off [requested on]
> tcp-segmentation-offload: off
> tx-tcp-segmentation: off
> tx-tcp-ecn-segmentation: off
> tx-tcp-mangleid-segmentation: off
> tx-tcp6-segmentation: off
> udp-fragmentation-offload: on
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: on
> rx-vlan-filter: off [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: on [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: on
> tx-gre-segmentation: off [fixed]
> tx-gre-csum-segmentation: off [fixed]
> tx-ipxip4-segmentation: off [fixed]
> tx-ipxip6-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-udp_tnl-csum-segmentation: off [fixed]
> tx-gso-partial: off [fixed]
> tx-sctp-segmentation: on
> tx-esp-segmentation: off [fixed]
> fcoe-mtu: off [requested on]
> tx-nocache-copy: off
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
> l2-fwd-offload: off [fixed]
> hw-tc-offload: off [fixed]
> esp-hw-offload: off [fixed]
> esp-tx-csum-hw-offload: off [fixed]
>
>
> shaper /etc # ethtool -i eth3
> driver: ixgbe
> version: 5.0.0-k
> firmware-version: 0x2b2c0001
> expansion-rom-version:
> bus-info: 0000:06:00.1
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: yes
>
> mpstat -P ALL 10
> Linux 4.12.9-build-0132 (shaper) 09/13/17 _x86_64_ (32 CPU)
>
> 18:15:55 CPU %usr %nice %sys %iowait %irq %soft
> %steal %guest %idle
> 18:16:05 all 0.00 0.00 0.00 0.00 0.00 0.63
> 0.00 0.00 99.37
> 18:16:05 0 0.00 0.00 0.13 0.00 0.00 0.13
> 0.00 0.00 99.73
> 18:16:05 1 0.00 0.00 0.00 0.00 0.00 1.34
> 0.00 0.00 98.66
> 18:16:05 2 0.00 0.00 0.00 0.00 0.00 1.32
> 0.00 0.00 98.68
> 18:16:05 3 0.00 0.00 0.00 0.00 0.00 1.81
> 0.00 0.00 98.19
> 18:16:05 4 0.00 0.00 0.00 0.00 0.00 1.78
> 0.00 0.00 98.22
> 18:16:05 5 0.00 0.00 0.00 0.00 0.00 1.77
> 0.00 0.00 98.23
> 18:16:05 6 0.00 0.00 0.00 0.00 0.00 1.77
> 0.00 0.00 98.23
> 18:16:05 7 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 8 0.00 0.00 0.00 0.00 0.00 0.15
> 0.00 0.00 99.85
> 18:16:05 9 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 10 0.00 0.00 0.00 0.00 0.00 0.15
> 0.00 0.00 99.85
> 18:16:05 11 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 12 0.00 0.00 0.00 0.00 0.00 0.48
> 0.00 0.00 99.52
> 18:16:05 13 0.00 0.00 0.00 0.00 0.00 0.59
> 0.00 0.00 99.41
> 18:16:05 14 0.00 0.00 0.00 0.00 0.00 1.30
> 0.00 0.00 98.70
> 18:16:05 15 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 16 0.00 0.00 0.00 0.00 0.00 0.12
> 0.00 0.00 99.88
> 18:16:05 17 0.00 0.00 0.00 0.00 0.00 0.82
> 0.00 0.00 99.18
> 18:16:05 18 0.00 0.00 0.00 0.00 0.00 0.71
> 0.00 0.00 99.29
> 18:16:05 19 0.00 0.00 0.00 0.00 0.00 0.71
> 0.00 0.00 99.29
> 18:16:05 20 0.00 0.00 0.00 0.00 0.00 0.72
> 0.00 0.00 99.28
> 18:16:05 21 0.00 0.00 0.00 0.00 0.00 0.59
> 0.00 0.00 99.41
> 18:16:05 22 0.00 0.00 0.00 0.00 0.00 1.30
> 0.00 0.00 98.70
> 18:16:05 23 0.00 0.00 0.00 0.00 0.00 1.18
> 0.00 0.00 98.82
> 18:16:05 24 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 25 0.00 0.00 0.00 0.00 0.00 0.84
> 0.00 0.00 99.16
> 18:16:05 26 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 27 0.00 0.00 0.00 0.00 0.00 0.85
> 0.00 0.00 99.15
> 18:16:05 28 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 29 0.00 0.00 0.12 0.00 0.00 0.12
> 0.00 0.00 99.76
> 18:16:05 30 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
> 18:16:05 31 0.00 0.00 0.00 0.00 0.00 0.00
> 0.00 0.00 100.00
^ permalink raw reply
* Re: netfilter: xt_bpf: ABI issue in xt_bpf_info_v1?
From: Willem de Bruijn @ 2017-09-13 15:35 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Shmulik Ladkani, netfilter-devel, Pablo Neira Ayuso,
Network Development, Willem de Bruijn, Rafael Buchbinder,
Shmulik Ladkani, eyal
In-Reply-To: <CAF=yD-LUCCLSXuPNKPgEY695ej+T-2s=zhmw6CJwK6tFyY+_dg@mail.gmail.com>
On Wed, Sep 13, 2017 at 11:05 AM, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Wed, Sep 13, 2017 at 10:22 AM, Jan Engelhardt <jengelh@inai.de> wrote:
>>
>> On Wednesday 2017-09-13 15:24, Shmulik Ladkani wrote:
>>>
>>>One way to fix is to have iptables open the object (using the stored
>>>xt_bpf_info_v1->path), gaining a new process local fd for the object,
>>>just after getting the rules from IPT_SO_GET_ENTRIES.
>>>However we didn't see any other extensions doing something like that in
>>>iptables.
>
> The binary should call bpf_obj_get on the filepath each time. These are
> not regular files, but references to a pinned object in the bpf filesystem.
>
> Blindly passing back the fd received from the kernel is clearly wrong. I'm
> really surprised that I did not run into this problem when I wrote the
> feature.
>
>>>
>>>Another way to solve is to fix the ABI (or have a v2 one), that does NOT
>>>pass the fd from userspace, only the path of the pinned object.
>>>Then, 'bpf_mt_check_v1' will open the file from the given path in order
>>>to get the bpf_prog.
>>
>> But a path has a similar problem like a file descriptor - it is local to a
>> certain mount namespace.
>
> Because these are pinned objects in the bpf filesystem, and there is
> only one of those, it may be possible to lookup the object in the kernel
> without relying on a process-local view of mount points.
It would be preferable to fix this for the existing v1 users as well.
That said, the new bpf identifier feature allows passing a globally
unique id instead of a filepath.
>
>>
>> To load "large" blobs into the kernel, a pointer to user memory is a possible
>> option. The downside is that such extra data is not retrievable from the kernel
>> via the iptables setsockopts anymore - one could work around it with procfs, or
>> just let it be.
>>
>> https://sourceforge.net/p/xtables-addons/xtables-addons/ci/master/tree/extensions/xt_geoip.c
>> line 64+.
^ permalink raw reply
* Re: Memory leaks in conntrack
From: Florian Westphal @ 2017-09-13 15:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Cong Wang, netfilter-devel, Linux Kernel Network Developers
In-Reply-To: <20170913080516.GD25977@breakpoint.cc>
Florian Westphal <fw@strlen.de> wrote:
> Cong Wang <xiyou.wangcong@gmail.com> wrote:
> > While testing my TC filter patches (so not related to conntrack), the
> > following memory leaks are shown up:
> >
> > unreferenced object 0xffff9b19ba551228 (size 128):
> > comm "chronyd", pid 338, jiffies 4294910829 (age 53.188s)
> > hex dump (first 32 bytes):
> > 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> > 00 00 00 00 18 00 00 30 00 00 00 00 00 00 00 00 .......0........
> > backtrace:
> > [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> > [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> > [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> > [<ffffffff9f1ca2db>] __kmalloc_track_caller+0x113/0x146
> > [<ffffffff9f193c3b>] __krealloc+0x4a/0x69
> > [<ffffffff9f948dbd>] nf_ct_ext_add+0xe1/0x145
> > [<ffffffff9f942395>] init_conntrack+0x1f7/0x36e
> > [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> > [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> > [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> > [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> > [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> > [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> > [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> > [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> > [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> > unreferenced object 0xffff9b19a69b3340 (size 336):
> > comm "chronyd", pid 338, jiffies 4294910868 (age 53.032s)
> > hex dump (first 32 bytes):
> > 01 00 00 00 5a 5a 5a 5a 00 00 00 00 ad 4e ad de ....ZZZZ.....N..
> > ff ff ff ff 5a 5a 5a 5a ff ff ff ff ff ff ff ff ....ZZZZ........
> > backtrace:
> > [<ffffffff9f1e1175>] create_object+0x169/0x2aa
> > [<ffffffff9fb77fb2>] kmemleak_alloc+0x25/0x41
> > [<ffffffff9f1c47ed>] slab_post_alloc_hook+0x44/0x65
> > [<ffffffff9f1c7a7d>] kmem_cache_alloc+0xd7/0x1f1
> > [<ffffffff9f941b78>] __nf_conntrack_alloc+0xa2/0x146
> > [<ffffffff9f942250>] init_conntrack+0xb2/0x36e
> > [<ffffffff9f942762>] nf_conntrack_in+0x1d3/0x326
> > [<ffffffff9fa1ea69>] ipv4_conntrack_local+0x4d/0x50
> > [<ffffffff9f93ad70>] nf_hook_slow+0x3c/0x9b
> > [<ffffffff9f9c7999>] nf_hook.constprop.40+0xbe/0xd8
> > [<ffffffff9f9c7ba2>] __ip_local_out+0xb3/0xbf
> > [<ffffffff9f9c7bca>] ip_local_out+0x1c/0x36
> > [<ffffffff9f9c9216>] ip_send_skb+0x19/0x3d
> > [<ffffffff9f9ee3de>] udp_send_skb+0x17e/0x1df
> > [<ffffffff9f9eea37>] udp_sendmsg+0x5a2/0x77c
> > [<ffffffff9f9f8cb8>] inet_sendmsg+0x37/0x5e
> >
> > I don't touch chronyd in my VM, so I have no idea why it sends out UDP
> > packets, my guess is it is some periodical packet.
> >
> > I don't think I use conntrack either, since /proc/net/ip_conntrack
> > does not exist.
>
> You probably do, can you try "cat /proc/net/nf_conntrack" instead?
>
> (otherwise there should be no ipv4_conntrack_local() invocation
> since we would not register this hook at all).
>
> I tried to reproduce this but so far I had no success.
> If you can identify something that could give a hint when this
> is happening (only once after boot, periodically, only with udp, etc)
> please let us know.
FWIW i managed to obtain a similar backtrace, but in that case it was a
false positive (peeking at the address content showed it was my ssh connection
to the vm and timeout and tcp conntrackk struct fields were changing;
i.e. the nf_conn reported was still in the conntrack hash.
Why this address was reported i do not know, afaik kmemleak
does scan for addresses anywhere in the object (we use
container_of() to get back nf_conn from the hlist_node), so it
should have found the address linked via the main conntrack hash table.
Right now I don't have enough info to dig any further, sorry :-/
^ permalink raw reply
* Re: 319554f284dd ("inet: don't use sk_v6_rcv_saddr directly") causes bind port regression
From: Laura Abbott @ 2017-09-13 15:44 UTC (permalink / raw)
To: Josef Bacik, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Cole Robinson
In-Reply-To: <AF16C126-99CA-401A-B803-AA05CDFBFF93@fb.com>
On 09/12/2017 04:12 PM, Josef Bacik wrote:
> First I’m super sorry for the top post, I’m at plumbers and I forgot to upload my muttrc to my new cloud instance, so I’m screwed using outlook.
>
> I have a completely untested, uncompiled patch that I think will fix the problem, would you mind giving it a go? Thanks,
>
> Josef
Thanks for the quick turnaround. Unfortunately, the problem is still
reproducible according to the reporter.
Thanks,
Laura
^ permalink raw reply
* [PATCH net 0/3] nfp: wait more carefully for card init
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
Hi!
The first patch is a small fix for flower offload, we need a whitelist
of supported matches, otherwise the unsupported ones will be ignored.
The second and the third patch are adding wait/polling to the probe path.
We had reports of driver failing probe because it couldn't find the
control process (NSP) on the card. Turns out the NSP will only announce
its existence after it's fully initialized. Until now we assumed it
will be reachable, just not processing commands (hence we wait for
a NOOP command to execute successfully).
Jakub Kicinski (2):
nfp: wait for board state before talking to the NSP
nfp: wait for the NSP resource to appear on boot
Pieter Jansen van Vuuren (1):
nfp: add whitelist of supported flow dissector
.../net/ethernet/netronome/nfp/flower/offload.c | 13 ++++++
drivers/net/ethernet/netronome/nfp/nfp_main.c | 47 ++++++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 23 -----------
drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h | 2 +
.../ethernet/netronome/nfp/nfpcore/nfp_resource.c | 45 +++++++++++++++++++++
5 files changed, 107 insertions(+), 23 deletions(-)
--
2.14.1
^ permalink raw reply
* [PATCH net 1/3] nfp: add whitelist of supported flow dissector
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Pieter Jansen van Vuuren
In-Reply-To: <20170913155131.18090-1-jakub.kicinski@netronome.com>
From: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Previously we did not check the flow dissector against a list of allowed
and supported flow key dissectors. This patch introduces such a list and
correctly rejects unsupported flow keys.
Fixes: 43f84b72c50d ("nfp: add metadata to each flow offload")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
drivers/net/ethernet/netronome/nfp/flower/offload.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/flower/offload.c b/drivers/net/ethernet/netronome/nfp/flower/offload.c
index d396183108f7..a18b4d2b1d3e 100644
--- a/drivers/net/ethernet/netronome/nfp/flower/offload.c
+++ b/drivers/net/ethernet/netronome/nfp/flower/offload.c
@@ -44,6 +44,16 @@
#include "../nfp_net.h"
#include "../nfp_port.h"
+#define NFP_FLOWER_WHITELIST_DISSECTOR \
+ (BIT(FLOW_DISSECTOR_KEY_CONTROL) | \
+ BIT(FLOW_DISSECTOR_KEY_BASIC) | \
+ BIT(FLOW_DISSECTOR_KEY_IPV4_ADDRS) | \
+ BIT(FLOW_DISSECTOR_KEY_IPV6_ADDRS) | \
+ BIT(FLOW_DISSECTOR_KEY_PORTS) | \
+ BIT(FLOW_DISSECTOR_KEY_ETH_ADDRS) | \
+ BIT(FLOW_DISSECTOR_KEY_VLAN) | \
+ BIT(FLOW_DISSECTOR_KEY_IP))
+
static int
nfp_flower_xmit_flow(struct net_device *netdev,
struct nfp_fl_payload *nfp_flow, u8 mtype)
@@ -112,6 +122,9 @@ nfp_flower_calculate_key_layers(struct nfp_fl_key_ls *ret_key_ls,
u8 key_layer;
int key_size;
+ if (flow->dissector->used_keys & ~NFP_FLOWER_WHITELIST_DISSECTOR)
+ return -EOPNOTSUPP;
+
if (dissector_uses_key(flow->dissector,
FLOW_DISSECTOR_KEY_ENC_CONTROL)) {
struct flow_dissector_key_control *mask_enc_ctl =
--
2.14.1
^ permalink raw reply related
* [PATCH net 2/3] nfp: wait for board state before talking to the NSP
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170913155131.18090-1-jakub.kicinski@netronome.com>
Board state informs us which low-level initialization stages the card
has completed. We should wait for the card to be fully initialized
before trying to communicate with it, not only before we configure
passing traffic.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_main.c | 43 +++++++++++++++++++++++
drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 23 ------------
2 files changed, 43 insertions(+), 23 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index f055b1774d65..424707d41fbd 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -74,6 +74,45 @@ static const struct pci_device_id nfp_pci_device_ids[] = {
};
MODULE_DEVICE_TABLE(pci, nfp_pci_device_ids);
+static bool nfp_board_ready(struct nfp_pf *pf)
+{
+ const char *cp;
+ long state;
+ int err;
+
+ cp = nfp_hwinfo_lookup(pf->hwinfo, "board.state");
+ if (!cp)
+ return false;
+
+ err = kstrtol(cp, 0, &state);
+ if (err < 0)
+ return false;
+
+ return state == 15;
+}
+
+static int nfp_pf_board_state_wait(struct nfp_pf *pf)
+{
+ const unsigned long wait_until = jiffies + 10 * HZ;
+
+ while (!nfp_board_ready(pf)) {
+ if (time_is_before_eq_jiffies(wait_until)) {
+ nfp_err(pf->cpp, "NFP board initialization timeout\n");
+ return -EINVAL;
+ }
+
+ nfp_info(pf->cpp, "waiting for board initialization\n");
+ if (msleep_interruptible(500))
+ return -ERESTARTSYS;
+
+ /* Refresh cached information */
+ kfree(pf->hwinfo);
+ pf->hwinfo = nfp_hwinfo_read(pf->cpp);
+ }
+
+ return 0;
+}
+
static int nfp_pcie_sriov_read_nfd_limit(struct nfp_pf *pf)
{
int err;
@@ -425,6 +464,10 @@ static int nfp_pci_probe(struct pci_dev *pdev,
nfp_hwinfo_lookup(pf->hwinfo, "assembly.revision"),
nfp_hwinfo_lookup(pf->hwinfo, "cpld.version"));
+ err = nfp_pf_board_state_wait(pf);
+ if (err)
+ goto err_hwinfo_free;
+
err = devlink_register(devlink, &pdev->dev);
if (err)
goto err_hwinfo_free;
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
index 5abb9ba31e7d..ff373acd28f3 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_main.c
@@ -64,23 +64,6 @@
#define NFP_PF_CSR_SLICE_SIZE (32 * 1024)
-static int nfp_is_ready(struct nfp_pf *pf)
-{
- const char *cp;
- long state;
- int err;
-
- cp = nfp_hwinfo_lookup(pf->hwinfo, "board.state");
- if (!cp)
- return 0;
-
- err = kstrtol(cp, 0, &state);
- if (err < 0)
- return 0;
-
- return state == 15;
-}
-
/**
* nfp_net_get_mac_addr() - Get the MAC address.
* @pf: NFP PF handle
@@ -725,12 +708,6 @@ int nfp_net_pci_probe(struct nfp_pf *pf)
INIT_WORK(&pf->port_refresh_work, nfp_net_refresh_vnics);
- /* Verify that the board has completed initialization */
- if (!nfp_is_ready(pf)) {
- nfp_err(pf->cpp, "NFP is not ready for NIC operation.\n");
- return -EINVAL;
- }
-
if (!pf->rtbl) {
nfp_err(pf->cpp, "No %s, giving up.\n",
pf->fw_loaded ? "symbol table" : "firmware found");
--
2.14.1
^ permalink raw reply related
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 15:51 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers
In-Reply-To: <4cd23914d8cc2cf5caf78cb5654fb245@nuclearcat.com>
On Wed, 2017-09-13 at 18:20 +0300, Denys Fedoryshchenko wrote:
> Hi,
>
> I noticed after increasing bandwidth over some amount HTB started to
> throttle classes it should not throttle.
> Also estimated rate in htb totally wrong, while byte counters is
> correct.
>
> Is there any overflow or something?
Thanks Denys for the report, I will take a look at this, since I
probably introduced some regression.
^ permalink raw reply
* [PATCH net 3/3] nfp: wait for the NSP resource to appear on boot
From: Jakub Kicinski @ 2017-09-13 15:51 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, Jakub Kicinski
In-Reply-To: <20170913155131.18090-1-jakub.kicinski@netronome.com>
The control process (NSP) may take some time to complete its
initialization. This is not a problem on most servers, but
on very fast-booting machines it may not be ready for operation
when driver probes the device. There is also a version of the
flash in the wild where NSP tries to train the links as part
of init. To wait for NSP initialization we should make sure
its resource has already been added to the resource table.
NSP adds itself there as last step of init.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_main.c | 4 ++
drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h | 2 +
.../ethernet/netronome/nfp/nfpcore/nfp_resource.c | 45 ++++++++++++++++++++++
3 files changed, 51 insertions(+)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_main.c b/drivers/net/ethernet/netronome/nfp/nfp_main.c
index 424707d41fbd..1c17b261a21c 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_main.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_main.c
@@ -390,6 +390,10 @@ static void nfp_fw_unload(struct nfp_pf *pf)
struct nfp_nsp *nsp;
int err;
+ err = nfp_resource_wait(pf->cpp, NFP_RESOURCE_NSP, 30);
+ if (err)
+ return err;
+
nsp = nfp_nsp_open(pf->cpp);
if (IS_ERR(nsp)) {
nfp_err(pf->cpp, "Reset failed, can't open NSP\n");
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h
index 1a8d04a1e113..3ce51f03126f 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp.h
@@ -97,6 +97,8 @@ nfp_resource_acquire(struct nfp_cpp *cpp, const char *name);
void nfp_resource_release(struct nfp_resource *res);
+int nfp_resource_wait(struct nfp_cpp *cpp, const char *name, unsigned int secs);
+
u32 nfp_resource_cpp_id(struct nfp_resource *res);
const char *nfp_resource_name(struct nfp_resource *res);
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
index 072612263dab..b1dd13ff282b 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_resource.c
@@ -249,6 +249,51 @@ void nfp_resource_release(struct nfp_resource *res)
kfree(res);
}
+/**
+ * nfp_resource_wait() - Wait for resource to appear
+ * @cpp: NFP CPP handle
+ * @name: Name of the resource
+ * @secs: Number of seconds to wait
+ *
+ * Wait for resource to appear in the resource table, grab and release
+ * its lock. The wait is jiffies-based, don't expect fine granularity.
+ *
+ * Return: 0 on success, errno otherwise.
+ */
+int nfp_resource_wait(struct nfp_cpp *cpp, const char *name, unsigned int secs)
+{
+ unsigned long warn_at = jiffies + NFP_MUTEX_WAIT_FIRST_WARN * HZ;
+ unsigned long err_at = jiffies + secs * HZ;
+ struct nfp_resource *res;
+
+ while (true) {
+ res = nfp_resource_acquire(cpp, name);
+ if (!IS_ERR(res)) {
+ nfp_resource_release(res);
+ return 0;
+ }
+
+ if (PTR_ERR(res) != -ENOENT) {
+ nfp_err(cpp, "error waiting for resource %s: %ld\n",
+ name, PTR_ERR(res));
+ return PTR_ERR(res);
+ }
+ if (time_is_before_eq_jiffies(err_at)) {
+ nfp_err(cpp, "timeout waiting for resource %s\n", name);
+ return -ETIMEDOUT;
+ }
+ if (time_is_before_eq_jiffies(warn_at)) {
+ warn_at = jiffies + NFP_MUTEX_WAIT_NEXT_WARN * HZ;
+ nfp_info(cpp, "waiting for NFP resource %s\n", name);
+ }
+ if (msleep_interruptible(10)) {
+ nfp_err(cpp, "wait for resource %s interrupted\n",
+ name);
+ return -ERESTARTSYS;
+ }
+ }
+}
+
/**
* nfp_resource_cpp_id() - Return the cpp_id of a resource handle
* @res: NFP Resource handle
--
2.14.1
^ permalink raw reply related
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Denys Fedoryshchenko @ 2017-09-13 15:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Linux Kernel Network Developers, netdev-owner
In-Reply-To: <1505317903.15310.167.camel@edumazet-glaptop3.roam.corp.google.com>
On 2017-09-13 18:51, Eric Dumazet wrote:
> On Wed, 2017-09-13 at 18:20 +0300, Denys Fedoryshchenko wrote:
>> Hi,
>>
>> I noticed after increasing bandwidth over some amount HTB started to
>> throttle classes it should not throttle.
>> Also estimated rate in htb totally wrong, while byte counters is
>> correct.
>>
>> Is there any overflow or something?
>
> Thanks Denys for the report, I will take a look at this, since I
> probably introduced some regression.
It's definitely not something recent, this system was on older kernel
with uptime over 200 days, and this bottleneck was present, i noticed it
long time before.
But never tried to remove estimators (increasing burst/cburst to insane
values saved me for a while).
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
From: Sergei Shtylyov @ 2017-09-13 16:02 UTC (permalink / raw)
To: Yoshihiro Shimoda, davem, robh+dt, mark.rutland
Cc: netdev, linux-renesas-soc, devicetree
In-Reply-To: <1505305060-4192-1-git-send-email-yoshihiro.shimoda.uh@renesas.com>
Hello!
On 09/13/2017 03:17 PM, Yoshihiro Shimoda wrote:
> Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> index 1672353..ae2213f 100644
> --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
> +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
> @@ -17,6 +17,7 @@ Required properties:
>
> - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
> - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
> + - "renesas,etheravb-r8a77995" for the R8A77995 SoC.
That would conflict with the R8A77970 bindings patch posted by me
yesterday. Please respin atop of it.
> - "renesas,etheravb-rcar-gen3" as a fallback for the above
> R-Car Gen3 devices.
>
One more fragment is needed here, about the mandatory 'interrupt-names"
prop. My patch makes this change unnecessary, however...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: renesas-ravb: Add support for R8A77995 RAVB
From: Sergei Shtylyov @ 2017-09-13 16:08 UTC (permalink / raw)
To: Yoshihiro Shimoda, davem, robh+dt, mark.rutland
Cc: netdev, linux-renesas-soc, devicetree
In-Reply-To: <1f4763ea-9f8a-03a6-1215-69b96c404590@cogentembedded.com>
On 09/13/2017 07:02 PM, Sergei Shtylyov wrote:
>> Add a new compatible string for the R8A77995 (R-Car D3) RAVB.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> ---
>> Documentation/devicetree/bindings/net/renesas,ravb.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> b/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> index 1672353..ae2213f 100644
>> --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
>> @@ -17,6 +17,7 @@ Required properties:
>> - "renesas,etheravb-r8a7795" for the R8A7795 SoC.
>> - "renesas,etheravb-r8a7796" for the R8A7796 SoC.
>> + - "renesas,etheravb-r8a77995" for the R8A77995 SoC.
>
> That would conflict with the R8A77970 bindings patch posted by me
> yesterday. Please respin atop of it.
Here's the link for your convenience:
https://marc.info/?l=linux-renesas-soc&m=150524655515476
[...]
MBR, Sergei
^ permalink raw reply
* Re: HTB going crazy over ~5Gbit/s (4.12.9, but problem present in older kernels as well)
From: Eric Dumazet @ 2017-09-13 16:16 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: Linux Kernel Network Developers
In-Reply-To: <d2aee52fda21d8f668ca012333ef3677@nuclearcat.com>
On Wed, 2017-09-13 at 18:34 +0300, Denys Fedoryshchenko wrote:
> Well, probably i am answering my own question, removing estimator from
> classes seems drastically improve situation.
> It seems estimator has some issues that cause shaper to behave
> incorrectly (throttling traffic while it should not).
> But i guess thats a bug?
> As i was not able to predict such bottleneck by CPU load measurements.
Well, there was a reason we disabled HTB class estimators by default ;)
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=64153ce0a7b61b2a5cacb01805cbf670142339e9
^ permalink raw reply
* Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.
From: David Miller @ 2017-09-13 16:20 UTC (permalink / raw)
To: allen.lkml
Cc: linux-kernel, nouveau, linux-crypto, dri-devel,
MPT-FusionLinux.pdl, linux-scsi, netdev, megaraidlinux.pdl,
target-devel, linux-fbdev, linux-btrfs
In-Reply-To: <1505287939-14106-6-git-send-email-allen.lkml@gmail.com>
From: Allen Pais <allen.lkml@gmail.com>
Date: Wed, 13 Sep 2017 13:02:15 +0530
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
This is quite pointless as the caller doesn't do anything with
the value, it just tests whether a negative value is returned
or not.
^ permalink raw reply
* Re: [PATCH net] sctp: potential read out of bounds in sctp_ulpevent_type_enabled()
From: David Miller @ 2017-09-13 16:25 UTC (permalink / raw)
To: dan.carpenter; +Cc: vyasevich, nhorman, linux-sctp, netdev, kernel-janitors
In-Reply-To: <20170913092028.idzvduj7ran4li6b@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 13 Sep 2017 12:20:28 +0300
> @@ -154,7 +154,11 @@ static inline int sctp_ulpevent_type_enabled(__u16 sn_type,
> struct sctp_event_subscribe *mask)
> {
> char *amask = (char *) mask;
> - return amask[sn_type - SCTP_SN_TYPE_BASE];
> + int offset = sn_type - SCTP_SN_TYPE_BASE;
Please use reverse-christmas-tree local variable ordering.
Thank you.
^ 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