Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp354829pxb; Wed, 14 Apr 2021 17:38:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/OcDqnn3B0mAX+KUMpGSgvnevbPLKxHSAfPc9rbU1FtpZedx33cEWoOCSAinrVXh8Wib3 X-Received: by 2002:a17:906:c08f:: with SMTP id f15mr740249ejz.318.1618447111150; Wed, 14 Apr 2021 17:38:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618447111; cv=none; d=google.com; s=arc-20160816; b=t1fH2Q4MVrQAFSNEWZiH7dzPNuag6y6FD0PrBEXesn/1/79uvDaDgyEm18drA/wks7 zMpdhgxK9YkMWcbPuarhEmdXlMSAake08YszzGNTNJpwa0scwc6Y6VJa55CBWbwQbF+P 6M2rs2cEBHbbYW4MpxF7aZQ39Dc7MlOl0xp/ZOfbFRq7Xag0PmM9GcBaHiTXNCf00FCo 5cNbNMFEC/5FP/pk/Fxj9Bfkp2IgIFbSR8RkDDMs6rPfFphi8Wbw5sI9fkDv8u5xen+i ueNQWdKkhZIQ7i5Xj1eB3yYohTCd8S9oXYd7c0xJDTsoM9sThpPUtjy9TnwyudaMsc80 0lAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=K+CoWOryQXPkwoI6HADtuZJs0NXTCSdwEpDuMV86TlA=; b=FjOWlsoYhnvoAZFK21wmp/tITduBlWjB/BRb31fAkO9S8KM6WZLGk/bqptRqS1WTC2 fg5LEiVIp6OuRAr00aBu0U5ys/4e1IhCExU5lSrmWxcwhhqcjfWNap/b4ln2h2354C1b ETQ+gNUla5RqjhA8ebFCvD76Y+Fqs/clw4okuo6Q12eg6G+UaXJzXXgG9lOBZNbs31Zp FJHDDog0BIa9+pISYSd4aCi2Jw/PW6ugYRAdAyfAMDkevh1qGS2CrE9k/u2ur7DUyddk 0LNWIPUcz853LnAQGHo/vBohpb6sSwc20SaUzBOtTG/hFFQy6gVvWyYswsaA59XO2bK2 sxvQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=bv523jUW; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t22si966874edd.558.2021.04.14.17.38.08; Wed, 14 Apr 2021 17:38:31 -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=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=bv523jUW; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232359AbhDNRWF (ORCPT + 99 others); Wed, 14 Apr 2021 13:22:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43938 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231764AbhDNRWC (ORCPT ); Wed, 14 Apr 2021 13:22:02 -0400 Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43DAAC061574 for ; Wed, 14 Apr 2021 10:21:41 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id d15so9215514qkc.9 for ; Wed, 14 Apr 2021 10:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=K+CoWOryQXPkwoI6HADtuZJs0NXTCSdwEpDuMV86TlA=; b=bv523jUWRxpMuwbk6qn63MlBojHdAT3raBNQVr5ncdx1Pa+c+Slrjo3PVYbdNW24r2 PmpEuKXoj0AIGt6346L38UqnljlFhqA5owtMDWCQmuCEdGy/Jap23GmsopTSqzqhB0kn d2w7tBccKzvOWz16UWg+IsJSk1l10NqIT8YDhAwRuqzSAC3RJMVJS6yxl213gzQ/+XWa ozm47LpwltErV6/fMMRuR2oNMlUodIlUZtZ7D9Ima6ZjJieOwN/3MkDbIB9bKLC4Vh90 h7O5L7G01ke0hAATOA+OxqkGsEH1k8NEoYC+YeHEeCbCUpws4K+tFDNu1fAWieD/nK0+ mmOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=K+CoWOryQXPkwoI6HADtuZJs0NXTCSdwEpDuMV86TlA=; b=fGPJNHntrD9u9AgsM/hnr1j+szjC1uAvLLkaZffsKwnbEDsfjN0tkmCl0p0Mg2gHCu sypCW1NdQpqdeRRZUZF5yQcYr+bOjVqFE88Y4mM4iflxAXGiyS7ZAe6S9bK+lxHbd8I3 wnmBaWdHmrKCTFjTc8AGOQbrWH10nSm0mJVNvVv1YK+VEwjpP+Pctkw+IMmvutzQ9+bC 2HB1wkspuYkGOX8VP/etTkRsgqN1AKxx/UTLAQyfWtaVj2mIFlD0Cz9dKNYHzkHm5CFE Gz5+A+S5/Ty85Gcw311G22GxWbd8IOZ2pDat01wJDyX2PC56wUx1le3j42K/x9En+cXt gkvA== X-Gm-Message-State: AOAM532pEA94X9UfFVdwSo0i2MLMkssmEzEWeKlK3I8lZ7/+zizMEMk4 sjW2ASmulTRz2dTB/YTngqE80Q== X-Received: by 2002:a37:9604:: with SMTP id y4mr12435433qkd.354.1618420900166; Wed, 14 Apr 2021 10:21:40 -0700 (PDT) Received: from ?IPv6:2620:10d:c0a8:11c1::127b? ([2620:10d:c091:480::1:e1e5]) by smtp.gmail.com with ESMTPSA id h65sm18155qkd.112.2021.04.14.10.21.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Apr 2021 10:21:39 -0700 (PDT) Subject: Re: the qemu-nbd process automatically exit with the commit 43347d56c 'livepatch: send a fake signal to all blocking tasks' To: xiaojun.zhao141@gmail.com, Miroslav Benes Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org References: <20210414115548.0cdb529b@slime> <20210414232119.13b126fa@slime> From: Josef Bacik Message-ID: Date: Wed, 14 Apr 2021 13:21:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <20210414232119.13b126fa@slime> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/14/21 11:21 AM, xiaojun.zhao141@gmail.com wrote: > 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. > Would wait_event_killable() fix this problem? I'm not sure any client implementations depend on being able to send other signals to the client process, so it should be safe from that standpoint. Not sure if the livepatch thing would still get an error at that point tho. Thanks, Josef