On Fri, Jun 05, 2009 at 08:49:56AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 5 Jun 2009, Alexey Dobriyan wrote:
> >
> > This mapping issue is what created VM_EXECUTABLE/MAP_EXECUTABLE in
> > the first place, I assume? Never mind it's cheap hack.
> >
> > > and goes along with task->mm, and should be there, not in task_struct.
> >
> > Because ->mm can be borrowed to unrelated task and user has to check
> > for it.
>
> Not it can't.
>
> You're confusing ->mm with ->active_mm.
>
> The latter can be borrowed. The former can not.
Not permanently, but it can:
static void aio_kick_handler(struct work_struct *work)
{
struct kioctx *ctx = container_of(work, struct kioctx, wq.work);
mm_segment_t oldfs = get_fs();
struct mm_struct *mm;
int requeue;
set_fs(USER_DS);
use_mm(ctx->mm);
spin_lock_irq(&ctx->ctx_lock);
requeue =__aio_run_iocbs(ctx);
mm = ctx->mm;
spin_unlock_irq(&ctx->ctx_lock);
unuse_mm(mm);
set_fs(oldfs);
/*
* we're in a worker thread already, don't use
* queue_delayed_work,
*/
if (requeue)
queue_delayed_work(aio_wq, &ctx->wq, 0);
}
It's borrowed by kernel thread of course, not userspace task.
> The fact is, the executable is _inherently_ tied to the mm. It's what it
> is mapped into. It makes no sense to tie it to anything else. It's simply
> fundamentally not a "per-thread" thing.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
