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] [day] [month] [year] [list]
Date:	Thu, 4 Jul 2013 05:43:39 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Waiman Long <Waiman.Long@...com>
Cc:	Jeff Layton <jlayton@...hat.com>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...isplace.org>,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Chandramouleeswaran, Aswin" <aswin@...com>,
	"Norton, Scott J" <scott.norton@...com>
Subject: Re: [PATCH v3 25/25] selinux: Change how dentry's d_lock field is
 accessed

On Wed, Jul 03, 2013 at 04:22:17PM -0400, Waiman Long wrote:
> diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
> index ff42773..c83a201 100644
> --- a/security/selinux/selinuxfs.c
> +++ b/security/selinux/selinuxfs.c
> @@ -1187,28 +1187,28 @@ static void sel_remove_entries(struct dentry *de)
>  {
>  	struct list_head *node;
>  
> -	spin_lock(&de->d_lock);
> +	d_lock(de);
>  	node = de->d_subdirs.next;
>  	while (node != &de->d_subdirs) {
>  		struct dentry *d = list_entry(node, struct dentry, d_u.d_child);
>  
> -		spin_lock_nested(&d->d_lock, DENTRY_D_LOCK_NESTED);
> +		d_lock_nested(d, DENTRY_D_LOCK_NESTED);
>  		list_del_init(node);
>  
>  		if (d->d_inode) {
>  			dget_dlock(d);
> -			spin_unlock(&de->d_lock);
> -			spin_unlock(&d->d_lock);
> +			d_unlock(de);
> +			d_unlock(d);
>  			d_delete(d);
>  			simple_unlink(de->d_inode, d);
>  			dput(d);
> -			spin_lock(&de->d_lock);
> +			d_lock(de);
>  		} else
> -			spin_unlock(&d->d_lock);
> +			d_unlock(d);
>  		node = de->d_subdirs.next;
>  	}
>  
> -	spin_unlock(&de->d_lock);
> +	d_unlock(de);

BTW, all that bunch (this and similar simple_unlink() callers) is seriously
asking for a common helper somewhere in libfs.c; I'd started experimenting
in that direction several times, but got sidetracked.  The real question
here is what do we do with the stuff mounted on those.

Linus, do you have any suggestions re semantics of mounts on such mountpoints?
I see two variants - disslove all mounts on those when the kernel decides to
kill such a volatile mountpoint (the same goes for e.g. /proc/42/fd getting
invalidated, etc.) or ban mounting on them in the first place (i.e. set
DCACHE_CANT_MOUNT when these dentries are created)...  Preferences, alternative
suggestions?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ