On Thu, Feb 28, 2019 at 12:06 AM Vlastimil Babka <vbabka@xxxxxxx> wrote: > > On 2/27/19 10:32 PM, Oscar Salvador wrote: > > On Tue, Feb 26, 2019 at 02:04:28PM -0800, Andrew Morton wrote: > >> How is this going to affect existing userspace which is aware of the > >> current behaviour? > > > > Well, current behavior is not really predictable. > > Our customer was "surprised" that the call to mremap() failed, but the regions > > got unmapped nevertheless. > > They found it the hard way when they got a segfault when trying to write to those > > regions when cleaning up. > > > > As I said in the changelog, the possibility for false positives exists, due to > > the fact that we might get rid of several vma's when unmapping, but I do not > > expect existing userspace applications to start failing. > > Should be that the case, we can revert the patch, it is not that it adds a lot > > of churn. > > Hopefully the only program that would start failing would be a LTP test > testing the current behavior near the limit (if such test exists). And > that can be adjusted. > IMO the original behavior is itself probably not a big issue because if userspace wanted to mremap over something, it was prepared to lose the "over something" mapping anyway. So it does seem to be a stretch to call the behavior a "bug". Still I agree with the patch that mremap should not leave any side effects after returning error. thanks, - Joel
