[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Follow-Ups:
References: