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=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 313F3C4361B for ; Thu, 17 Dec 2020 14:03:47 +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 A282E2360D for ; Thu, 17 Dec 2020 14:03:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A282E2360D Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=virtuozzo.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:54260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kptsf-0002p5-87 for qemu-devel@archiver.kernel.org; Thu, 17 Dec 2020 09:03:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kptqG-0001AP-4x; Thu, 17 Dec 2020 09:01:16 -0500 Received: from mail-eopbgr00095.outbound.protection.outlook.com ([40.107.0.95]:62852 helo=EUR02-AM5-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kptq8-0004O8-NA; Thu, 17 Dec 2020 09:01:14 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fMAGZInbdk2Hru95/QMExIdpX8OzG69oehlLcl2cc1KkhGgnb6o6Ve02XgOwD/jdNwR2SIoC2YcyVbx4QH5YENW23OEor4BCqdi0KtYvx34hUxWwzV2nYLNUN0VjTDfpFQcd04stEuZTFmntsu0MRHKy3Y1PAMOW3JUTBrDBXxwV2JKwVkzubX4cM7lYYdTEU5XU4sRWLnSqnIInzWy1SWJ+crurAczRE5JsayJxltV5QXg4+dzc19BKz73VDSDIFGCRD7U9qrxlCJC808sJyTm+sIL0WpL/qcFprtL93vh7Qu6efQlGuuO1bWeqZNQJKcFqrMMjX7HZcJW/Chwy6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pO4nCuCyX73aaYqdOq4oxM1ZPe9FqdWAsp0oFeIBq2g=; b=Xu3/FIpd5Uuq4jcrALsi+KOTiqmF8JIJuh2uwOHOsqPYphsvwO9acnuh4x+eanu/Pe/V/mc2RBjAd7m1CrWynmotEy6bvzgTu1EpMwvBB1GCEVYmnDEmDwFncQIpavVljcdktVhSmPxRa20A2DuzJax6N94LAeXNfJblAVFS1ZLdJuqC5KMyLV+61pbaTUJ/vu9hc47LP5t9eBnaFUmV6H2KyxevGEdUv+cypeWm4TMtFAU7Iphp4JfitdsW1TISnHdH1DWgG/j2ljHyDAae6lspNNJOD6coG5mijEpHbEp9C9thQZ7fq38ygXrohCuPj8+23CvLJUtx7H2v0T5cFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=virtuozzo.com; dmarc=pass action=none header.from=virtuozzo.com; dkim=pass header.d=virtuozzo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtuozzo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pO4nCuCyX73aaYqdOq4oxM1ZPe9FqdWAsp0oFeIBq2g=; b=WiTxmDWDLW8avJU6t00WZ+/3mHPPB0sVOfK9iSdt28xe1Zh+4cvuIQX0XIdMmIx6c7vzg0zbICauRwVYwAynYgZWNrU+LO+5fInyzltIicWI+5iYaq0fxomTspfuXctvz5IOTEvWGQ+vzPY27v4Bk/S3Eo4WGVBdngjJuapCuWs= Authentication-Results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=virtuozzo.com; Received: from AM7PR08MB5494.eurprd08.prod.outlook.com (2603:10a6:20b:dc::15) by AS8PR08MB5944.eurprd08.prod.outlook.com (2603:10a6:20b:297::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.24; Thu, 17 Dec 2020 14:01:05 +0000 Received: from AM7PR08MB5494.eurprd08.prod.outlook.com ([fe80::d585:99a4:d7a4:d478]) by AM7PR08MB5494.eurprd08.prod.outlook.com ([fe80::d585:99a4:d7a4:d478%4]) with mapi id 15.20.3654.024; Thu, 17 Dec 2020 14:01:05 +0000 Subject: Re: [PATCH v2 2/4] block: Avoid processing BDS twice in bdrv_set_aio_context_ignore() To: Kevin Wolf References: <20201215121233.GD8185@merkur.fritz.box> <20201215131527.evpidxevevtfy54n@mhamilton> <20201215150119.GE8185@merkur.fritz.box> <20201215172337.w7vcn2woze2ejgco@mhamilton> <20201216123514.GD7548@merkur.fritz.box> <20201216145502.yiejsw47q5pfbzio@mhamilton> <20201216183102.GH7548@merkur.fritz.box> <20201217093744.tg6ik73o45nidcs4@mhamilton> <20201217105830.GA12328@merkur.fritz.box> <20201217130602.GB12328@merkur.fritz.box> From: Vladimir Sementsov-Ogievskiy Message-ID: <84380429-388c-f8c3-d318-788eda550c97@virtuozzo.com> Date: Thu, 17 Dec 2020 17:01:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 In-Reply-To: <20201217130602.GB12328@merkur.fritz.box> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [185.215.60.92] X-ClientProxiedBy: AM0PR06CA0089.eurprd06.prod.outlook.com (2603:10a6:208:fa::30) To AM7PR08MB5494.eurprd08.prod.outlook.com (2603:10a6:20b:dc::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.100.5] (185.215.60.92) by AM0PR06CA0089.eurprd06.prod.outlook.com (2603:10a6:208:fa::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12 via Frontend Transport; Thu, 17 Dec 2020 14:01:04 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f7a67be9-9a09-4319-25fc-08d8a29431fe X-MS-TrafficTypeDiagnostic: AS8PR08MB5944: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zKD4Hd47SKkjtLbHHKlaM/C2vhOfTZElmjvrxSH/ur+DsEq6eXQvACbbsXT5heL79zWUclkce5+K0XZhGA8VZLf3cLLrEDSuNg11+FhxAt8er8gBVROXr71k/8F3MPqOFExxeLKuRkvJ+b0kRP0VT1Icc9NKAjkQ8ZzZKb3fxZrxZujuj+5aCagrmZN/Y6BEg/512GHHvqW8GsozsWCedUDOo696iQ1SwopyYvVpWg5/KSn+JN5mGyetJvrblIb85/QKH6qOReqNuGZJM0FdEf8dK0e4QxoUWpYlLoPxy8Y4/zW9nMa0+gdxOMfifmx4hiHjj7IKyQnndklKAN3stBIcQyD0vZsYQVAuCp7ZD0+edv8T5uBm7wDmB4Smu5ffyvpelYCGo0zwT95kK2AwAfb0mRD2V42dp07yXV5KH0I= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR08MB5494.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(136003)(39830400003)(376002)(7416002)(478600001)(66946007)(6486002)(6916009)(36756003)(316002)(66556008)(8936002)(16526019)(16576012)(66476007)(5660300002)(31696002)(54906003)(186003)(8676002)(2616005)(956004)(4326008)(31686004)(83380400001)(86362001)(2906002)(52116002)(26005)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?MDVZUzVJZHJ2blNjT0hJbEtDcTFaeEs5OUhreE9pSC92UXE2ZS85M3ZQQi9C?= =?utf-8?B?VlNHbm9WN3RTeHhoTEFiT0pvem9ndXYvYU1xQWJ1V1NBT3RBQzFqZGRBMDFJ?= =?utf-8?B?YVc3bG5kTUFjdkkrY0ZaN0hORGFhSmJIMDNLUTFhcDhjd0hTV0x2d2RBYlZw?= =?utf-8?B?NUtGdVMxZ1Mva1Nhdmc2djBYTERQMG1UR0RCZm9LcWtHcWZWSmlHbzhiamlG?= =?utf-8?B?NE81alV5bGJKSldDWnBndXg5WEpZQ2ZVR2NoRXNkdTR1cm0xRjVkV0pYbXFn?= =?utf-8?B?TCtUeGk2N2NINGNvUkJndmU1WmdTN1RoS01FQ1IweEcyMXFSNk5Qc2tXR2Nj?= =?utf-8?B?aTlKVmtRQ1VSSVdnZGdqT2hNOWdneTFyV2psZ2tWUHdBVGUyOTc0d2JpNVE2?= =?utf-8?B?SGxRbmsxNFE2OVMvbEllMW5UQjllR0NlSGZpRU1LdFlXS2JrNEo0ZExZVUVT?= =?utf-8?B?dDRjQ1VEM1psM2s2dTFQck1OV2hrRzZtYkl4QkdrNWZmeDFzd1ByOTZNalFG?= =?utf-8?B?SFFmMzFrN3QxSSsxS2d3MTVNSnNnWXdUU2g1WUlUUnBicmZFNEJoak5XcERy?= =?utf-8?B?TGpOY1hCMU1kWFBqVmxWOEdZQ0dsalhsM1drcmp2bnpkd3pJaDBuY3lNcVUw?= =?utf-8?B?SkZ4UTQyVVhCNGUvdHBab3V5RE9DTWxIbFFZWnVjWDdpKzBQR2ZmdFVSNFpB?= =?utf-8?B?MmNuSDJrVFFvalJZUXRhK21uc2xiVVpxaHFuRm5vQUN0TE8zZlZqWFIrbkJw?= =?utf-8?B?MU9DdCtkLzJGOW5IbTYraEJyRzRHYWxEdHlwTGlnRWxNdWFUR1A5czU4ZHY3?= =?utf-8?B?TldQVXlnWHJCQnhWWGVuQm1uZVk2SXE0RWRHNlNHMFVjeEhBVXpuRFIvQzFL?= =?utf-8?B?bU1OenI2RExsaVFoTytjY1BzTjIrdFNkWlp1MkhQSFZuaVBvZTlEZU9KRVZG?= =?utf-8?B?RXNYMnI5RW5nYUNINnpydDdUM1dVbXVSQ1k3c0ZzM0JkRlU0ZTZIOHNRWXhT?= =?utf-8?B?c0dLUjJTOGZUVW1BbnN6aCs2L2JRdWIrWlBST0gzWmRSKzNPYll2d0Z6R2JM?= =?utf-8?B?VkdDNmFrcUVQTVc2Nll3aU9BNmtRRTJsY1pVek00SU5MWCs2Vjc1YjM1aHFa?= =?utf-8?B?OUVpOFltSWhyTktpRmRBcTZrQWdqelB5WWVoR1RKK3FHNFhjVzFvb0l2bWxq?= =?utf-8?B?Q2pnOVhYYUh5eFN0SHRWaVVsNnowSGhucWFEdTFWTW9MV3NObjJ1dXJWTXkx?= =?utf-8?B?eFNheEdrUnRqZ2hvMFRPQ2x3bFlyNmZEckYvb0FEVUZzaCtyZE5rc0FqMHlM?= =?utf-8?Q?/1cS4y2Fn92Ofo4MGTRK3lYsBfTaPNK50g?= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-AuthSource: AM7PR08MB5494.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2020 14:01:04.9916 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 0bc7f26d-0264-416e-a6fc-8352af79c58f X-MS-Exchange-CrossTenant-Network-Message-Id: f7a67be9-9a09-4319-25fc-08d8a29431fe X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: aRzVLTntScyIFkZhiAbvnTglALE6I5m9iN58xbIuONPDSJTvxm8SM51jkBuHkTE2y/AdczRjsJGJQa+oBxyCXHu85UGFTxd08liuxyhtnbc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB5944 Received-SPF: pass client-ip=40.107.0.95; envelope-from=vsementsov@virtuozzo.com; helo=EUR02-AM5-obe.outbound.protection.outlook.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FORGED_SPF_HELO=1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, T_SPF_TEMPERROR=0.01 autolearn=no 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: Fam Zheng , Stefano Stabellini , Sergio Lopez , qemu-block@nongnu.org, "Michael S. Tsirkin" , Paul Durrant , qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , xen-devel@lists.xenproject.org, Anthony Perard , Paolo Bonzini Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 17.12.2020 16:06, Kevin Wolf wrote: > Am 17.12.2020 um 13:50 hat Vladimir Sementsov-Ogievskiy geschrieben: >> 17.12.2020 13:58, Kevin Wolf wrote: >>> Am 17.12.2020 um 10:37 hat Sergio Lopez geschrieben: >>>> On Wed, Dec 16, 2020 at 07:31:02PM +0100, Kevin Wolf wrote: >>>>> Am 16.12.2020 um 15:55 hat Sergio Lopez geschrieben: >>>>>> On Wed, Dec 16, 2020 at 01:35:14PM +0100, Kevin Wolf wrote: >>>>>>> Anyway, trying to reconstruct the block graph with BdrvChild pointers >>>>>>> annotated at the edges: >>>>>>> >>>>>>> BlockBackend >>>>>>> | >>>>>>> v >>>>>>> backup-top ------------------------+ >>>>>>> | | | >>>>>>> | +-----------------------+ | >>>>>>> | 0x5655068b8510 | | 0x565505e3c450 >>>>>>> | | | >>>>>>> | 0x565505e42090 | | >>>>>>> v | | >>>>>>> qcow2 ---------------------+ | | >>>>>>> | | | | >>>>>>> | 0x565505e52060 | | | ??? [1] >>>>>>> | | | | | >>>>>>> v 0x5655066a34d0 | | | | 0x565505fc7aa0 >>>>>>> file v v v v >>>>>>> qcow2 (backing) >>>>>>> | >>>>>>> | 0x565505e41d20 >>>>>>> v >>>>>>> file >>>>>>> >>>>>>> [1] This seems to be a BdrvChild with a non-BDS parent. Probably a >>>>>>> BdrvChild directly owned by the backup job. >>>>>>> >>>>>>>> So it seems this is happening: >>>>>>>> >>>>>>>> backup-top (5e48030) <---------| (5) >>>>>>>> | | | >>>>>>>> | | (6) ------------> qcow2 (5fbf660) >>>>>>>> | ^ | >>>>>>>> | (3) | | (4) >>>>>>>> |-> (1) qcow2 (5e5d420) ----- |-> file (6bc0c00) >>>>>>>> | >>>>>>>> |-> (2) file (5e52060) >>>>>>>> >>>>>>>> backup-top (5e48030), the BDS that was passed as argument in the first >>>>>>>> bdrv_set_aio_context_ignore() call, is re-entered when qcow2 (5fbf660) >>>>>>>> is processing its parents, and the latter is also re-entered when the >>>>>>>> first one starts processing its children again. >>>>>>> >>>>>>> Yes, but look at the BdrvChild pointers, it is through different edges >>>>>>> that we come back to the same node. No BdrvChild is used twice. >>>>>>> >>>>>>> If backup-top had added all of its children to the ignore list before >>>>>>> calling into the overlay qcow2, the backing qcow2 wouldn't eventually >>>>>>> have called back into backup-top. >>>>>> >>>>>> I've tested a patch that first adds every child to the ignore list, >>>>>> and then processes those that weren't there before, as you suggested >>>>>> on a previous email. With that, the offending qcow2 is not re-entered, >>>>>> so we avoid the crash, but backup-top is still entered twice: >>>>> >>>>> I think we also need to every parent to the ignore list before calling >>>>> callbacks, though it doesn't look like this is the problem you're >>>>> currently seeing. >>>> >>>> I agree. >>>> >>>>>> bs=0x560db0e3b030 (backup-top) enter >>>>>> bs=0x560db0e3b030 (backup-top) processing children >>>>>> bs=0x560db0e3b030 (backup-top) calling bsaci child=0x560db0e2f450 (child->bs=0x560db0fb2660) >>>>>> bs=0x560db0fb2660 (qcow2) enter >>>>>> bs=0x560db0fb2660 (qcow2) processing children >>>>>> bs=0x560db0fb2660 (qcow2) calling bsaci child=0x560db0e34d20 (child->bs=0x560db1bb3c00) >>>>>> bs=0x560db1bb3c00 (file) enter >>>>>> bs=0x560db1bb3c00 (file) processing children >>>>>> bs=0x560db1bb3c00 (file) processing parents >>>>>> bs=0x560db1bb3c00 (file) processing itself >>>>>> bs=0x560db0fb2660 (qcow2) calling bsaci child=0x560db16964d0 (child->bs=0x560db0e50420) >>>>>> bs=0x560db0e50420 (qcow2) enter >>>>>> bs=0x560db0e50420 (qcow2) processing children >>>>>> bs=0x560db0e50420 (qcow2) calling bsaci child=0x560db0e34ea0 (child->bs=0x560db0e45060) >>>>>> bs=0x560db0e45060 (file) enter >>>>>> bs=0x560db0e45060 (file) processing children >>>>>> bs=0x560db0e45060 (file) processing parents >>>>>> bs=0x560db0e45060 (file) processing itself >>>>>> bs=0x560db0e50420 (qcow2) processing parents >>>>>> bs=0x560db0e50420 (qcow2) processing itself >>>>>> bs=0x560db0fb2660 (qcow2) processing parents >>>>>> bs=0x560db0fb2660 (qcow2) calling set_aio_ctx child=0x560db1672860 >>>>>> bs=0x560db0fb2660 (qcow2) calling set_aio_ctx child=0x560db1b14a20 >>>>>> bs=0x560db0e3b030 (backup-top) enter >>>>>> bs=0x560db0e3b030 (backup-top) processing children >>>>>> bs=0x560db0e3b030 (backup-top) processing parents >>>>>> bs=0x560db0e3b030 (backup-top) calling set_aio_ctx child=0x560db0e332d0 >>>>>> bs=0x560db0e3b030 (backup-top) processing itself >>>>>> bs=0x560db0fb2660 (qcow2) processing itself >>>>>> bs=0x560db0e3b030 (backup-top) calling bsaci child=0x560db0e35090 (child->bs=0x560db0e50420) >>>>>> bs=0x560db0e50420 (qcow2) enter >>>>>> bs=0x560db0e3b030 (backup-top) processing parents >>>>>> bs=0x560db0e3b030 (backup-top) processing itself >>>>>> >>>>>> I see that "blk_do_set_aio_context()" passes "blk->root" to >>>>>> "bdrv_child_try_set_aio_context()" so it's already in the ignore list, >>>>>> so I'm not sure what's happening here. Is backup-top is referenced >>>>>> from two different BdrvChild or is "blk->root" not pointing to >>>>>> backup-top's BDS? >>>>> >>>>> The second time that backup-top is entered, it is not as the BDS of >>>>> blk->root, but as the parent node of the overlay qcow2. Which is >>>>> interesting, because last time it was still the backing qcow2, so the >>>>> change did have _some_ effect. >>>>> >>>>> The part that I don't understand is why you still get the line with >>>>> child=0x560db1b14a20, because when you add all children to the ignore >>>>> list first, that should have been put into the ignore list as one of the >>>>> first things in the whole process (when backup-top was first entered). >>>>> >>>>> Is 0x560db1b14a20 a BdrvChild that has backup-top as its opaque value, >>>>> but isn't actually present in backup-top's bs->children? >>>> >>>> Exactly, that line corresponds to this chunk of code: >>>> >>>> <---- begin ----> >>>> QLIST_FOREACH(child, &bs->parents, next_parent) { >>>> if (g_slist_find(*ignore, child)) { >>>> continue; >>>> } >>>> assert(child->klass->set_aio_ctx); >>>> *ignore = g_slist_prepend(*ignore, child); >>>> fprintf(stderr, "bs=%p (%s) calling set_aio_ctx child=%p\n", bs, bs->drv->format_name, child); >>>> child->klass->set_aio_ctx(child, new_context, ignore); >>>> } >>>> <---- end ----> >>>> >>>> Do you think it's safe to re-enter backup-top, or should we look for a >>>> way to avoid this? >>> >>> I think it should be avoided, but I don't understand why putting all >>> children of backup-top into the ignore list doesn't already avoid it. If >>> backup-top is in the parents list of qcow2, then qcow2 should be in the >>> children list of backup-top and therefore the BdrvChild should already >>> be in the ignore list. >>> >>> The only way I can explain this is that backup-top and qcow2 have >>> different ideas about which BdrvChild objects exist that connect them. >>> Or that the graph changes between both places, but I don't see how that >>> could happen in bdrv_set_aio_context_ignore(). >>> >> >> bdrv_set_aio_context_ignore() do bdrv_drained_begin().. As I reported >> recently, nothing prevents some job finish and do graph modification >> during some another drained section. It may be the case. > > Good point, this might be the same bug then. > > If everything worked correctly, a job completion could only happen on > the outer bdrv_set_aio_context_ignore(). But after that, we are already > in a drain section, so the job should be quiesced and a second drain > shouldn't cause any additional graph changes. > > I would have to go back to the other discussion, but I think it was > related to block jobs that are already in the completion process and > keep moving forward even though they are supposed to be quiesced. > > If I remember correctly, actually pausing them at this point looked > difficult. Maybe what we should then do is letting .drained_poll return > true until they have actually fully completed? > > Ah, but was this something that would deadlock because the job > completion callbacks use drain sections themselves? Hmm.. I've recently sent good example of dead-lock in email "aio-poll dead-lock".. I don't have better idea than moving all graph modifications (together with corresponding drained sections) into coroutines and protect by global coroutine mutex. > >> If backup-top involved, I can suppose that graph modification is in >> backup_clean, when we remove the filter.. Who is making >> set_aio_context in the issue? I mean, what is the backtrace of >> bdrv_set_aio_context_ignore()? > > Sergio, can you provide the backtrace and also test if the theory with a > job completion in the middle of the process is what you actually hit? > > Kevin > -- Best regards, Vladimir