From: Chris Metcalf <cmetcalf@tilera.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, arnd@arndb.de
Subject: Re: [PATCH] arch/tile: updates to hardwall code from community feedback.
Date: Sun, 4 Jul 2010 07:54:16 -0400 [thread overview]
Message-ID: <4C307668.40002@tilera.com> (raw)
In-Reply-To: <20100704035759.GA5888@linux-sh.org>
On 7/3/2010 11:57 PM, Paul Mundt wrote:
> On Fri, Jul 02, 2010 at 11:45:18AM -0400, Chris Metcalf wrote:
>
>> #define for_each_hardwall_task_safe(pos, n, head) \
>> - hardwall_for_each_entry_safe(pos, n, head, thread.hardwall_list)
>> + list_for_each_entry_safe(pos, n, head, thread.hardwall_list)
>>
>>
> If you've killed off the rest of the wrappers due to them not really
> having to do anything special, you could do the same for this one, too.
>
Good point, thanks. Done.
>> static struct hardwall_info *hardwall_create(
>> - size_t size, const unsigned long __user *bits)
>> + size_t size, const unsigned char __user *bits)
>> {
>> [...]
>>
>>
> Does it even make any sense to accept > sizeof(struct cpumask) ? Your
> case below obviously handles this by making sure the rest of the bits are
> zeroed, but that still seems a bit excessive. If anything, the
> sizeof(struct cpumask) should be your worst case (or just rejected out of
> hand), and you could use cpumask_size() for everything else.
>
Yes, it does make sense; see get_nodes() in mm/mempolicy.c for a similar
API philosophy. The idea is that you don't want to tie userspace code
to the particular NR_CPUS that you happened to build your kernel with.
So you let userspace use any reasonable value for its bitmask, and as
long as it's passing zeroes for the >NR_CPUS positions, that's OK.
cpumask_parse_user() won't help here, since we're not parsing an ASCII
string input. The main flow is just a copy_from_user() for the bits in
the mask, then an optional memset() if the user specified fewer than
NR_CPUS cpus, or a scan to check for set bits if the user specified more
than NR_CPUS cpus.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
WARNING: multiple messages have this Message-ID (diff)
From: Chris Metcalf <cmetcalf@tilera.com>
To: Paul Mundt <lethal@linux-sh.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-arch@vger.kernel.org>,
<arnd@arndb.de>
Subject: Re: [PATCH] arch/tile: updates to hardwall code from community feedback.
Date: Sun, 4 Jul 2010 07:54:16 -0400 [thread overview]
Message-ID: <4C307668.40002@tilera.com> (raw)
In-Reply-To: <20100704035759.GA5888@linux-sh.org>
On 7/3/2010 11:57 PM, Paul Mundt wrote:
> On Fri, Jul 02, 2010 at 11:45:18AM -0400, Chris Metcalf wrote:
>
>> #define for_each_hardwall_task_safe(pos, n, head) \
>> - hardwall_for_each_entry_safe(pos, n, head, thread.hardwall_list)
>> + list_for_each_entry_safe(pos, n, head, thread.hardwall_list)
>>
>>
> If you've killed off the rest of the wrappers due to them not really
> having to do anything special, you could do the same for this one, too.
>
Good point, thanks. Done.
>> static struct hardwall_info *hardwall_create(
>> - size_t size, const unsigned long __user *bits)
>> + size_t size, const unsigned char __user *bits)
>> {
>> [...]
>>
>>
> Does it even make any sense to accept > sizeof(struct cpumask) ? Your
> case below obviously handles this by making sure the rest of the bits are
> zeroed, but that still seems a bit excessive. If anything, the
> sizeof(struct cpumask) should be your worst case (or just rejected out of
> hand), and you could use cpumask_size() for everything else.
>
Yes, it does make sense; see get_nodes() in mm/mempolicy.c for a similar
API philosophy. The idea is that you don't want to tie userspace code
to the particular NR_CPUS that you happened to build your kernel with.
So you let userspace use any reasonable value for its bitmask, and as
long as it's passing zeroes for the >NR_CPUS positions, that's OK.
cpumask_parse_user() won't help here, since we're not parsing an ASCII
string input. The main flow is just a copy_from_user() for the bits in
the mask, then an optional memset() if the user specified fewer than
NR_CPUS cpus, or a scan to check for set bits if the user specified more
than NR_CPUS cpus.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
next prev parent reply other threads:[~2010-07-04 11:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-02 15:45 [PATCH] arch/tile: updates to hardwall code from community feedback Chris Metcalf
2010-07-03 19:13 ` Arnd Bergmann
2010-07-04 3:57 ` Paul Mundt
2010-07-04 11:54 ` Chris Metcalf [this message]
2010-07-04 11:54 ` Chris Metcalf
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=4C307668.40002@tilera.com \
--to=cmetcalf@tilera.com \
--cc=arnd@arndb.de \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.