linux-kernel - Re: [PATCH 3/4] kthreads: rework kthread

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]

Message-ID: <m1ocxivlch.fsf@fess.ebiederm.org>
Date:	Tue, 03 Feb 2009 21:10:06 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	paulmck@...ux.vnet.ibm.com
Cc:	Rusty Russell <rusty@...tcorp.com.au>, paulmck@...ux.vnet.ibm.com,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@....de>, Ingo Molnar <mingo@...e.hu>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Vitaliy Gusev <vgusev@...nvz.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] kthreads: rework kthread_stop()

"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> writes:

> ACCESS_ONCE() suffices in many cases, but if the pointer being accessed
> points to a structure that might recently have been initialized, then
> rcu_dereference() will be required on Alpha.  Though perhaps the
> discussion below removes the need entirely, but cannot say that I fully
> understand this part of the kernel.

Thanks.  I had overlooked the addition of ACCESS_ONCE() into our set of
tricks.  I thought Oleg was referring to a hypothetical construct.

Currently Oleg's implementation is fine because of an explicit
memory barrier and two dereferences of the pointer.  It just isn't
especially clear.

ACCESS_ONCE would help.

Hmm.

I wonder if it would be better/clearer to define to_kthread as:

static struct kthread *to_kthread(struct task_struct *tsk)
{
	void *stack = task_stack_page(tsk);
	return (struct kthread *)(stack + kthread_offset);

}

And to measure kthread_offset the first time kthread() was
called.  I would love to have a fixed compile time offset but
I don't know how to measure it at compile time reliably.

Oleg what do you think.  It would remove the test and be simple and
obviously correct.

Eric

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