From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Sonny Rao <sonny@burdell.org>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
anton@samba.org
Subject: Re: Possible bug in do_execve()
Date: Wed, 21 Jun 2006 14:42:50 -0500 [thread overview]
Message-ID: <20060621194250.GD16576@sergelap.austin.ibm.com> (raw)
In-Reply-To: <20060621192726.GA10052@kevlar.burdell.org>
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-06-21 19:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 2:25 Sonny Rao
2006-06-21 18:41 ` Serge E. Hallyn
2006-06-21 18:55 ` Sonny Rao
2006-06-21 19:09 ` Serge E. Hallyn
2006-06-21 19:27 ` Sonny Rao
2006-06-21 19:42 ` Serge E. Hallyn [this message]
2006-06-21 20:12 ` Sonny Rao
2006-06-22 11:59 ` Serge E. Hallyn
2006-06-22 20:03 ` Sonny Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060621194250.GD16576@sergelap.austin.ibm.com \
--to=serue@us.ibm.com \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=sonny@burdell.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox