Re: devpts mounts too slowly

Re: devpts mounts too slowly

[H. Peter Anvin]

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.

	-hpa

Re: devpts mounts too slowly

[Al Viro]

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().

Re: devpts mounts too slowly

[Andrew Morton]

On Wed, 24 Jun 2009 21:01:08 +0100
Al Viro <viro@ZenIV.linux.org.uk> wrote:

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

CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set

>  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().

Re: devpts mounts too slowly

[H. Peter Anvin]

Andrew Morton wrote:
>>>
>>> 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.
> 
> CONFIG_SECURITY_SELINUX=y
> CONFIG_SECURITY_SELINUX_BOOTPARAM=y
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
> CONFIG_SECURITY_SELINUX_DISABLE=y
> CONFIG_SECURITY_SELINUX_DEVELOP=y
> CONFIG_SECURITY_SELINUX_AVC_STATS=y
> CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
> # CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set
> # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
> 

Wow.  It doesn't even check for selinux actually being enabled before
embarking on this stupidity.

FAIL.

	-hpa