Received: by 10.192.165.148 with SMTP id m20csp3915512imm; Mon, 30 Apr 2018 08:30:47 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqKBWT3lnDeTjeX6EvtVeA8WQlDZU69w/TBoErb4OQqNYHlHQBnTW9NBFgWkSzMQtCLQP2J X-Received: by 10.167.134.20 with SMTP id p20mr12423994pfn.159.1525102247760; Mon, 30 Apr 2018 08:30:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525102247; cv=none; d=google.com; s=arc-20160816; b=l5/UTLqoBjIobiNgm4yZgCndFU4gSBZGkzXdVuUHT//6/IOVyF7Fcy5TB61trN8uop qKlNWr3UnfBpIYmELxx+hNNM5pAxVJZmEkJHS7ChiFKc2uxvKgl+CqpEOFRkjxxvo9B1 3lNsU57oZJkPZ6OBcPK1yP/rmpn7/ZRg29a3G22xOm+1+R8X7g3LdX5li8eS/xdKxyfW ZTbgABYneEADXzfjs2eeteWNvkdKp+fdhs6LRsqNuGqvIMN7oeSp/Yq0mSAtTyf+mUwP 1e5UhNCmln/E10/eBA67ESzedYUilrtzCbrXeTbKzEgXP4KzTMSm0Zi76J4YJRwbcxvL eJSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=klaKgm+EH/mW5GhJixz5568NW4kkTuRsPuOMTjiSL/Y=; b=vjs5GUylph7IPljwZtQbzodDJR2sBsMjqPbsfubPN7FpaspnFV/8lMnlmfJD+Ck6qv HvadND6xw5WbdqzdsgThkpu7XOGKNUdUqtAkk7LIbSzQ3dORyfv4wuXBdH9m6I9bqoL5 CUABRVOf9tEPoBBX2IDHdoDsQA7OIZSLd0EmjtykdQk+9UDREnazETQQjZG+0sp5dGqA PJVowTkVlvJ8yGvnodgJ/qN8K4QRSOrpgQcFjEF8S02k3F3afXj9uWnBCXX2TyMbXqY7 rhCF6uLAHe8+fqVmniT3KD1D3m7pW6E1DC9ecrH16tV8PoRZpKyXsYreH1jclcy5NaXz 6qmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 61-v6si7510525plz.290.2018.04.30.08.30.33; Mon, 30 Apr 2018 08:30:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754642AbeD3P24 (ORCPT + 99 others); Mon, 30 Apr 2018 11:28:56 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:34692 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753256AbeD3P2y (ORCPT ); Mon, 30 Apr 2018 11:28:54 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 36F0F406C74C; Mon, 30 Apr 2018 15:28:54 +0000 (UTC) Received: from gondolin (dhcp-192-222.str.redhat.com [10.33.192.222]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3B0DE202327B; Mon, 30 Apr 2018 15:28:53 +0000 (UTC) Date: Mon, 30 Apr 2018 17:28:51 +0200 From: Cornelia Huck To: Dong Jia Shi Cc: Pierre Morel , pasic@linux.vnet.ibm.com, linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH 03/10] vfio: ccw: new SCH_EVENT event Message-ID: <20180430172851.2cb3d550.cohuck@redhat.com> In-Reply-To: <20180426065954.GP5428@bjsdjshi@linux.vnet.ibm.com> References: <1524149293-12658-1-git-send-email-pmorel@linux.vnet.ibm.com> <1524149293-12658-4-git-send-email-pmorel@linux.vnet.ibm.com> <20180426065954.GP5428@bjsdjshi@linux.vnet.ibm.com> Organization: Red Hat GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 30 Apr 2018 15:28:54 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 30 Apr 2018 15:28:54 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'cohuck@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 26 Apr 2018 14:59:54 +0800 Dong Jia Shi wrote: > * Pierre Morel [2018-04-19 16:48:06 +0200]: > > > The Sub channel event callback is threaded using workqueues. > > The work uses the FSM introducing the VFIO_CCW_EVENT_SCH_EVENT > > event. > > The update of the SCHIB is now done inside the FSM function. > > > > Signed-off-by: Pierre Morel > > --- > > drivers/s390/cio/vfio_ccw_drv.c | 33 +++++++++++++-------------------- > > drivers/s390/cio/vfio_ccw_fsm.c | 23 +++++++++++++++++++++++ > > drivers/s390/cio/vfio_ccw_private.h | 3 +++ > > 3 files changed, 39 insertions(+), 20 deletions(-) > > > > @@ -171,28 +181,11 @@ static void vfio_ccw_sch_shutdown(struct subchannel *sch) > > static int vfio_ccw_sch_event(struct subchannel *sch, int process) > > { > > struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev); > > - unsigned long flags; > > > > - spin_lock_irqsave(sch->lock, flags); > > if (!device_is_registered(&sch->dev)) > > - goto out_unlock; > > - > > - if (work_pending(&sch->todo_work)) > > - goto out_unlock; > Just realized that this has a bug in the orignal implementation. For > error out this should return -EAGAIN. We'd need a separated fix on > this. Indeed. Will you send a patch, or should I hack something up? > > > - > > - if (cio_update_schib(sch)) { > > - vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_NOT_OPER); > > - goto out_unlock; > > - } > > - > > - private = dev_get_drvdata(&sch->dev); > > - if (private->state == VFIO_CCW_STATE_NOT_OPER) { > > - private->state = private->mdev ? VFIO_CCW_STATE_IDLE : > > - VFIO_CCW_STATE_STANDBY; > > - } > This hunk was toatally removed, and this is fine because? > > > - > > -out_unlock: > > - spin_unlock_irqrestore(sch->lock, flags); > > + return -1; > -1 is not a valid code. -ENODEV looks more fitting, if we decide to go with this rework. > > > + WARN_ON(work_pending(&private->event_work)); > > + queue_work(vfio_ccw_work_q, &private->event_work); > > > > return 0; > > } I'm wondering why this should always be done via a workqueue. It seems the other subchannel types try to do as much as possible immediately? (And returning -EAGAIN already triggers the css code to schedule another call later.)