Messages in this thread | | | Date | Sat, 8 Jan 2005 16:28:41 -0200 | From | Marcelo Tosatti <> | Subject | Re: uselib() & 2.6.X? |
| |
On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote: > > > On Fri, 7 Jan 2005, Marcelo Tosatti wrote: > > > > Only problem is that current do_brk() callers dont take the lock - you would > > need a version of do_brk() that doesnt warn for them? > > No, I'd just fix them up.
What do you mean by "fix them up" ? With your minimal fix the other do_brk() callers do not have the lock, you dont mean "fix" by grabbing the lock?
> They mostly don't _need_ the lock (at least not the binary loader ones), > since at executable loading time you're guaranteed to be the only user > anyway,
OK - the old mappings have been unmapped at this point, correct? There are no mappings at all?
I think you also need to fix some cases in arch/sparc{64},arch/mips? as Alan said.
> but hey, we get the lock for do_mmap() there for the same reason: > to just keep things consistent (and I think we used to have a warning in > do_mmap() a long time ago when we were chasing down some other bug, so > doign the same thing for do_brk() is just very consistent).
I think the rule "always have mmap_sem locked when calling do_brk()" is simpler and easier to understand, but hey, you prefer the minimal fix.
I was also not sure if it was safe to NOT have the lock except for execve() as you mention.
> Another issue is likely that we should make the whole "uselib()" > interfaces configurable. I don't think modern binaries use it (where > "modern" probably means "compiled within the last 8 years" ;).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |