On Sun, 27 Oct 2019 at 14:39, Greg KH <greg@xxxxxxxxx> wrote: > > On Sat, Oct 26, 2019 at 05:46:03PM +0200, Ard Biesheuvel wrote: > > On Sat, 26 Oct 2019 at 17:40, Sasha Levin <sashal@xxxxxxxxxx> wrote: > > > > > > On Sat, Oct 26, 2019 at 10:01:21AM +0200, Greg KH wrote: > > > >On Fri, Oct 25, 2019 at 05:39:44PM +0200, Ard Biesheuvel wrote: > > > >> On Fri, 25 Oct 2019 at 17:28, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > > >> > > > > >> > On Fri, 25 Oct 2019 at 17:25, Sasha Levin <sashal@xxxxxxxxxx> wrote: > > > >> > > > > > >> > > On Thu, Oct 24, 2019 at 04:37:12PM +0200, Ard Biesheuvel wrote: > > > >> > > >On Thu, 24 Oct 2019 at 16:34, Alexandru Elisei <alexandru.elisei@xxxxxxx> wrote: ... > > > >> > > >> > > > >> > > >> This breaks when building, because __hardenbp_enab is declared in the next patch: > > > >> > > >> > > > >> > > >> $ make -j32 defconfig && make -j32 > > > >> > > >> > > > >> > > >> [..] > > > >> > > >> arch/arm64/kernel/cpu_errata.c: In function ‘check_branch_predictor’: > > > >> > > >> arch/arm64/kernel/cpu_errata.c:492:3: error: ‘__hardenbp_enab’ undeclared (first > > > >> > > >> use in this function) > > > >> > > >> __hardenbp_enab = false; > > > >> > > >> ^~~~~~~~~~~~~~~ > > > >> > > >> arch/arm64/kernel/cpu_errata.c:492:3: note: each undeclared identifier is reported > > > >> > > >> only once for each function it appears in > > > >> > > >> make[1]: *** [scripts/Makefile.build:326: arch/arm64/kernel/cpu_errata.o] Error 1 > > > >> > > >> make[1]: *** Waiting for unfinished jobs.... > > > >> > > >> > > > >> > > > > > > >> > > >Indeed, but as discussed, this matches the state of both mainline and > > > >> > > >v4.19, which carry these patches in the same [wrong] order as well. > > > >> > > > > > > >> > > >Greg should confirm, but as I understand it, it is preferred to be > > > >> > > >bug-compatible with mainline rather than fixing problems when spotting > > > >> > > >them while doing the backport. > > > >> > > > > > >> > > Is it just patch ordering? If so I'd rather fix it, there's no reason to > > > >> > > carry this issue into the stable trees. > > > >> > > > > > >> > > We reserve "bug compatibility" for functional issues that are not yet > > > >> > > fixed upstream, it doesn't seem to be the case here. > > > >> > > > > > >> > > > > >> > The patches don't apply cleanly in the opposite order. > > > >> > > > >> What we could do is squash the two patches together. That way, we > > > >> avoid the breakage without having to modify the patches in order to be > > > >> able to apply them. > > > > > > > >No, don't do that. Just take all of the needed commits. > > > > > > Right, just make the patches apply in reverse, this shouldn't be more > > > than moving some code from the 2nd patch back to the 1st one, right? > > > > > > We usually don't do this in stable backports, but there are three good > > > reasons to do it here: > > > > > > 1. It'll be nice to maintain bisectability. > > > 2. The end result should be exactly the same, so there's no room for > > > error here. > > > 3. It's a backport for an older kernel to begin with, so there are > > > changes from upstream already. > > > > > > > I really don't see the point of doing this for v4.14 while v4.19 and > > mainline have the two patches in the opposite order. > > > > Would you like me to resend the entire 48 piece series for this? > > No need, I've queued the whole thing up now, thanks. > Thanks Greg
