linux-kernel - Re: [PATCH 1/4] blkcg: Drop unnecessary RCU read [un]locks from blkg_conf

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Jan 2023 08:24:08 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Christoph Hellwig <hch@....de>
Cc:     axboe@...nel.dk, josef@...icpanda.com, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] blkcg: Drop unnecessary RCU read [un]locks from
 blkg_conf_prep/finish()

Hello,

On Tue, Jan 10, 2023 at 07:49:00AM +0100, Christoph Hellwig wrote:
> On Mon, Jan 09, 2023 at 10:48:55AM -1000, Tejun Heo wrote:
> > Now that all RCU flavors have been combined, holding a spin lock, disabling
> > irq, disabling preemption all imply RCU read lock.
> 
> Can you write it like this in the commit log, please? 

Sure, will do.

> > I can drop the changes but this actually bothers me. The annotation has been
> > broken for a *long* time and nobody noticed. Furthermore, I can't remember a
> > time when __acquires/__releases notation caught anything that lockdep
> > couldn't trivially and can't even think of a way how it could. AFAICS, these
> > annotations don't contribute anything other than preservation of themselves.
> > I don't see why we would want to keep them.
> 
> People have noticed it.  It just hasn't been a priority as there are
> lots of even more problematic things.

That doesn't really shed a positive light on them, does it? I'll drop this
part but can you think of actual reasons to keep these around other than to
keep sparse happy? I'm genuninely curious and have asked several people.
Nobody had a good answer.

Thanks.

-- 
tejun