Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp96229pxb; Wed, 14 Apr 2021 10:15:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMPkmqvvY5xAcL3lFiamf7Nr3icQAHMqnGTXtkZS/WZHvwnsFAj8nHzQORwxDX7FV/+ZUG X-Received: by 2002:a17:90a:2c4c:: with SMTP id p12mr1562772pjm.87.1618420508176; Wed, 14 Apr 2021 10:15:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618420508; cv=none; d=google.com; s=arc-20160816; b=Jk24fa/vPXXRq6xV7ChygAncKFodZ1gl7ChoxXuc+jFUNcbgIm2NxJVKjQK5j3l76q Sm9q6YwSaraSddbubJFKPppPVLOyPe5taRPhHDAi8jTmtHVeL6JNE+JGrHPqysUMyGhf Vz9zpk1Tr5eWAvkN73+JahMf8uCpYHvnEjkMiNJl1sV75cSUYPfHipbS569z23eDtWBf xGwNleDP55v0KW3NluZmmcBvzyk3LUZNjnuqdgzldUW75lqxRXIp/kxVs5AErtkFiFZb 1DWV6U7jYmRjUvkYV5yPAhFaW19KiFxfSGqUEBS0BGwIhmA9oqjSrYlfe4mdb1QJArqM XveA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:date:from :dkim-signature; bh=LKBWpjyMDRFuuMYdGVnQkKgGtzVnoGLy1lYODPpAzN4=; b=hVocvUxQmfY/pCe1NUCuSMTyYEG9CmXggKQInayUvteEn71e5y6EPSCNyXR3HWil6r U1D3IxtXzlC2vmANFl3zs9DF7NfTrKWJMGYYUORyCOrjhs//kzAAdQMY2eI2mfO/p4dF +f7tmdk2khoaSlPiKkj6HAjY+7ptXzWwOvAjPPjVxBSzILCypkQuM1ntDoZFRkRuw7s2 DTcW36zulpsAUA6HUpMY3ex8tD0ef6E5IlqTlpP6kyKxHUW0m8Nd5x3F3dp0DPXTE2xV CiH7t1ZIx2a7VJ3uQMUwOiAJmbUK3qEdNsXexvxMlGImYGRXirTLw76Gt2NcDo1htD9H 18bA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Z7S2SFqo; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q15si227662plx.202.2021.04.14.10.14.53; Wed, 14 Apr 2021 10:15:08 -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=@gmail.com header.s=20161025 header.b=Z7S2SFqo; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234119AbhDNPVq (ORCPT + 99 others); Wed, 14 Apr 2021 11:21:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232358AbhDNPVp (ORCPT ); Wed, 14 Apr 2021 11:21:45 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C82DC061574; Wed, 14 Apr 2021 08:21:24 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id e2so5988983plh.8; Wed, 14 Apr 2021 08:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=LKBWpjyMDRFuuMYdGVnQkKgGtzVnoGLy1lYODPpAzN4=; b=Z7S2SFqo8Jhhfd7L9wAGEm2/Jq1XwM9BgNVD8/LS/YH5FFe3DS1y8X+8iIB5w1O//n 7mOKIeUGvzKkAbJH7e4DroEhKLuKLt+2I8x0K8CT7vz2O9OjSzpA/hC6+oPbzvvs1egs IjOtQlRkE5W44ChjhY+CzpIQq5WIjo6mNKAEPSFwEc+U0ukXtCMxAeacQGrLwdjXFdP9 9xBlsb8Axpzql02GqmTcTgCH8IrK7P6fCxrvlkxTKdtr5OWvg5Fhbe3cXaHhp6A/39Qt lM2DIxnnvrIDG1i0SoI+QxrMfGPcT6AzNI6p9nTIxQCWLzISJvksq4Ik/WQz3pm/KpZt koqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=LKBWpjyMDRFuuMYdGVnQkKgGtzVnoGLy1lYODPpAzN4=; b=F+LcziuLA6i7exmS8CxNsFiVC8GZlB64Pngq/A5xfmjH35HXTMp6F4m7I8TIgmCDpn UPXqedv9dPVrHH5JYiNx6AQsGl9RGySJ7ZYQWRe9Vk6Q84IZ/FJha4PCJ+Nrpoz/2OYM 1ZnfISlDesHT/jlWGxDkauYrvqvaIhpCtppXw5e9buR8ZxQjRm8pxBzUr/Ci+XjsdfP/ pTM0M8OdKNWOKWegWr3Zxzxl8VJyWkQTJI84Wi3F+BotO/Gcd7lkzLym3rg2VFowBEeQ LU20JCqHFAjNEURUv04qfnC/cpQ+TJcdPwDV5xeuHliOVK3meoFcYblOcYR6M5iWG9iZ iELA== X-Gm-Message-State: AOAM533m1fxNRSZmrJ9zK0Ku66pR7VEbBfGrJ+DOIwtPBKXUvJuWq/vC 78jVgbb5iPXDEHrqKpfkHvE= X-Received: by 2002:a17:902:b28b:b029:ea:eda0:4d5e with SMTP id u11-20020a170902b28bb02900eaeda04d5emr17850905plr.68.1618413683915; Wed, 14 Apr 2021 08:21:23 -0700 (PDT) Received: from slime ([139.198.121.254]) by smtp.gmail.com with ESMTPSA id y19sm17873854pge.50.2021.04.14.08.21.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Apr 2021 08:21:23 -0700 (PDT) From: xiaojun.zhao141@gmail.com X-Google-Original-From: Date: Wed, 14 Apr 2021 23:21:19 +0800 To: Miroslav Benes Cc: xiaojun.zhao141@gmail.com, josef@toxicpanda.com, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Subject: Re: the qemu-nbd process automatically exit with the commit 43347d56c 'livepatch: send a fake signal to all blocking tasks' Message-ID: <20210414232119.13b126fa@slime> In-Reply-To: References: <20210414115548.0cdb529b@slime> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Apr 2021 13:27:43 +0200 (CEST) Miroslav Benes wrote: > Hi, > > On Wed, 14 Apr 2021, xiaojun.zhao141@gmail.com wrote: > > > I found the qemu-nbd process(started with qemu-nbd -t -c /dev/nbd0 > > nbd.qcow2) will automatically exit when I patched for functions of > > the nbd with livepatch. > > > > The nbd relative source: > > static int nbd_start_device_ioctl(struct nbd_device *nbd, struct > > block_device *bdev) > > { struct nbd_config *config = > > nbd->config; int > > ret; > > ret = > > nbd_start_device(nbd); if > > (ret) return > > ret; > > if > > (max_part) bdev->bd_invalidated = > > 1; > > mutex_unlock(&nbd->config_lock); ret = > > wait_event_interruptible(config->recv_wq, > > atomic_read(&config->recv_threads) == 0); if > > (ret) > > sock_shutdown(nbd); > > flush_workqueue(nbd->recv_workq); > > mutex_lock(&nbd->config_lock); > > nbd_bdev_reset(bdev); > > /* user requested, ignore socket errors > > */ if (test_bit(NBD_RT_DISCONNECT_REQUESTED, > > &config->runtime_flags)) ret = > > 0; if (test_bit(NBD_RT_TIMEDOUT, > > &config->runtime_flags)) ret = > > -ETIMEDOUT; return > > ret; } > > So my understanding is that ndb spawns a number > (config->recv_threads) of workqueue jobs and then waits for them to > finish. It waits interruptedly. Now, any signal would make > wait_event_interruptible() to return -ERESTARTSYS. Livepatch fake > signal is no exception there. The error is then propagated back to > the userspace. Unless a user requested a disconnection or there is > timeout set. How does the userspace then reacts to it? Is > _interruptible there because the userspace sends a signal in case of > NBD_RT_DISCONNECT_REQUESTED set? How does the userspace handles > ordinary signals? This all sounds a bit strange, but I may be missing > something easily. > > > When the nbd waits for atomic_read(&config->recv_threads) == 0, the > > klp will send a fake signal to it then the qemu-nbd process exits. > > And the signal of sysfs to control this action was removed in the > > commit 10b3d52790e 'livepatch: Remove signal sysfs attribute'. Are > > there other ways to control this action? How? > > No, there is no way currently. We send a fake signal automatically. > > Regards > Miroslav It occurs IO error of the nbd device when I use livepatch of the nbd, and I guess that any livepatch on other kernel source maybe cause the IO error. Well, now I decide to workaround for this problem by adding a livepatch for the klp to disable a automatic fake signal. Regards.