From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-48.mta0.migadu.com [91.218.175.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E374A41F342 for ; Wed, 12 Aug 2026 09:57:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786528639; cv=none; b=u8bn1nCR8MwM1IUtykEr79q6AbS9SRpM9kf6kFKDfV6e9xRNuqqWaTRmPMkvraOpw1jEBt3bnW87CF+tZRqyO15quW9nK4RlDeY4VMNZnY/mU9oakqM6guyCSijeOgBsvqivClrNAjlqoUa4GYQws/YREId31v1tq0YyIKSjVTE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786528639; c=relaxed/simple; bh=YBnyvyc75sBYBQiEBfOzBDUagZL06PaEKMK/eukkudM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FdRXLDhFm9mzJEeOSjQ7QHuXmDbcTyE0UvBM7h32CvQy+mj1ja69d8BsnXzkIAAjIZ79x3LdWEOWKPSj8K0YbS42GtT1zGtmMukuf7gIXvyzM12cV+Mm2xgtvqbaqG2wIYR/lF1jSh5YtMoicGEnQE5+ouGeIXjJMhtWdFyauxc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=BgOcZ2Jo; arc=none smtp.client-ip=91.218.175.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="BgOcZ2Jo" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=YBnyvyc75sBYBQiEBfOzBDUagZL06PaEKMK/eukkudM=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786528634; v=1; x=1787133434; b=BgOcZ2JogmOB7fD/iEpncMjVjoSfLyBTolLkLiDJicyG/43sVaeFyg15sRUb/StFwVzo+ZRH QEer238Jj8+xxEgmKDPMezeeDbq84fQ7QzNe7WtH/OLA3ITPCgSfZpHa7JndGOOs4V7s2uLcqwE zleu1XOrfHvsDrk+8n0FgZYM= X-Envelope-To: linux-kernel@vger.kernel.org Received: from [IPV6:2a02:6b6f:e75b:1900:855:edd6:ce7b:4965] (2a02:6b6f:e75b:1900:855:edd6:ce7b:4965) by smtp.migadu.com with ESMTPS id 7f9ab11aacc6e042; Wed, 12 Aug 2026 09:55:59 +0000 X-Migadu-Scanner: mta11.migadu.com Authentication-Results: mta11.migadu.com; none Message-ID: <25b34f95-ca45-451e-9efe-3509788b37ce@linux.dev> Date: Wed, 12 Aug 2026 10:55:50 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3] blk-iolatency: clear delay state when freeing policy data To: Tejun Heo Cc: axboe@kernel.dk, cgroups@vger.kernel.org, josef@toxicpanda.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, shakeel.butt@linux.dev, hannes@cmpxchg.org, riel@surriel.com, kernel-team@meta.com References: <20260806183742.946953-1-usama.arif@linux.dev> <20260806183742.946953-2-usama.arif@linux.dev> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 10/08/2026 19:48, Tejun Heo wrote: > On Thu, Aug 06, 2026 at 11:37:18AM -0700, Usama Arif wrote: >> static void iolatency_pd_free(struct blkg_policy_data *pd) >> { >> + struct blkcg_gq *blkg = pd_to_blkg(pd); >> + >> + /* >> + * Groups throttled as collateral have min_lat_nsec == 0, so >> + * iolatency_pd_offline() leaves their delay set. Drop it here, where >> + * no in-flight bio can re-arm it via check_scale_change(). >> + */ >> + if (blkg) > > When can blkg be NULL here? > > Thanks. > Not in the normal case. pd->blkg is only set when the pd is attached to a blkg. blkcg_activate_policy() pre-allocates one outside the queue_lock when the GFP_NOWAIT allocation fails, and frees it through pd_free_fn() if it ends up unused — both at the retry and at the out: label. That pd never had ->blkg assigned. It reads as NULL rather than garbage because iolatency_pd_alloc() uses kzalloc_node(). Good to keep as a guard in this case?