Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp2125025ybt; Fri, 3 Jul 2020 01:12:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylLGiG0zGodCGtYla59pEmXQaK2nv6XT5z2PfBUKW3enheS+SyC6oK+RjpFkwPhBRVQ1pX X-Received: by 2002:aa7:d6cc:: with SMTP id x12mr31725888edr.354.1593763974089; Fri, 03 Jul 2020 01:12:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593763974; cv=none; d=google.com; s=arc-20160816; b=xKEwL8BpdUrLSd3FMHb90DTNY8NEgG3ND1JyoyrMz65wfNXMA7ho9KQO3qNzC/+oDy Y7OXJi2O0o1aJhu/w+zVRmVN98i8qLiqLTV2MUegbf2ksPReDwUfV97TVFa+pGZZ5tS9 wP5bdPvHnAXcE9de38vf8oRxQk+uRSWhPekLDPCkeQrXDy3H/loEGbxtAnQi2oqAcE3X Z80Y9/gmRgL3UuF2VWgEnpJg3jNFZH0/a5yZCK4RO6QGYHUHegBsd8+aZv9HWw6PGnUu 1i5gGPA+zwX4iLIiEYpcQH1/cdvOBLdKAqmfCz1F9vLCUFKXFmjd5XhC+O5rGpKzjNGg v2Zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=aL1ix2yKSa96qtp2+jnkXvtwe2HET4gQ2cg4dTxzFd8=; b=jyFWkrmuT7iSt2HLEeUhbpawFYbzJrYJ81yVzHo4RtJnNAgkAIVxa82yQcdJA+WHmT W8IVshYrF7wLFdFi03pDkITyWLM5nctGeHz3uqtgKZpmTnZljic6wxWBT9ArjdMvTKNp ersA9y/CKcWuGdDrJCceoiK/Vd+glh8Z/4bFivux0qF1Sa3z8CupXoUG/GUgdY4xytq3 4VFaZDi3swQ8dglm17WwcnJlfoKLljnSQtv4be/HiRnqQkX/au/WGp4lfpeBwA8+/cYA 2S1J+kbO06HIpYZjRKaBPtG1Wjo4srIlZFgX/fGPqf7tz66qhK/QARBoOt7jLh4PeOOA PfSg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OTOMPRDJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm7si7603673edb.43.2020.07.03.01.12.31; Fri, 03 Jul 2020 01:12:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OTOMPRDJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726304AbgGCIMS (ORCPT + 99 others); Fri, 3 Jul 2020 04:12:18 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:29152 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725891AbgGCIMS (ORCPT ); Fri, 3 Jul 2020 04:12:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593763937; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=aL1ix2yKSa96qtp2+jnkXvtwe2HET4gQ2cg4dTxzFd8=; b=OTOMPRDJeG4RHuVIZ61CQNXhArP5wj+SqQJaOhYQWvm8bgM9rcrfNtk+3AfRHFhbnlr/bY nQ4Q7X3ceBz6cidlP9YbT/i/m2CxwvF4RZG2boOgcPxR5lrN6wq9SYwOWZ1kVR8Ij+Llwf YEHAY8jIdtYZ4bnBk4Nev4DrOHjuRYc= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-216-AaxTv_GvPnuXibdgmTo4EQ-1; Fri, 03 Jul 2020 04:12:13 -0400 X-MC-Unique: AaxTv_GvPnuXibdgmTo4EQ-1 Received: by mail-wr1-f70.google.com with SMTP id w4so29075222wrm.5 for ; Fri, 03 Jul 2020 01:12:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aL1ix2yKSa96qtp2+jnkXvtwe2HET4gQ2cg4dTxzFd8=; b=ZbqRwMi5tSq0i4APMYTtRzL9RWKeEWPKWQMbnH5wbfBye2ARpIcufHf8Y3VpIMhsSc /fRUM1L2wdmuDMWLw5i35sLaYhr+MJJU6ruIud8qbe0XaNxCDVR8vbJYTbfAw2US6bO/ vrdiYLV0KzgVY/BidXlO0Da4Utiam9ScpfDoMljS1bY9/7hGY/mRaXyiDXnJds4BTYzR 0QSYB5NezN58u0Q2ndqiFtUx1X3TkiBndcKmISSA02z/PidKj42hSWZmt0jYmycp82AK Na9PtXCf1Ca+Ud+edANY+FGNjGJYNCBqlF78+t65qZIEvVCBWFI2RppySWPrSbvFtFrU HZ2g== X-Gm-Message-State: AOAM530fPduCh20NLJhw9uqI2xO47C1N9BkU9LfJYjrXUHXZG5n0jh4Z S1C5+MhWtq/LgoaDmV+EPjH1/irDAH1hpo7BcZ9u5ffIdbhuafDhy8l7q5quUZm5q+Ua/7JpFzl MfGKx94cGlItRF5LQiBC5wnjg X-Received: by 2002:a7b:c4d6:: with SMTP id g22mr36721014wmk.170.1593763932662; Fri, 03 Jul 2020 01:12:12 -0700 (PDT) X-Received: by 2002:a7b:c4d6:: with SMTP id g22mr36720996wmk.170.1593763932436; Fri, 03 Jul 2020 01:12:12 -0700 (PDT) Received: from localhost.localdomain ([151.29.191.109]) by smtp.gmail.com with ESMTPSA id v11sm49685250wmb.3.2020.07.03.01.12.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2020 01:12:11 -0700 (PDT) Date: Fri, 3 Jul 2020 10:12:09 +0200 From: Juri Lelli To: zhe.he@windriver.com Cc: viro@zeniv.linux.org.uk, axboe@kernel.dk, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] eventfd: Enlarge recursion limit to allow vhost to work Message-ID: <20200703081209.GN9670@localhost.localdomain> References: <20200410114720.24838-1-zhe.he@windriver.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200410114720.24838-1-zhe.he@windriver.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 10/04/20 19:47, zhe.he@windriver.com wrote: > From: He Zhe > > commit b5e683d5cab8 ("eventfd: track eventfd_signal() recursion depth") > introduces a percpu counter that tracks the percpu recursion depth and > warn if it greater than zero, to avoid potential deadlock and stack > overflow. > > However sometimes different eventfds may be used in parallel. Specifically, > when heavy network load goes through kvm and vhost, working as below, it > would trigger the following call trace. > > - 100.00% > - 66.51% > ret_from_fork > kthread > - vhost_worker > - 33.47% handle_tx_kick > handle_tx > handle_tx_copy > vhost_tx_batch.isra.0 > vhost_add_used_and_signal_n > eventfd_signal > - 33.05% handle_rx_net > handle_rx > vhost_add_used_and_signal_n > eventfd_signal > - 33.49% > ioctl > entry_SYSCALL_64_after_hwframe > do_syscall_64 > __x64_sys_ioctl > ksys_ioctl > do_vfs_ioctl > kvm_vcpu_ioctl > kvm_arch_vcpu_ioctl_run > vmx_handle_exit > handle_ept_misconfig > kvm_io_bus_write > __kvm_io_bus_write > eventfd_signal > > 001: WARNING: CPU: 1 PID: 1503 at fs/eventfd.c:73 eventfd_signal+0x85/0xa0 > ---- snip ---- > 001: Call Trace: > 001: vhost_signal+0x15e/0x1b0 [vhost] > 001: vhost_add_used_and_signal_n+0x2b/0x40 [vhost] > 001: handle_rx+0xb9/0x900 [vhost_net] > 001: handle_rx_net+0x15/0x20 [vhost_net] > 001: vhost_worker+0xbe/0x120 [vhost] > 001: kthread+0x106/0x140 > 001: ? log_used.part.0+0x20/0x20 [vhost] > 001: ? kthread_park+0x90/0x90 > 001: ret_from_fork+0x35/0x40 > 001: ---[ end trace 0000000000000003 ]--- > > This patch enlarges the limit to 1 which is the maximum recursion depth we > have found so far. > > Signed-off-by: He Zhe > --- Not sure if this approch can fly, but I also encountered the same warning (which further caused hangs during VM install) and this change addresses that. I'd be interested in understanding what is the status of this problem/fix. On a side note, by looking at the code, I noticed that (apart from samples) all callers don't actually check eventfd_signal() return value and I'm wondering why is that the case and if is it safe to do so. Thanks, Juri