Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp5516160imm; Tue, 12 Jun 2018 08:59:44 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJOdICcWkHlSG3jxgxAGUGywRr90JLJD0NzOd+I9n4loqHw3ajBgzENmI2C/yAPkdfbcbUm X-Received: by 2002:a65:4e09:: with SMTP id r9-v6mr774956pgt.369.1528819184314; Tue, 12 Jun 2018 08:59:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528819184; cv=none; d=google.com; s=arc-20160816; b=WDyQRsAPzap8yUmhA3VwFBQQcX/0yc+qAng7EMr8RRbPRdTFfVZI70JmTAdB0PTjX9 q/0W+lz9kw8GcQBo681izhMwNRqapMdhBYfIwZ8CTthVKCDcsKFrmTYO0z+cD17K7900 yygWBn6TpPdtaWmTlKFfArP+wlYoIJ9i8s2LgYKbh/TBy7cf7oFtFm6W7sR7who1q4x+ 8oMwqdskAilatMmI9KgvN0VthuU30N9VlApqOLKCsNQ71GUEG5qDRi5hfXw+qjRWFSvm 7t1UST/D4Efc0sOw3EAW5YSTF95qH3WVJujsfKUnc3OgkSntxHcgvxVY2PO8qgUHbp+M H1Pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=NTQMVO6FP0JufDK/eYcyCmgMw53EedLeFbsq7AST1W8=; b=fEWRS6u6bknq4eNVNmec44Moxul9BAoIVk3zVWbAP2D2Ihd1ha0vqtmiW7fAZUKsZr WaImURXqM78QYt4T5e79CU2uGYrMzNfMQNAzvnDRTJVr3CfwLEqdhvQrFVtWLKRO0Osc GbAsEu0ml/bh1GStPrO0HunnWxtqAo1bnhScuT2LdO0Cyz7LKhTFNWH4SuJwTKn/vjnD V7lZdRLd9UPLvMcA737IexjVmOCfkhJf7opWvZ3RzuVHoTmad3/AUs4RHHaCPDcKj/sI ljZ7ftRJaMyx6CHVhnEGgnnw7t4c2HERszOlgZESjGcBNhDSGe8+osdyPK3RqX4HmRAw O5LA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g25-v6si319708pgn.613.2018.06.12.08.58.59; Tue, 12 Jun 2018 08:59:44 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934190AbeFLP56 (ORCPT + 99 others); Tue, 12 Jun 2018 11:57:58 -0400 Received: from mx2.suse.de ([195.135.220.15]:52926 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933439AbeFLP55 (ORCPT ); Tue, 12 Jun 2018 11:57:57 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5840CAF94; Tue, 12 Jun 2018 15:57:55 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 74E511E0516; Tue, 12 Jun 2018 17:57:54 +0200 (CEST) Date: Tue, 12 Jun 2018 17:57:54 +0200 From: Jan Kara To: Tejun Heo Cc: Jan Kara , Tetsuo Handa , Dmitry Vyukov , Jens Axboe , syzbot , syzkaller-bugs , linux-fsdevel , LKML , Al Viro , Dave Chinner , linux-block@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH] bdi: Fix another oops in wb_workfn() Message-ID: <20180612155754.x5k2yndh5t6wlmpy@quack2.suse.cz> References: <2b437c6f-3e10-3d83-bdf3-82075d3eaa1a@i-love.sakura.ne.jp> <3cf4b0e3-31b6-8cdc-7c1e-15ba575a7879@i-love.sakura.ne.jp> <20180611091248.2i6nt27h5mxrodm2@quack2.suse.cz> <20180611160131.GQ1351649@devbig577.frc2.facebook.com> <20180611162920.mwapvuqotvhkntt3@quack2.suse.cz> <20180611172053.GR1351649@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180611172053.GR1351649@devbig577.frc2.facebook.com> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 11-06-18 10:20:53, Tejun Heo wrote: > Hello, > > On Mon, Jun 11, 2018 at 06:29:20PM +0200, Jan Kara wrote: > > > Would something like the following work or am I missing the point > > > entirely? > > > > I was pondering the same solution for a while but I think it won't work. > > The problem is that e.g. wb_memcg_offline() could have already removed > > wb from the radix tree but it is still pending in bdi->wb_list > > (wb_shutdown() has not run yet) and so we'd drop reference we didn't get. > > Yeah, right, so the root cause is that we're walking the wb_list while > holding lock and expecting the object to stay there even after lock is > released. Hmm... we can use a mutex to synchronize the two > destruction paths. It's not like they're hot paths anyway. Hmm, do you mean like having a per-bdi or even a global mutex that would protect whole wb_shutdown()? Yes, that should work and we could get rid of WB_shutting_down bit as well with that. Just it seems a bit strange to introduce a mutex only to synchronize these two shutdown paths - usually locks protect data structures and in this case we have cgwb_lock for that so it looks like a duplication from a first look. Honza -- Jan Kara SUSE Labs, CR