[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44C83480.6000102@vandrovec.name>
Date: Thu, 27 Jul 2006 05:35:28 +0200
From: Petr Vandrovec <petr@...drovec.name>
To: Arnd Bergmann <arnd.bergmann@...ibm.com>
CC: Heiko Carstens <heiko.carstens@...ibm.com>,
linux-kernel@...r.kernel.org,
Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH] ncpfs: move ioctl32 code to fs/ncpfs/ioctl.c
[removed linware@...cvut.cz - I believe it is dead...]
Arnd Bergmann wrote:
> The ncp specific compat ioctls are clearly local to one
> file system, so the code can better live there.
>
> This version of the patch moves everything into the
> generic ioctl handler and uses it for both 32 and 64
> bit calls.
>
> Petr, can you test this patch on a 64 bit system?
Yes, tomorrow (on amd64).
> @@ -544,6 +691,9 @@
> kfree(oldname);
> return 0;
> }
> +#ifdef CONFIG_COMPAT
> + case NCP_IOC_GETPRIVATEDATA_32:
> +#endif
> case NCP_IOC_GETPRIVATEDATA:
> if (current->uid != server->m.mounted_uid) {
> return -EACCES;
...
> @@ -562,10 +722,23 @@
> server->priv.data,
> outl)) return -EFAULT;
> }
> - if (copy_to_user(argp, &user, sizeof(user)))
> - return -EFAULT;
> + if (cmd == NCP_IOC_GETPRIVATEDATA) {
> + if (copy_to_user(argp, &user, sizeof(user)))
> + return -EFAULT;
> + } else {
> +#ifdef CONFIG_COMPAT
> + struct compat_ncp_privatedata_ioctl user32;
> + user32.len = user.len;
> + user32.data = (unsigned long) user.data;
> + if (copy_to_user(&user32, argp, sizeof(user32)))
> + return -EFAULT;
> +#endif
> + }
> return 0;
> }
Although I understand that this code is correct, what about removing this second
#ifdef ? gcc should realize it anyway that without CONFIG_COMPAT defined cmd
must be equal to NCP_IOC_GETPRIVATEDATA, and having empty "else" variant is IMHO
just asking for troubles. Or what about
#ifdef CONFIG_COMPAT
if (cmd == NCP_IOC_GETPRIVATEDATA_32) {
struct ...
} else
#endif
if (copy_to_user(argp, &user, sizeof(user)))
return -EFAULT;
Thanks,
Petr
-
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/
Powered by blists - more mailing lists