linux-kernel - Re: [PATCH 3/3] wait_task_inactive: don't use the dummy version when !SMP && PREEMPT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Jul 2008 19:22:53 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] wait_task_inactive: don't use the dummy version when !SMP && PREEMPT

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/