Subject: Re: How to lock current->signal->tty
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@redhat.com>, Al Viro <viro@ftp.linux.org.uk>,
       James Morris <jmorris@namei.org>, linux-kernel@vger.kernel.org,
       davem@redhat.com, jack@suse.cz, dwmw2@infradead.org,
       tony.luck@intel.com, jdike@karaya.com,
       James.Bottomley@HansenPartnership.com
In-Reply-To: <1155057114.1123.97.camel@moss-spartans.epoch.ncsc.mil>
References: <1155050242.5729.88.camel@localhost.localdomain>
	 <1155057114.1123.97.camel@moss-spartans.epoch.ncsc.mil>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Aug 2006 18:43:14 +0100
Message-Id: <1155058994.5729.99.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 971
Lines: 25

Ar Maw, 2006-08-08 am 13:11 -0400, ysgrifennodd Stephen Smalley:
> Does this look sane?  Or do we need a common helper factored from
> disassociate_ctty()?  Why is the locking different for TIOCNOTTY in the
> non-leader case?

The non-leader case for TIOCNOTTY in the base kernel is different
because it is wrong and I've fixed that one.

If you can factor disassociate_ctty out to do what you need I'd prefer
that path so the tty locking actually ends up in the tty layer.

> +	mutex_lock(&tty_mutex);
> +	tty = current->signal->tty;
>  	if (tty) {
>  		file_list_lock();

Looks sane and the lock ordering matches vhangup() which may actually
also do what you want - I'm not 100% sure I follow what SELinux tries to
do here.

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