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.
