From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761901Ab2CORSP (ORCPT ); Thu, 15 Mar 2012 13:18:15 -0400 Received: from mail-pz0-f46.google.com ([209.85.210.46]:60318 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755769Ab2CORSN (ORCPT ); Thu, 15 Mar 2012 13:18:13 -0400 Date: Thu, 15 Mar 2012 10:18:08 -0700 From: Tejun Heo To: Vivek Goyal Cc: Fengguang Wu , Jens Axboe , LKML Subject: Re: [PATCH block/for-3.4/core] cfq: fix cfqg ref handling when BLK_CGROUP && !CFQ_GROUP_IOSCHED Message-ID: <20120315171808.GF32137@google.com> References: <20120315094945.GA3205@localhost> <20120315163546.GA32137@google.com> <20120315164621.GD3253@redhat.com> <20120315165057.GB32137@google.com> <20120315170100.GF3253@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120315170100.GF3253@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 15, 2012 at 01:01:00PM -0400, Vivek Goyal wrote: > On Thu, Mar 15, 2012 at 09:50:57AM -0700, Tejun Heo wrote: > > > > [..] > > > > @@ -3533,7 +3551,7 @@ static int cfq_init_queue(struct request > > > > > > > > spin_lock_irq(q->queue_lock); > > > > cfq_link_cfqq_cfqg(&cfqd->oom_cfqq, cfqd->root_group); > > > > - blkg_put(cfqg_to_blkg(cfqd->root_group)); > > > > + cfqg_put(cfqd->root_group); > > > > > > This seems to be a spurious cfqg_put()? Which reference we are putting > > > down here? > > > > The extra ref from cfq_link_cfqq_cfqg() for oom_cfqq; otherwise, we > > need an extra cfq_put() in cfq_exit_queue(). I thought I wrote > > comment about that somewhere. Hmmm.... apparently not. The thing is > > that oom_cfqq doesn't go through proper cfqq destruction and thus > > never puts the extra ref to root cfqg. > > Ok. Is cfq_exit_queue() a better place to put down this reference > explicitly with a comment. Even if you keep it here, atleast a comment > is required. It is not obvious at all (atleast to me). Ah... the comment actually already is there. /* * Our fallback cfqq if cfq_find_alloc_queue() runs into OOM issues. * Grab a permanent reference to it, so that the normal code flow * will not attempt to free it. oom_cfqq is linked to root_group * but shouldn't hold a reference as it'll never be unlinked. Lose * the reference from linking right away. */ -- tejun