Received: by 10.192.165.156 with SMTP id m28csp985869imm; Wed, 11 Apr 2018 10:20:06 -0700 (PDT) X-Google-Smtp-Source: AIpwx49MY5AoAnBDHV1mOFu7Do2OuJZGcDLm+GWrOH6R0Dbf2z6wO4h6AWWmPqINP4hZowdW+6Lx X-Received: by 10.98.174.5 with SMTP id q5mr4730752pff.155.1523467206753; Wed, 11 Apr 2018 10:20:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523467206; cv=none; d=google.com; s=arc-20160816; b=s+94Bn9NN5NRbU+pOgcsaq/oMtClQIN2wxP3qA8BaLSJcJJJmSG+IzZ0tzjmwbdF2K w1m4tD8rrSanpGs8wB1S3C+LYAJcSVQfre+LnQyRhZlBV/nlvR2Rq4bs3DHQsb7+mv8G Db56txiI9DgPzLy2O1kEOnsVEr2WLdHh/YSdYHMtRhiIP+WpuPcxDCHzVEc4V2MjsD7s Gt84bqbMeqnMwiiOmUvCDkT6EmsbMRxO65XnPrq1LQ7oNXgwbMQGm5ErpjMX3UDZ3yI9 QVNOvPvoIzLENWPkUtieh3MdGzepeW0QSxNiAxX6Xhvfhakj/b2DobyjV2CP8vHIOZ46 eg/w== 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:dkim-signature:arc-authentication-results; bh=LtjK+V7HfaHCJayAEv+h83WuJ/MxLZSre2F8ToIN2r0=; b=VU/6wz6B8zBmm4plP4lyYBC9E6dVLjmcUGiEX7j0LIme1hmSEpCFyUp1OxjxBpP4dv nhMWyGjsCAIAIRnXxvdIKLgGSeRzP1tVEMQ5aQEmYlefHULfG7WCdBI7PpzaGAT/PRqA nzLTSDnglx1n2r8Phz9g3LsO3THxNGui+WVI3Bba/cdh6OJ2jStA4YxsgFyYXzmnLSN+ KvytAz1tLq0K0MGOWvEzMVze/Y2pMrenkJvtixroaADpF31qCr+kL2+UR4yH71zeVYos swOYYSLeEF9lstEvZj3j0CETzb6QSG1h22YVy3DWuunkm5kmroxltOFFnHVS4x8XjNBg VnLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=rfkn6+TA; 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 d1si1006523pgf.499.2018.04.11.10.19.29; Wed, 11 Apr 2018 10:20:06 -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=fail header.i=@gmail.com header.s=20161025 header.b=rfkn6+TA; 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 S1754032AbeDKRPo (ORCPT + 99 others); Wed, 11 Apr 2018 13:15:44 -0400 Received: from mail-yb0-f177.google.com ([209.85.213.177]:39304 "EHLO mail-yb0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753664AbeDKRPm (ORCPT ); Wed, 11 Apr 2018 13:15:42 -0400 Received: by mail-yb0-f177.google.com with SMTP id g197-v6so875240ybf.6; Wed, 11 Apr 2018 10:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=LtjK+V7HfaHCJayAEv+h83WuJ/MxLZSre2F8ToIN2r0=; b=rfkn6+TAz69qYM4SnXFSDgFPeViIQfkvQf4AVQ01n67NDIn6V/UdvEzRKm2+drPAA+ /o4ornH/tRtBCHggMfofJCwOo5it4pkft28a7I7qiZUu3wo/mDwlc4IeivdlEHS8OOtR 33yDGB1rkbrIKD8Zp7KSFdgIzIpGzNxWHf7187awNMxIozeCMKoDHTCXxAYTmvQRho2n UbQNndS2dhv5p8tTseRtDkuZzsdnlER88ZTEC5Aw95Z4heZu1SnUx8oy5c4Hbv6KijfE L/36CuB8XOYnp64YLl7ilnaNGzWyJ4Bqh1HGQ3zPODsN34mggL9EQVCHOd6dTn0larEH ZocA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=LtjK+V7HfaHCJayAEv+h83WuJ/MxLZSre2F8ToIN2r0=; b=MsBWyQe2ma3riJE3vQ3QWFbYUhp5DYfFkczyKFKXoCu2PnSGs2Ft6YUjK3nDiMd+qm zuHVqrQZ5bKiz6BPDK21h9lhsUjj1dsE0NGbenEBHLcJ1RMCPYMY9glWniRaA8+SYyi6 Re+NGUkzcD5CkBht79ooGJT9pRta3x2sZYwmA+GuIdgZSNA1VyqH++LvT2KA/g2YmJiu w9YTn7TEOl2jgflydZuoCoWHktrhs3ckZWE7pgN4iY66/ZF9oQHshyvZfGOeyAByAsYF eYSQsk7aCjYKFWjCbkiJRsfNtn9Fn8AKD0aJ6fuAZpZPEDb0wAMOgI2dch3EcSpQ0AdG HhpA== X-Gm-Message-State: ALQs6tBgI+C1ZJPPEH/bfWFdvIlnGyuX7Wvb/O5g0VzGIzRBIzQRphKX TcqM9zevk8+A/U2rnnyPdXf3S6bT X-Received: by 2002:a25:ce4c:: with SMTP id x73-v6mr2704027ybe.249.1523466941139; Wed, 11 Apr 2018 10:15:41 -0700 (PDT) Received: from localhost ([2620:10d:c091:200::1:e6ed]) by smtp.gmail.com with ESMTPSA id y195sm603642ywy.103.2018.04.11.10.15.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Apr 2018 10:15:40 -0700 (PDT) Date: Wed, 11 Apr 2018 10:15:38 -0700 From: "tj@kernel.org" To: Bart Van Assche Cc: "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "nborisov@suse.com" , "axboe@kernel.dk" , "shli@fb.com" , "gregkh@linuxfoundation.org" , "00moses.alexander00@gmail.com" <00moses.alexander00@gmail.com>, "arnd@arndb.de" , "joseph.qi@linux.alibaba.com" Subject: Re: [PATCH v2] blk-cgroup: remove entries in blkg_tree before queue release Message-ID: <20180411171538.GN793541@devbig577.frc2.facebook.com> References: <20180409220938.GI3126663@devbig577.frc2.facebook.com> <20180411101242.GA2322@gmail.com> <20180411142019.GG793541@devbig577.frc2.facebook.com> <20180411142859.GB2322@gmail.com> <20180411144616.GI793541@devbig577.frc2.facebook.com> <20180411145123.GJ793541@devbig577.frc2.facebook.com> <20180411145632.GK793541@devbig577.frc2.facebook.com> <20180411170018.GL793541@devbig577.frc2.facebook.com> <398bad36e2f01e37645a36d052d62136766ee88d.camel@wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <398bad36e2f01e37645a36d052d62136766ee88d.camel@wdc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Wed, Apr 11, 2018 at 05:06:41PM +0000, Bart Van Assche wrote: > A simple and effective solution is to dissociate a request queue from the > block cgroup controller before blk_cleanup_queue() returns. This is why commit > a063057d7c73 ("block: Fix a race between request queue removal and the block > cgroup controller") moved the blkcg_exit_queue() call from __blk_release_queue() > into blk_cleanup_queue(). which is broken. We can try to switch the lifetime model to revoking all live objects but that likely is a lot more involving than blindly moving blkg shootdown from release to cleanup. Implementing sever semantics is usually a lot more involved / fragile because it requires explicit participation from all users (exactly the same way revoking ->queue_lock is difficult). I'm not necessarily against switching to sever model, but what the patch did isn't that. It just moved some code without actually understanding or auditing what the implications are. Thanks. -- tejun