MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>, Ingo Molnar <mingo@elte.hu>,
       Linus Torvalds <torvalds@linux-foundation.org>,
       linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] wait_task_inactive: don't use the dummy version when !SMP && PREEMPT
In-Reply-To: Oleg Nesterov's message of  Wednesday, 30 July 2008 21:09:49 +0400 <20080730170949.GA18682@tv-sign.ru>
References: <20080730170949.GA18682@tv-sign.ru>
Message-Id: <20080731022253.BDD83154290@magilla.localdomain>
Date: Wed, 30 Jul 2008 19:22:53 -0700 (PDT)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1659
Lines: 37

I'm not convinced we need this at all (as per prior thread
"Q: wait_task_inactive() and !CONFIG_SMP && CONFIG_PREEMPT").

Let's not get hung up on what the explanation of the function's semantics
supposedly is.  We can change the comments to match the reality.  We can
rename the function to better reflect its true guarantee, if you like.

There are two uses of wait_task_inactive.  One is kthread_bind.
We have established that a nop is fine for !SMP there.

The other uses are for tracing.  Presently that is the traditional use in
ptrace, and task_current_syscall.

I've described that the requirement of the traditional ptrace call is quite
weak.  A nop is fine for !SMP.  Preemption is not an issue because all that
matters is that no access to pt_regs/thread_struct can race with the actual
context switch (by definition has to be on another CPU to be simultaneous).

For task_current_syscall, it also doesn't matter that it's left the run
queue.  It just matters that the call before looking at pt_regs and the
call after indicate whether it stayed switched out for the duration.  As
per the prior thread on this, I think that's covered by using nivcsw+nvcsw
as I did originally rather than nvcsw alone.  So a short inline is still
fine.

The other uses I anticipate (e.g. utrace) follow the same model as
task_current_syscall (check before and after) and have only the same
requirements.


Thanks,
Roland
--
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/