On Mon, Jan 08, 2018 at 10:10:44AM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 08, 2018 at 09:47:23AM +0100, Michal Hocko wrote: > > On Mon 08-01-18 08:53:08, Greg KH wrote: > > > On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote: > > > > On Sun 07-01-18 13:44:02, Mike Galbraith wrote: > > > > > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote: > > > > > > On Sun 07-01-18 10:11:15, Greg KH wrote: > > > > > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote: > > > > > > > > On Fri, 2017-12-22 at 09:45 +0100, Greg Kroah-Hartman wrote: > > > > > > > > > 4.14-stable review patch. If anyone has any objections, please let me know. > > > > > > > > > > > > > > > > FYI, this broke kdump, or rather the makedumpfile part thereof. > > > > > > > > Forward looking wreckage is par for the kdump course, but... > > > > > > > > > > > > > > Is it also broken in Linus's tree with this patch? Or is there an > > > > > > > add-on patch that I should apply to 4.14 to resolve this issue there? > > > > > > > > > > > > This one http://lkml.kernel.org/r/1513932498-20350-1-git-send-email-bhe@xxxxxxxxxx > > > > > > I guess. > > > > > > > > > > That won't unbreak kdump, else master wouldn't be broken. I don't care > > > > > deeply, or know if anyone else does, I'm just reporting it because I > > > > > met it and chased it down. > > > > > > > > OK, I didn't notice that d8cfbbfa0f7 ("mm/sparse.c: wrong allocation > > > > for mem_section") made it in after rc6. I am still wondering why > > > > 83e3c48729 ("mm/sparsemem: Allocate mem_section at runtime for > > > > CONFIG_SPARSEMEM_EXTREME=y") made it into the stable tree in the first > > > > place. > > > > > > It was part of the prep for the KTPI code from what I can tell. > > > > I do not see a direct relation, to be honest. It is more related to > > 5-level page tables but I might be missing some subtle relation. > > > > > If you > > > think it should be reverted, just let me know and I'll be glad to do so. > > > > This seems to be affecting Linus tree as well so it needs to get > > resolved. I would suggest reverting in stable for the mean time. > > If you really need it in the stable tree then you can pull it back later > > with all the follow up fixes. > > Ok, I've now reverted it, thanks. Nope, it breaks the build when reverted, I'm dropping that revert now. It's as if the x86 maintainers actually knew what they were doing in asking for this to be backported :) thanks, greg k-h