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.