On Tuesday, August 29, 2017, Nicolas Pitre wrote: > On Tue, 29 Aug 2017, Chris Brandt wrote: > > > On Monday, August 28, 2017, Nicolas Pitre wrote: > > > OK I moved the lock promotion right at the beginning _before_ > validating > > > the split point. Also got a reference on the file to make sure that > > > hasn't changed too. > > > > > > > While we are at it, what happens if you mmap 120Kb, then munmap() > the > > > middle > > > > 40Kb. Leaving two 40Kb VMAs with 40Kb gap between them, that is. > Will > > > your > > > > ->vm_private_data be correct for both? > > > > > > It wouldn't, but I now changed it to contain absolute values so now it > > > will. And if the split point lands in the hole then the code just > > > readjusts the pgoff at the beginning of the remaining part. > > > > > > Here's the revised patch: > > > > > > For whatever it's worth, as soon as I moved to 4.13-rc7, > > CONFIG_CRAMFS_PHYSMEM=y crashes my XIP_KERNEL system before it can even > > get to any console output. > > > > (both the old patch and the new patch) > > > > If CONFIG_CRAMFS_PHYSMEM is not set, my XIP system boots fine. > > > > However, if I boot -rc7 as a uImage, the new patch works just as good as > > the old patch. > > When not a uImage, do you mean by that a XIP kernel? Yes, CONFIG_XIP_KERNEL. > If so you should > know by now from that other thread on LAK that the XIP linker script is > broken and probably just worked by luck till now. Still, if you could > bisect between -rc4 and -rc7 and pinpoint the change that makes it not > work that would be better than speculations. Note that everything else seem OK when CONFIG_XIP_KERNEL=y. It's just when CONFIG_XIP_KERNEL=y CONFIG_CRAMFS_PHYSMEM=y which is odd. So hopefully that means it will be easy to track down. Chris
