Received-SPF: pass (google.com: domain of linux-kernel+bounces-214056-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Sender: Tejun Heo <htejun@gmail.com>
Date: Thu, 13 Jun 2024 12:20:24 -1000
From: Tejun Heo <tj@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org, kernel-team@fb.com, newella@fb.com,
	hch@lst.de
Subject: Re: [PATCH 12/27] blk-iocost: grab ioc->lock for debt handling
Message-ID: <ZmtwqDsMnTJHQB6o@slm.duckdns.org>
References: <20200901185257.645114-1-tj@kernel.org>
 <20200901185257.645114-13-tj@kernel.org>
 <45603be5-65ae-4d45-bfbe-22c3c1e22280@oracle.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45603be5-65ae-4d45-bfbe-22c3c1e22280@oracle.com>

Hello,

On Wed, Jun 12, 2024 at 12:33:19PM +0100, John Garry wrote:
...
> This generates the following sparse warnings on mainline today:
> 
>   CHECK   block/blk-iocost.c
> block/blk-iocost.c:685:9: warning: context imbalance in 'iocg_lock' -
> wrong count at exit
> block/blk-iocost.c:696:28: warning: context imbalance in 'iocg_unlock'
> - unexpected unlock
> 
> If we try to break iocg_lock() into one version for lock_ioc set and another
> for lock_ioc unset, we can solve the sparse issues for those functions, but
> then we get another sparse issue from the callsites for those functions:
> 
> block/blk-iocost.c:2679:17: warning: context imbalance in
> 'ioc_rqos_throttle' - different lock contexts for basic block
> 
> I tried to solve with a total ioc_rqos_throttle() re-org and much code
> duplication by calling the different lock and unlock versions from
> effectively 2x separate copies of ioc_rqos_throttle(), as sparse seems
> confused with how we call these functions. It's a total no-go.
> 
> Any simpler idea to solve these? Or just something to live with?

I kinda gave up on sparse lock checking as there's not much it can do that
lockdep can't and the annotations are too awkward and inconsistent
throughout the code base. So, my tendency is just to ignore it.

Thanks.

-- 
tejun