linux-kernel - Re: [patch 2/4] Configure out file locking features

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: <20080731153757.GB20212@cs181140183.pp.htv.fi>
Date:	Thu, 31 Jul 2008 18:37:57 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:	linux-kernel@...r.kernel.org, linux-embedded@...r.kernel.org,
	michael@...e-electrons.com, Matt Mackall <mpm@...enic.com>,
	matthew@....cx, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [patch 2/4] Configure out file locking features

On Thu, Jul 31, 2008 at 04:20:07PM +0200, Thomas Petazzoni wrote:
> Le Thu, 31 Jul 2008 16:53:19 +0300,
> Adrian Bunk <bunk@...nel.org> a écrit :
> 
> > As I've already said in the past I'm personally not a huge fan of
> > these patches, but if it brings advantages in real-life situations
> > it's hard to argue against it.
> 
> Yes, I've seen your points about that kind of patches on
> linux-embedded, and I understand them. I agree that adding dozens and
> dozens of configuration items for small features doesn't look like
> something sustainable on the long run. However, the kernel keeps
> growing and this isn't sustainable either on the long run for *some*
> embedded users. So, what should we do ? (That's a real question)

I'm not against making the kernel smaller.

I'm just not a fan of adding config options for each few kB of code - 
we have to maintain them and the more complex the configuration becomes 
the more often it breaks.

> Some numbers about a bootable x86 allnoconfig kernel with ELF, ext2 and
> IDE support :
> 
>    text	   data	    bss	    dec	    hex	filename
> 1110389	 119468	 217088	1446945	 161421	vmlinux.2.6.26
> 1134606	 118840	 212992	1466438	 166046	vmlinux.2.6.27-rc1
>   24217    -628   -4096   19493    4C25 +/-

What became bigger was most likely not related to the patches you sent.

Where and why did the kernel become bigger?

> (The only configuration change between the two kernels is
> CONFIG_FW_LOADER n->y, which pulls drivers/base/firmware_class.o, 3k).

Why did CONFIG_FW_LOADER get enabled?
Due to alnoconfig disabling CONFIG_EMBEDDED?

> > In which use cases can users safely disable this option, and on what 
> > devices have you verified that CONFIG_FILE_LOCKING=n kernels actually 
> > work in practice?
> 
> As long as they don't use NFS (realistic in many production
> environments) and that the applications do not rely on advisory locking
> (flock() and fnctl() F_GETLK and F_SETLK), file locking can be
> disabled.

But what does that mean in practice?

A user will ask:
I'm using $applications with $libraries, can I safely disable this option?

And e.g. according to a quick grep through the sources uClibc's 
updwtmp() seems to cease working without flock().

It costs us maintainance of the option and the #ifdef's and gives users 
one way more to shoot themselves into the foot in nontrivial to detect 
ways.

> In practice, I only tested a CONFIG_FILE_LOCKING=n kernel
> with a basic Busybox under Qemu.
> 
> Sincerly,
> 
> Thomas

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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