linux-kernel - Re: [PATCH 1/1] shmem.c: Compilation failure in shmem_file_setup for !CONFIG

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:	Mon, 20 Feb 2012 11:29:43 -0800 (PST)
From:	Hugh Dickins <hughd@...gle.com>
To:	Kautuk Consul <consul.kautuk@...il.com>
cc:	Eric Anholt <eric@...olt.net>, Keith Packard <keithp@...thp.com>,
	Chris Wilson <chris@...is-wilson.co.uk>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] shmem.c: Compilation failure in shmem_file_setup
 for !CONFIG_MMU

On Mon, 20 Feb 2012, Kautuk Consul wrote:
> I disabled the CONFIG_MMU and tried to compile the kernel and got the
> following problem:
> In function ‘shmem_file_setup’:
> error: implicit declaration of function ‘ramfs_nommu_expand_for_mapping’
> 
> This is because, we do not include ramfs.h for CONFIG_SHMEM.
> 
> Included linux/ramfs.h for both CONFIG_SHMEM as well as !CONFIG_SHMEM.
> 
> Signed-off-by: Kautuk Consul <consul.kautuk@...il.com>

Thanks for looking into this, but I think that's the wrong fix.

We don't expect CONFIG_SHMEM=y without CONFIG_MMU=y, and init/Kconfig
does say config SHMEM depends on MMU.  I don't think anyone has ever
thought about the implications of CONFIG_SHMEM without CONFIG_MMU,
it just hasn't been needed.

If CONFIG_SHMEM is not set, then you should already have linux/ramfs.h
included.  So I expect it's one of those weakness-in-select issues:
something doing select SHMEM without a depends on MMU.

config DRM_I915?  i915 is happier to be served by SHMEM with its
use of swap, but by that logic i915 would want to select SWAP too.
It should be fine with ramfs: not as full an implementation, but
that's the tradeoff people choose when they ask for SHMEM off.
Is DRM_I915 any good without MMU??

When GEM went in, I remember we particularly asked for it not
to select SHMEM, but to work in the tiny !SHMEM ramfs case too.
Then I think some bug came up that made them add a select SHMEM
in a hurry.  Ah yes, bugzilla.kernel.org 14662.  Well, the
select TMPFS that was added afterwards was valid, but the
select SHMEM is not.

Things have changed again since then, since we switched i915 over
to shmem_read_mapping_page_gfp() and shmem_truncate_range(): I
believe nowadays it needs neither select SHMEM nor select TMPFS,
and I'd be very happy to see a tested patch from the i915 people
removing both those selects; but I'm unable to test it adequately
myself, so never pushed that change.

Hugh

> ---
>  mm/shmem.c |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 269d049..4884188 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -30,6 +30,7 @@
>  #include <linux/mm.h>
>  #include <linux/export.h>
>  #include <linux/swap.h>
> +#include <linux/ramfs.h>
>  
>  static struct vfsmount *shm_mnt;
>  
> @@ -2442,8 +2443,6 @@ out4:
>   * effectively equivalent, but much lighter weight.
>   */
>  
> -#include <linux/ramfs.h>
> -
>  static struct file_system_type shmem_fs_type = {
>  	.name		= "tmpfs",
>  	.mount		= ramfs_mount,
> -- 
> 1.7.5.4