linux-kernel - Re: [PATCH 12/27] blk-iocost: grab ioc->lock for debt handling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZmtwqDsMnTJHQB6o@slm.duckdns.org>
Date: Thu, 13 Jun 2024 12:20:24 -1000
From: Tejun Heo <tj@...nel.org>
To: John Garry <john.g.garry@...cle.com>
Cc: axboe@...nel.dk, linux-block@...r.kernel.org, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, kernel-team@...com, newella@...com,
	hch@....de
Subject: Re: [PATCH 12/27] blk-iocost: grab ioc->lock for debt handling

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