From: He Zhe <zhe.he@windriver.com>
To: Arnd Bergmann <arnd@arndb.de>,
Clemens Ladisch <clemens@ladisch.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hpet: Support 32-bit userspace
Date: Thu, 6 Jun 2024 17:47:30 +0800 [thread overview]
Message-ID: <f418409a-6a7c-4d28-922d-089486f6fc70@windriver.com> (raw)
In-Reply-To: <acfe6adb-2070-445c-aecc-ec0972355d8a@app.fastmail.com>
On 2024/6/6 16:12, Arnd Bergmann wrote:
> On Thu, Jun 6, 2024, at 08:13, He Zhe wrote:
>> diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
>> index d51fc8321d41..025a5905a370 100644
>> --- a/drivers/char/hpet.c
>> +++ b/drivers/char/hpet.c
>> @@ -269,7 +269,8 @@ hpet_read(struct file *file, char __user *buf,
>> size_t count, loff_t * ppos)
>> if (!devp->hd_ireqfreq)
>> return -EIO;
>>
>> - if (count < sizeof(unsigned long))
>> + if ((sizeof(int) != sizeof(long) && count < sizeof(compat_ulong_t)) ||
>> + (sizeof(int) == sizeof(long) && count < sizeof(unsigned long)))
>> return -EINVAL;
>>
>> add_wait_queue(&devp->hd_waitqueue, &wait);
>> @@ -294,9 +295,15 @@ hpet_read(struct file *file, char __user *buf,
>> size_t count, loff_t * ppos)
>> schedule();
>> }
>>
>> - retval = put_user(data, (unsigned long __user *)buf);
>> - if (!retval)
>> - retval = sizeof(unsigned long);
>> + if (sizeof(int) != sizeof(long) && count == sizeof(compat_ulong_t)) {
>> + retval = put_user(data, (compat_ulong_t __user *)buf);
>> + if (!retval)
>> + retval = sizeof(compat_ulong_t);
>> + } else {
>> + retval = put_user(data, (unsigned long __user *)buf);
>> + if (!retval)
>> + retval = sizeof(unsigned long);
>> + }
> This does not look right: you are changing the behavior for
> both 32-bit and 64-bit mode, and now choose the output based
> on how many bytes userspace asked for. This has at least two
> problems:
>
> - if userspace asks for 5 to 7 bytes on a 64-bit kernel,
> it returns 8 bytes, overflowing the provided buffer.
> - when 32-bit userspace asks for 8 or more bytes, it
> gets 8 bytes instead of 4.
>
> Instead, you should check in_compat_syscall() to see
> which output matches the running task.
Thanks. I have should have known this helper.
v2 sent to address the above and below issues.
Regards,
Zhe
>
>> @@ -651,14 +658,23 @@ struct compat_hpet_info {
>> unsigned short hi_timer;
>> };
>>
>> +#define COMPAT_HPET_INFO _IOR('h', 0x03, struct compat_hpet_info)
>> +#define COMPAT_HPET_IRQFREQ _IOW('h', 0x6, compat_ulong_t)
> Right, it looks this was missing from my original change 54066a57c584
> ("hpet: kill BKL, add compat_ioctl").
>
> COMPAT_HPET_IRQFREQ should probably have a comment about the
> command code being wrong.
>
>> mutex_lock(&hpet_mutex);
>> - err = hpet_ioctl_common(file->private_data, cmd, arg, &info);
>> + err = hpet_ioctl_common(file->private_data, cmd, (unsigned
>> long)compat_ptr(arg), &info);
>> mutex_unlock(&hpet_mutex);
> While this works on x86, this is not a correct use of
> compat_ptr() on architectures that modify the pointer
> in compat_ptr(). Since HPET_INFO is the only one that
> passes a pointer and that one is handled separately,
> you should just drop the compat_ptr() conversion here.
>
> Arnd
prev parent reply other threads:[~2024-06-06 9:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 6:13 He Zhe
2024-06-06 8:12 ` Arnd Bergmann
2024-06-06 9:47 ` He Zhe [this message]
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=f418409a-6a7c-4d28-922d-089486f6fc70@windriver.com \
--to=zhe.he@windriver.com \
--cc=arnd@arndb.de \
--cc=clemens@ladisch.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.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
all inboxes | Powered by JetHome®