On 09/09/14 at 03:41pm, Vivek Goyal wrote: > On Sat, Sep 06, 2014 at 06:16:57AM +0800, Baoquan He wrote: > > [CC hpa ] > > > Hi Kees, > > > > Yes, process_e820_entry() can make sure the choice+output_len < > > CONFIG_RANDOMIZE_BASE_MAX_OFFSET, but that can't stop other bootloaders > > to put kernel in region above CONFIG_RANDOMIZE_BASE_MAX_OFFSET. > > > > E.g in kdump, we can set crashkernel=256M@1024M in cmdline. Then the 1st > > kernel will reserve 256M memory just at 1024M place. So if load kdump > > kernel now, the output will be 1024M before choose_kernel_location(). > > With this value, output won't be changed in choose_kernel_location(), > > then it will do decompress(), then call handle_relocations(). Then since > > 1024 is not equal to LOAD_PHYSICAL_ADDR, it will start relocatoins > > handling. And this cause _text stamping into MODULES vaddr range. System > > will be exceptional. > > Bao, > > If you apply your first patch where output_orig == output, then > handle_relocations() will not do anything for x86_64 case and bail > out. That should take care of this issue. Isn't it? And we should > not require this patch.
Yes, exactly. > > Thanks > Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
