On Wed, 2017-07-05 at 10:15 -0700, Linus Torvalds wrote: > > On Wed, Jul 5, 2017 at 9:58 AM, Ben Hutchings <b...@decadent.org.uk> wrote: > > > > I ended up with the following two patches, which seem to deal with > > both the Java and Rust regressions. These don't touch the > > stack-grows-up paths at all because Rust doesn't run on those > > architectures and the Java weirdness is i386-specific. > > > > They definitely need longer commit messages and comments, but aside > > from that do these look reasonable? > > I thin kthey both look reasonable, but I think we might still want to > massage things a bit (cutting down the quoting to a minimum, hopefully > leaving enough context to still make sense): > > > Subject: [1/2] mmap: Skip a single VM_NONE mapping when checking the stack > > gap > > > > prev = vma->vm_prev; > > + if (prev && !(prev->vm_flags & (VM_READ | VM_WRITE | VM_EXEC))) > > + prev = prev->vm_prev; > > if (prev && prev->vm_end > gap_addr) { > > Do we just want to ignore the user-supplied guard mapping, or do we > want to say "if the user does a guard mapping, we use that *instead* > of our stack gap"? > > IOW, instead of "prev = prev->vm_prev;" and continuing, maybe we want > to just return "ok".
Rust effectively added a second guard page to the main thread stack. But it does not (yet) implement stack probing (https://github.com/rust-lang/rust/issues/16012) so I think it will benefit from the kernel's larger stack guard gap. > > Subject: [2/2] mmap: Avoid mapping anywhere within the full stack extent > > if finite > > This is good thinking, but no, I don't think the "if finite" is right. > > I've seen people use "really big values" as replacement for > RLIM_INIFITY, for various reasons. > > We've had huge confusion about RLIM_INFINITY over the years - look for > things like COMPAT_RLIM_OLD_INFINITY to see the kinds of confusions > we've had. That sounds familiar... > Some people just use MAX_LONG etc, which is *not* the same as > RLIM_INFINITY, but in practice ends up doing the same thing. Yadda > yadda. > > So I'm personally leery of checking and depending on "exactly > RLIM_INIFITY", because I've seen it go wrong so many times. > > And I think your second patch breaks that "use a really large value to > approximate infinity" case that definitely has existed as a pattern. Right. Well that seems to leave us with remembering the MAP_FIXED flag and using that as the condition to ignore the previous mapping. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin
signature.asc
Description: This is a digitally signed message part