linux-kernel - Re: devpts mounts too slowly

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090624200108.GR8633@ZenIV.linux.org.uk>
Date:	Wed, 24 Jun 2009 21:01:08 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ray Lee <ray-lk@...rabbit.org>, renton@...ton.name,
	linux-kernel@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: devpts mounts too slowly

On Wed, Jun 10, 2009 at 01:51:25PM -0700, H. Peter Anvin wrote:
> Andrew Morton wrote:
> > 
> > hm, OK.
> > 
> > I've now mounted 15000 devpts's and still no slowdown is evident.
> 
> I ran my test script, mounting ramfs, with n=100000, and well, gave up
> since it hadn't gotten any further than 57000 or so overnight.  At that
> time each individual mount was taking several seconds.
> 
> Graphing the delays seem to indicate O(n^2) behavior.
> 
> umounts do not appear affected; each umount still take negible time.

I think I know what's going on.  /sbin/mount is linked against libselinux
/sbin/umount is not.  And FPOS in question blows if you
	* do not have selinuxfs mounted (e.g. because selinux is not enabled)
	* have a lot of mounts.

What happens is that this piece of crap checks for presence of selinuxfs
on /selinux; then, if the thing isn't there, we go and scan the entire
/proc/mounts in search of selinuxfs mounts.

If akpm has selinux enabled on his testbox and you don't have it on yours,
we have all observations explained.  I'd expect similar slowdown from
ls on an empty directory, BTW - /bin/ls is linked against the same thing,
so it gets hit as well.  Before it even gets to main().
--
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/