On Sun, Nov 01, 2020 at 05:38:35PM +0000, Matthew Wilcox wrote: > On Sun, Nov 01, 2020 at 12:31:05PM -0500, Arvind Sankar wrote: > > Commit > > b9de06783f01 ("compiler.h: fix barrier_data() on clang") > > moved the definition of barrier() into compiler.h. > > That's not a real commit ID. It only exists in linux-next and > will expire after a few weeks. > > The right way to fix a patch in Andrew's tree is to send an email > asking him to apply it as a -fix patch. As part of Andrew's submission > process, he folds all the -fix patches into the parent patch and it > shows up pristine in Linus' tree. Ok. So I still send it as a separate patch and he does the folding, or should I send a revised patch that replaces the original one? > > > This causes build failures at least on alpha, because there are files > > that rely on barrier() being defined via the implicit include of > > compiler_types.h. > > That seems like a bug that should be fixed rather than reverting this > part of the patch? > I thought about that, but barrier() is used in a large number of places, so reverting seemed like the safer approach, in case more errors like this cropped up. I don't know if it's a bug, as it was defined in compiler_types.h before my original patch, I'm not sure if there's a reason only compiler_types.h rather than compiler.h is implicitly included via the Makefile. Cc'ing Masahiro Yamada in case he has comments on that part. Thanks.