linux-kernel - Re: [PATCH] nfs client: kill compile warning on NOMMU machine

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]

Message-ID: <386072610902050824j6eeb8e9asde2c41ac5cf9815a@mail.gmail.com>
Date:	Fri, 6 Feb 2009 00:24:37 +0800
From:	Bryan Wu <cooloney@...nel.org>
To:	Trond Myklebust <Trond.Myklebust@...app.com>
Cc:	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nfs client: kill compile warning on NOMMU machine

On Thu, Feb 5, 2009 at 11:37 PM, Trond Myklebust
<Trond.Myklebust@...app.com> wrote:
> On Thu, 2009-02-05 at 08:28 -0500, Trond Myklebust wrote:
>> On Thu, 2009-02-05 at 17:02 +0800, Bryan Wu wrote:
>> > Hi guys,
>> >
>> > Is it possible to merge this patch?
>>
>> NACK. Although it would be nice to get rid of the warning, this patch
>> does so at the price of even further obfuscating the fact that we're
>> just returning -ENOSYS in the no MMU case, and by causing
>> nfs_file_vm_ops (which is currently optimised away) to be compiled in
>> for no good reason at all.
>>
>> Trond
>
> How about the following compromise: we get rid of the special casing
> altogether and just always call generic_file_mmap. If the noMMU folks
> want further optimisations, then they can inline generic_file_mmap(), so
> that the compiler always takes the 'generic_file_mmap() failed' path.
>

Beautiful, I do love this one and would like to test it on our platform.

Thanks
-Bryan

> Cheers
>  Trond
> ------------------------------------------------------------
> From: Trond Myklebust <Trond.Myklebust@...app.com>
> Date: Thu, 5 Feb 2009 10:23:36 -0500
> NFS: Kill the "defined but not used" compile error on nommu machines
>
> Bryan Wu reports that when compiling NFS on nommu machines he gets a
> "defined but not used" error on nfs_file_mmap().
>
> The easiest fix is simply to get rid of the special casing in NFS, and
> just always call generic_file_mmap() to set up the file.
>
> Signed-off-by: Trond Myklebust <Trond.Myklebust@...app.com>
> ---
>
>  fs/nfs/file.c |   12 +++++-------
>  1 files changed, 5 insertions(+), 7 deletions(-)
>
>
> diff --git a/fs/nfs/file.c b/fs/nfs/file.c
> index 404c19c..1eab9c9 100644
> --- a/fs/nfs/file.c
> +++ b/fs/nfs/file.c
> @@ -64,11 +64,7 @@ const struct file_operations nfs_file_operations = {
>        .write          = do_sync_write,
>        .aio_read       = nfs_file_read,
>        .aio_write      = nfs_file_write,
> -#ifdef CONFIG_MMU
>        .mmap           = nfs_file_mmap,
> -#else
> -       .mmap           = generic_file_mmap,
> -#endif
>        .open           = nfs_file_open,
>        .flush          = nfs_file_flush,
>        .release        = nfs_file_release,
> @@ -304,11 +300,13 @@ nfs_file_mmap(struct file * file, struct vm_area_struct * vma)
>        dprintk("NFS: mmap(%s/%s)\n",
>                dentry->d_parent->d_name.name, dentry->d_name.name);
>
> -       status = nfs_revalidate_mapping(inode, file->f_mapping);
> +       /* Note: generic_file_mmap() returns ENOSYS on nommu systems
> +        *       so we call that before revalidating the mapping
> +        */
> +       status = generic_file_mmap(file, vma);
>        if (!status) {
>                vma->vm_ops = &nfs_file_vm_ops;
> -               vma->vm_flags |= VM_CAN_NONLINEAR;
> -               file_accessed(file);
> +               status = nfs_revalidate_mapping(inode, file->f_mapping);
>        }
>        return status;
>  }
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@...app.com
> www.netapp.com
>
--
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/