Re: Possible bug in do_execve()

["Serge E. Hallyn" <serue@us.ibm.com>]

Quoting Sonny Rao (sonny@burdell.org):
> On Wed, Jun 21, 2006 at 02:09:10PM -0500, Serge E. Hallyn wrote:
> <snip>
> > > Yeah, I proposed a similar patch to Anton, and it would quiet the
> > > warning on powerpc, but that's not the point.  It happens that powerpc
> > > doesn't use 0 as a context id, but that may not be true on another
> > > architecture.  That's really what I'm concerned about.
> > 
> > FWIW, ppc and cris do the NO_CONTEXT check, while others don't
> > even have a arch-specific 'mm->context.id'.
> 
> Good point.  I probably stated that concern too narrowly.  Probably
> what I should say is: What is the pre-condition for calling
> destroy_context() ?  Is it that init_new_context() must have
> succeeded?  Or is it merely that mm.context has been zeroed
> out?

Right, that may be the right question.  If that's the case, then the
problem is really include/linux/sched.h:__mmdrop() which is what's
calling destroy_context().  Separating that out becomes a pretty
big patch affecting at least all mmput() and mmdrop() callers.

> Here's destroy context on sparc64:
> 
> void destroy_context(struct mm_struct *mm)
> {
>         unsigned long flags, i;
> 
>         for (i = 0; i < MM_NUM_TSBS; i++)
>                 tsb_destroy_one(&mm->context.tsb_block[i]);
> 
>         spin_lock_irqsave(&ctx_alloc_lock, flags);
> 
>         if (CTX_VALID(mm->context)) {
>                 unsigned long nr = CTX_NRBITS(mm->context);
>                 mmu_context_bmap[nr>>6] &= ~(1UL << (nr & 63));
>         }
> 
>         spin_unlock_irqrestore(&ctx_alloc_lock, flags);
> }
> 
> It seems to assume that mm->context is valid before doing a check.
> 
> Since I don't have a sparc64 box, I can't check to see if this
> actually breaks things or not.

So we can either go through all arch's and make sure destroy_context is
safe for invalid context, or split mmput() and destroy_context()...

The former seems easier, but the latter seems more robust in the face of
future code changes I guess.

-serge
-
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/