Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp262750imm; Thu, 14 Jun 2018 19:50:13 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLCKCuwgXtWYyTCUxrjD5liMTgcbYgCfF2qPZjH1GaS78RNr1Z4N/84RCRPcmxU/GPNyWYX X-Received: by 2002:a63:3759:: with SMTP id g25-v6mr4559501pgn.59.1529031013485; Thu, 14 Jun 2018 19:50:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529031013; cv=none; d=google.com; s=arc-20160816; b=Hmhid8ZUCYXf3oJBg8chvpvR+AmgzXw8lMdEXdUL/EQ25zOn45ySAxF+zIPPh7IwCg nbXCOveyGClqbMRjfKM3T1FzXaa7Mfoj5Yz1lcBBLHO6V/5T1QrfSKzGLgZ6EcIjP1YM KJNewjVHaTLI+RqTEHYGPQ5wQ4vXWfK53m+GTqAvaoWz4EM9tGarle0xbGa/mhS8hpYw XpIVvA/PtkzhdZ/TupOJMUv5EO/g0RV+r+vkgwX7v5TObJbq/QUxWi4ax0ooyE4D6aKu 8wGYoepletH7fD70/d5gje5YIG5tcu2gH9nwGX1ByABilQapQSekq+uHVBCq+nhRUR4r tUaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=J8pH5mFpf3/288/WZmuq1e6xn5EzsFYib600ox6pOoQ=; b=q+z2feSPN0JARE7xdBZaDwPscO4JahO7hPLlXUhMQupLhauVPD/C0dkxlYIvWL6AQp 82065UfWMyAXwP+miU0J8v56A0T9XbIMdz9g5uACJeG3j3spNHWMHYPtqwzVZl28VNI6 mHluN3Y9WvYI0gj5NsislxO+6MeHvz9OuNPfq6q3XY40U1Erf3d6sbdX0up5Q8FQx5QY OjVyD3KKQ98SSnaqeIvNroDemgi+uBlRFX8SS3KlTE3Xz+dTLJxyq7p0BDM06G6ClHzF fscjAj9z74//i2PZIhJxhH53S8GkKKmJzKBgLa2qR359bsRK1R1KcnZRmj48jEIntTzO Y05w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Hzf7xUyT; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a3-v6si8060998pll.412.2018.06.14.19.49.59; Thu, 14 Jun 2018 19:50:13 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Hzf7xUyT; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965509AbeFOCtd (ORCPT + 99 others); Thu, 14 Jun 2018 22:49:33 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:40436 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964995AbeFOCtb (ORCPT ); Thu, 14 Jun 2018 22:49:31 -0400 Received: by mail-wm0-f65.google.com with SMTP id n5-v6so1185323wmc.5; Thu, 14 Jun 2018 19:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J8pH5mFpf3/288/WZmuq1e6xn5EzsFYib600ox6pOoQ=; b=Hzf7xUyTPwUikEzQmk4XyDKnucLnkmOQx3sIqJCZ8ZrRguIsgkZMyVGbtKvzyasqgn c/mqE0JgTz7iFy7sCbfFfm32CsF3Nnp766AT2QdjbnNyWsCwrKkVUIKysA5LX7aPmYlN uf7/7pNzylV5RVoegOwLzAiVWMTpU3JvM4u/BN67qkZYsYKuoQeiJHCDn9HWoIEUQGI8 Fx8tUrnmt17BirLKtdr8CTN0KPqfeggRaSfORmvykaGY2Z8ZcPIK3MSwRwf7Ja4lsHc1 /TKeUL6RQGDafQcptLyAmnNBS3nAEIbHwh3yyqHZ6vfyj++zfbqlBL+xmEiSA/FgcT3A LKYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J8pH5mFpf3/288/WZmuq1e6xn5EzsFYib600ox6pOoQ=; b=rVt0JNtlmBBwtSYq7Lt9nHQDD92X3XodVgMZwIlkWG8X1OeSD4BOPDgUfVNhRPrB3g HsG3fv/Cu5u4QdFSn6cO65TiTBPEdhDCAbsOhjlGLVPvnPZOuJ5HQ1Y5LBypMaONZhwN HWszwauvmHghQ7RwywI3w5QmMTF/5WgMYDcHykGAms/NDgEpForjBPQsIHkWpNBBvjVn 69MbBzundn692Uin+INShHMEW0+8WT47jwB6ONDuVSsRsRFKEfQOG4pJOHREPRQSqUt1 b49aiFU9g+l/GqdgKhXzUO38KhWboLHRFf0t8YcQocVhRKlCZqbh7FV6T/ndBDs8mov8 udmQ== X-Gm-Message-State: APt69E1HtjLvaR7qxKDm+zPVD/rDSyITg6gu9HwDhy+5gHv/pfwqWn/s GUq1IRzoY7ggOFAarYKlU0WzIUAwmFppuu5AbrI= X-Received: by 2002:a1c:e594:: with SMTP id c142-v6mr112479wmh.161.1529030969885; Thu, 14 Jun 2018 19:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:97c6:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 19:49:29 -0700 (PDT) In-Reply-To: <3dd3f82a-5b68-f039-3a8a-7c5fe4e24c3e@oracle.com> References: <1529027847-29085-1-git-send-email-jianchao.w.wang@oracle.com> <3dd3f82a-5b68-f039-3a8a-7c5fe4e24c3e@oracle.com> From: Ming Lei Date: Fri, 15 Jun 2018 10:49:29 +0800 Message-ID: Subject: Re: [PATCH 1/2] block: export __blk_complete_request To: "jianchao.wang" Cc: Jens Axboe , Christoph Hellwig , James Bottomley , "Martin K. Petersen" , linux-block , Linux SCSI List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 15, 2018 at 10:22 AM, jianchao.wang wrote: > Hi Ming > > On 06/15/2018 10:17 AM, Ming Lei wrote: >> On Fri, Jun 15, 2018 at 9:57 AM, Jianchao Wang >> wrote: >>> After f6e7d48 (block: remove BLK_EH_HANDLED), LLDD is responsible >>> to complete the timed out request, however, for blk-legacy, the >>> 'complete' is still marked, blk_complete_request will do nothing, >>> we export __blk_complete_request for LLDD to complete the request >>> in timeout path. >>> >>> Signed-off-by: Jianchao Wang >>> --- >>> block/blk-softirq.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/block/blk-softirq.c b/block/blk-softirq.c >>> index 01e2b35..15c1f5e 100644 >>> --- a/block/blk-softirq.c >>> +++ b/block/blk-softirq.c >>> @@ -144,6 +144,7 @@ void __blk_complete_request(struct request *req) >>> >>> local_irq_restore(flags); >>> } >>> +EXPORT_SYMBOL(__blk_complete_request); >>> >>> /** >>> * blk_complete_request - end I/O on a request >>> -- >>> 2.7.4 >>> >> >> Looks non-blk-mq timeout code need to convert to ref-counter >> based approach too? > > IMO, ref-counter is just to fix the blk-mq req life recycle issue. Just thought of that, it is one blk-mq specific issue. > It cannot replace the blk_mark_rq_complete which could avoid the race between > timeout and io completion path. > Or maybe my understanding is wrong ... I didn't mean that this patch is unnecessary. But the question is that given driver has to deal with race between timeout and normal completion, why don't you follow blk-mq's way to move the atomic state change into __blk_complete_request()? Thanks, Ming Lei