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=-15.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 05D04C47094 for ; Thu, 10 Jun 2021 17:23:21 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 69FD0613C9 for ; Thu, 10 Jun 2021 17:23:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 69FD0613C9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:42338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lrOOl-0005Sj-70 for qemu-devel@archiver.kernel.org; Thu, 10 Jun 2021 13:23:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51368) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrONm-0004T0-SZ for qemu-devel@nongnu.org; Thu, 10 Jun 2021 13:22:18 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:59773) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lrONi-00032W-R3 for qemu-devel@nongnu.org; Thu, 10 Jun 2021 13:22:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623345733; 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=1hoUDABMAu8B6vmjK8RyAOdl4iWmj7RB/XBcqOadB8w=; b=MtoG/JGzrFXb7a8VKLSQC079rJ4EErQR20aKjtPzBnOu8qWtEKuxC9ijuyelp0ZJrTILzl SeYfbMyXrfPNslkNiX7VE7CjEk/+692AMZ1yyPrC/rGG5sSN/dLtLvvrh0dYHy/394o9ao s5hfI7UnvFSKKgJhYJI7itYIXKSihws= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-186-UXjB0c6_MBCY8VObWFjD2A-1; Thu, 10 Jun 2021 13:22:11 -0400 X-MC-Unique: UXjB0c6_MBCY8VObWFjD2A-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7309E8027F4; Thu, 10 Jun 2021 17:22:10 +0000 (UTC) Received: from redhat.com (ovpn-113-53.phx2.redhat.com [10.3.113.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9B5D05C1CF; Thu, 10 Jun 2021 17:22:06 +0000 (UTC) Date: Thu, 10 Jun 2021 12:22:04 -0500 From: Eric Blake To: Vladimir Sementsov-Ogievskiy Subject: Re: [PATCH v4 01/32] co-queue: drop extra coroutine_fn marks Message-ID: <20210610172204.w2gtdeoj3v72m5rg@redhat.com> References: <20210610100802.5888-1-vsementsov@virtuozzo.com> <20210610100802.5888-2-vsementsov@virtuozzo.com> MIME-Version: 1.0 In-Reply-To: <20210610100802.5888-2-vsementsov@virtuozzo.com> User-Agent: NeoMutt/20210205 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=eblake@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=170.10.133.124; envelope-from=eblake@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.199, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org, mreitz@redhat.com, Stefan Hajnoczi , pbonzini@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Jun 10, 2021 at 01:07:31PM +0300, Vladimir Sementsov-Ogievskiy wrote: > qemu_co_queue_next() and qemu_co_queue_restart_all() just call > aio_co_wake() which works well in non-coroutine context. So these > functions can be called from non-coroutine context as well. And > actually qemu_co_queue_restart_all() is called from > nbd_cancel_in_flight(), which is called from non-coroutine context. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > include/qemu/coroutine.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) In the back of my mind, I have to repeatedly question my faulty memory on whether: absence of coroutine_fn means this function is unsafe to call from a coroutine context (that is, coroutines can only call functions tagged with coroutine_fn) vs. presence of coroutine_fn means this function must only use coroutine-safe actions, but not all coroutine-safe functions have this tag (in particular, functions which are designed to work both in or out of coroutine context do not have the tag, but coroutines can call functions without the tag) But thankfully, rereading include/qemu/coroutine.h clears it up and both of my initial thoughts are wrong although the second is closer; it is yet another definition: presence of coroutine_fn means this function must NOT be called except from a coroutine context. coroutines can call functions with or without the tag, but if they lack the tag, the coroutine must ensure the function won't block. Thus, adding the tag is something we do when writing a function that obeys coroutine rules and requires a coroutine context to already be present, and once a function is then relaxed enough to work from both regular and coroutine functions, we drop the marker. But we keep the _co_ in the function name to remind ourselves that it is coroutine-safe, in addition to normal-safe. And your patch is doing just that - we have functions that work from both normal and coroutine context, so we can drop the marker but keep _co_ in the name. Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org