From: Dan Carpenter <dan.carpenter@oracle.com>
To: Serban Constantinescu <serban.constantinescu@arm.com>
Cc: gregkh@linuxfoundation.org, arve@android.com,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
john.stultz@linaro.org, ccross@android.com,
zach.pfeffer@linaro.org, Dave.Butcher@arm.com
Subject: Re: [PATCH 2/2] Staging: android: ashmem: Add support for 32bit ashmem calls in a 64bit kernel
Date: Tue, 4 Dec 2012 14:45:11 +0300 [thread overview]
Message-ID: <20121204114511.GI6568@mwanda> (raw)
In-Reply-To: <1354617854-25296-3-git-send-email-serban.constantinescu@arm.com>
I don't understand this, and I'm going to embarrass myself by
displaying my ignorance for all to see. Why is this code so
different from all the other 32 bit compat code that we have in the
kernel?
On Tue, Dec 04, 2012 at 10:44:14AM +0000, Serban Constantinescu wrote:
> -static int set_name(struct ashmem_area *asma, void __user *name)
> +static int set_name(struct ashmem_area *asma, userptr32_t name)
The user passes in a value which is a 32 pointer. ashmem_ioctl()
accepts it as "unsigned long arg". We pass it to set_name() which
truncates away the high zeros so now its a u32 (userptr32_t). We
then cast it to (unsigned long) and then we cast it to a void
pointer.
What's the point? Why not just take"unsigned long arg" and cast it
to a pointer directly?
> if (unlikely(copy_from_user(asma->name + ASHMEM_NAME_PREFIX_LEN,
> - name, ASHMEM_NAME_LEN)))
> + (void *)(unsigned long)name, ASHMEM_NAME_LEN)))
> ret = -EFAULT;
This will introduce a Sparse complaint. It should be:
(void __user *)(unsigned long)name.
But actually we shouldn't need to do this casting. Any casting
which we need to do should be done in one place instead of pushed
out to every function.
> + switch (_IOC_NR(cmd)) {
> + case _IOC_NR(ASHMEM_SET_NAME):
> + if (_IOC_SIZE(cmd) != sizeof(char[ASHMEM_NAME_LEN]))
> + pr_err("ashmem: ASHMEM_SET_NAME transaction size differs\n");
Don't merge debug code into the kernel. It just means people can
spam /var/log/messages.
regards,
dan carpenter
next prev parent reply other threads:[~2012-12-04 11:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-04 10:44 [PATCH 0/2] Android: Add support for a 32bit Android file system in a 64bit kernel Serban Constantinescu
2012-12-04 10:44 ` [PATCH 1/2] Staging: android: binder: Add support for 32bit binder calls " Serban Constantinescu
2012-12-04 16:17 ` Greg KH
2012-12-05 14:31 ` Serban Constantinescu
2012-12-05 15:11 ` Greg KH
2012-12-05 16:39 ` Fwd: " Serban Constantinescu
2012-12-05 16:56 ` Greg KH
2012-12-05 0:26 ` Arve Hjønnevåg
2012-12-05 14:54 ` Serban Constantinescu
2012-12-05 23:44 ` Arve Hjønnevåg
2012-12-04 10:44 ` [PATCH 2/2] Staging: android: ashmem: Add support for 32bit ashmem " Serban Constantinescu
2012-12-04 11:45 ` Dan Carpenter [this message]
2012-12-05 14:25 ` Serban Constantinescu
-- strict thread matches above, loose matches on Subject: below --
2013-02-01 16:07 [PATCH 0/2] staging: android: ashmem: add 32bit compat support Serban Constantinescu
2013-02-01 16:08 ` [PATCH 2/2] staging: android: ashmem: Add support for 32bit ashmem calls in a 64bit kernel Serban Constantinescu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121204114511.GI6568@mwanda \
--to=dan.carpenter@oracle.com \
--cc=Dave.Butcher@arm.com \
--cc=arve@android.com \
--cc=ccross@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=serban.constantinescu@arm.com \
--cc=zach.pfeffer@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).