From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753545AbdLUNu7 (ORCPT ); Thu, 21 Dec 2017 08:50:59 -0500 Received: from mail-qk0-f172.google.com ([209.85.220.172]:39763 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752816AbdLUNuz (ORCPT ); Thu, 21 Dec 2017 08:50:55 -0500 X-Google-Smtp-Source: ACJfBosxiMvciHXsxfKUPP5+5D9XNdzw2/k9mut23UjXbbg9FQAEXR9wKAlFEsrU9H68jrgUib9UGw== Date: Thu, 21 Dec 2017 05:50:51 -0800 From: Tejun Heo To: "jianchao.wang" Cc: jbacik@fb.com, jack@suse.cz, axboe@kernel.dk, clm@fb.com, kernel-team@fb.com, linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org, peterz@infradead.org, Bart.VanAssche@wdc.com Subject: Re: [PATCH 5/7] blk-mq: remove REQ_ATOM_COMPLETE usages from blk-mq Message-ID: <20171221135051.GE1084507@devbig577.frc2.facebook.com> References: <20171216120726.517153-1-tj@kernel.org> <20171216120726.517153-6-tj@kernel.org> <64dfa760-d433-1537-9bc6-b12cda3c9dc6@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64dfa760-d433-1537-9bc6-b12cda3c9dc6@oracle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Thu, Dec 21, 2017 at 11:56:49AM +0800, jianchao.wang wrote: > It's worrying that even though the blk_mark_rq_complete() here is intended to synchronize with > timeout path, but it indeed give the blk_mq_complete_request() the capability to exclude with > itself. Maybe this capability should be reserved. Can you explain further how that'd help? The problem there is that if you have two competing completions, where one isn't a timeout, there's nothing synchronizing the reuse of the request. IOW, the losing one can easily complete the next recycle instance. The atomic bitops might feel like more protection but it's just feels. Thanks. -- tejun