From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE168C433B4 for ; Thu, 15 Apr 2021 08:37:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1B9C611CD for ; Thu, 15 Apr 2021 08:37:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231775AbhDOIiL (ORCPT ); Thu, 15 Apr 2021 04:38:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:45596 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231736AbhDOIiI (ORCPT ); Thu, 15 Apr 2021 04:38:08 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 20484AE27; Thu, 15 Apr 2021 08:37:45 +0000 (UTC) Date: Thu, 15 Apr 2021 10:37:44 +0200 (CEST) From: Miroslav Benes To: Josef Bacik cc: xiaojun.zhao141@gmail.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' In-Reply-To: Message-ID: References: <20210414115548.0cdb529b@slime> <20210414232119.13b126fa@slime> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: live-patching@vger.kernel.org On Wed, 14 Apr 2021, Josef Bacik wrote: > 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, wait_event_killable() means that you would sleep uninterruptedly (still reacting to fatal signals), so the fake signal from livepatch would not be sent at all. set_notify_signal() handles TASK_INTERRUPTIBLE tasks. No disruption for the userspace and it would fix this problem. There is a catch on the livepatch side of things. If there is a live patch for nbd_start_device_ioctl(), the transition process would get stuck until the task leaves the function (all workqueue jobs are processed). I gather it is unlikely to be it indefinite, so we can live with that, I think. Miroslav