From patchwork Sat Nov 21 03:29:06 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jens Axboe X-Patchwork-Id: 7673301 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E8D749F2EC for ; Sat, 21 Nov 2015 03:29:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 242DC2051F for ; Sat, 21 Nov 2015 03:29:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 24A412051D for ; Sat, 21 Nov 2015 03:29:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934510AbbKUD3M (ORCPT ); Fri, 20 Nov 2015 22:29:12 -0500 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:21243 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759664AbbKUD3M (ORCPT ); Fri, 20 Nov 2015 22:29:12 -0500 Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.15.0.59/8.15.0.59) with SMTP id tAL3O9tF031459; Fri, 20 Nov 2015 19:29:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=subject : to : references : cc : from : message-id : date : mime-version : in-reply-to : content-type; s=facebook; bh=Dh4tNYK4MaDtLMHpvQJo49fQtJviI6lTj1zL1ps3Cpk=; b=CzEj6/btu0oJNRK1WNCGNlV4Uy1UTrkQ6Bh2iwNpGFJJoC2Rs8cRkT4QLRgcWOuDX4dB BlUvRkUugqLVaOLB2n1AHVaKVw74otkeLOtsXw2yMgS8zCJoYRKvaZk7JHW2+6LUg3eW pLQDyx6gBP4wWhOomtJFITODUOCfgx8MULY= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 1y8rt9maa8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Nov 2015 19:29:09 -0800 Received: from [192.168.1.30] (192.168.54.13) by mail.thefacebook.com (192.168.16.22) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 20 Nov 2015 19:29:07 -0800 Subject: Re: [PATCH] Btrfs: fix a bug of sleeping in atomic context To: References: <1447984177-26795-1-git-send-email-bo.li.liu@oracle.com> <20151120131358.GC9887@ret.masoncoding.com> <564F9103.7060301@fb.com> <20151120230829.GB8096@localhost.localdomain> <564FD665.90603@fb.com> <20151121031421.GC8096@localhost.localdomain> CC: Chris Mason , From: Jens Axboe Message-ID: <564FE502.2050808@fb.com> Date: Fri, 20 Nov 2015 20:29:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151121031421.GC8096@localhost.localdomain> X-Originating-IP: [192.168.54.13] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-11-21_03:, , signatures=0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 11/20/2015 08:14 PM, Liu Bo wrote: > On Fri, Nov 20, 2015 at 07:26:45PM -0700, Jens Axboe wrote: >> On 11/20/2015 04:08 PM, Liu Bo wrote: >>> On Fri, Nov 20, 2015 at 02:30:43PM -0700, Jens Axboe wrote: >>>> On 11/20/2015 06:13 AM, Chris Mason wrote: >>>>> On Thu, Nov 19, 2015 at 05:49:37PM -0800, Liu Bo wrote: >>>>>> while xfstesting, this bug[1] is spotted by both btrfs/061 and btrfs/063, >>>>>> so those sub-stripe writes are gatherred into plug callback list and >>>>>> hopefully we can have a full stripe writes. >>>>>> >>>>>> However, while processing these plugged callbacks, it's within an atomic >>>>>> context which is provided by blk_sq_make_request() because of a get_cpu() >>>>>> in blk_mq_get_ctx(). >>>>>> >>>>>> This changes to always use btrfs_rmw_helper to complete the pending writes. >>>>>> >>>>> >>>>> Thanks Liu, but MD raid has the same troubles, we're not atomic in our unplugs. >>>>> >>>>> Jens? >>>> >>>> Yeah, blk-mq does have preemption disabled when it flushes, for the single >>>> queue setup. That's a bug. Attached is an untested patch that should fix it, >>>> can you try it? >>>> >>> >>> Although it runs into a warning one time of 50 tries, that was not atomic warning but another racy issue. >>> >>> WARNING: CPU: 2 PID: 8531 at fs/btrfs/ctree.c:1162 __btrfs_cow_block+0x431/0x610 [btrfs]() >>> >>> So overall the patch is good. >>> >>>> I'll rework this to be a proper patch, not convinced we want to add the new >>>> request before flush, that might destroy merging opportunities. I'll unify >>>> the mq/sq parts. >>> >>> That's true, xfstests didn't notice any performance difference but that cannot prove anything. >>> >>> I'll test the new patch when you send it out. >> >> Try this one, that should retain the plug issue characteristics we care >> about as well. > > The test does not complain any more, thank for the quick patch. > > Tested-by: Liu Bo Can I talk you into trying this one? It's simpler, does the same thing. We don't need to overcomplicate it, it's fine not having preempt disabled for adding to the list. diff --git a/block/blk-mq.c b/block/blk-mq.c index 3ae09de62f19..6d6f8feb48c0 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -1291,15 +1291,16 @@ static blk_qc_t blk_mq_make_request(struct request_queue *q, struct bio *bio) blk_mq_bio_to_request(rq, bio); /* - * we do limited pluging. If bio can be merged, do merge. + * We do limited pluging. If the bio can be merged, do that. * Otherwise the existing request in the plug list will be * issued. So the plug list will have one request at most */ if (plug) { /* * The plug list might get flushed before this. If that - * happens, same_queue_rq is invalid and plug list is empty - **/ + * happens, same_queue_rq is invalid and plug list is + * empty + */ if (same_queue_rq && !list_empty(&plug->mq_list)) { old_rq = same_queue_rq; list_del_init(&old_rq->queuelist); @@ -1380,12 +1381,15 @@ static blk_qc_t blk_sq_make_request(struct request_queue *q, struct bio *bio) blk_mq_bio_to_request(rq, bio); if (!request_count) trace_block_plug(q); - else if (request_count >= BLK_MAX_REQUEST_COUNT) { + + blk_mq_put_ctx(data.ctx); + + if (request_count >= BLK_MAX_REQUEST_COUNT) { blk_flush_plug_list(plug, false); trace_block_plug(q); } + list_add_tail(&rq->queuelist, &plug->mq_list); - blk_mq_put_ctx(data.ctx); return cookie; }