linux-kernel - Re: [RFC PATCH v2 08/12] arm64: cmpxchg: Include build_bug.h instead of bug.h for BUILD

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, 27 Feb 2018 17:34:26 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Will Deacon <will.deacon@....com>
Cc:     linux-kernel@...r.kernel.org, peterz@...radead.org,
        yamada.masahiro@...ionext.com, mingo@...nel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v2 08/12] arm64: cmpxchg: Include build_bug.h instead
 of bug.h for BUILD_BUG

On Tue, Feb 27, 2018 at 05:33:23PM +0000, Will Deacon wrote:
> On Mon, Feb 26, 2018 at 03:48:49PM +0000, Mark Rutland wrote:
> > On Mon, Feb 26, 2018 at 03:04:56PM +0000, Will Deacon wrote:
> > > Having asm/cmpxchg.h pull in linux/bug.h is problematic because this
> > > ends up pulling in the atomic bitops which themselves may be built on
> > > top of atomic.h and cmpxchg.h.
> > > 
> > > Instead, just include build_bug.h for the definition of BUILD_BUG.
> > 
> > We also use VM_BUG_ON(), defined in <linux/mmdebug.h>, which includes
> > <linux/bug.h>.
> > 
> > ... so I think we still have some fragility here, albeit no worse than before.
> > 
> > We also miss includes for:
> > 
> > * <linux/percpu-defs.h> (raw_cpu_ptr)
> > * <linux/preempt.h> (preempt_disable, preempt_enable)
> 
> Hmm, we can't include this one because it pulls in linux/bitops.h. I've
> moved the percpu cmpxchg stuff into asm/percpu.h, but that too is missing
> the linux/preempt.h #include, so I've added that as well.
> 
> Generally, I think if we want to clean up our #includes then that's better
> done as a separate series rather than as a piecemeal effort, which will
> likely fail to identify many of the underlying problems.

Sure thing; the above shouldn't hold up this series.

Mark.