On 17:49 Thu 24 Apr , Bernd Petrovitsch wrote: > On Don, 2008-04-24 at 17:08 +0200, Michael Blizek wrote: > > It is not just cleaning the stack up. You have to make sure that no other > > thread in the userspace accesses it. This means you have to unmap it first. > > Uuugh, that looks like a quite weird software design if one thread > (which has his own stack) actually accesses data on the stack of another > thread. > Is there a compelling reason not to do that in a (more) sane way? This is a security risk. Somebody who does not have root permissions might do this deliberately in order to inject code into the kernel - and gain full access to the system. > > Even > > if it is not, you risk breaking some weird user-space programs which abuse > > unused stack space (e.g. functions returning pointers to local variables...). > > That code is broken anyways as it violates the C standard (and gcc warns > nowadays BTW). So IMHO no need to care about it. You are right. But some projects generate hundreds of warning when you compile them. This patch means breaking them all at once when you are doing the next kernel upgrade... -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.homelinux.net -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
