linux.kernel - 26 new messages in 17 topics - digest
linux.kernel
http://groups.google.com/group/linux.kernel?hl=en
Today's topics:
* bridge: make bridge support netpoll - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/716f4d07472adb41?hl=en
* proc: task->signal can't be NULL - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f9a3055c2ddbc988?hl=en
* Build error with v2.6.34-rc2-51-g7b1f513 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/097b532060577d54?hl=en
* Netfilter: Fix integer overflow in net/ipv6/netfilter/ip6_tables.c - 6
messages, 3 authors
http://groups.google.com/group/linux.kernel/t/a3ad7f06fccbf122?hl=en
* mm/nommu.c:Dynamic alloc/free percpu area for nommu - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/83a8db92f1b52963?hl=en
* staging:cx2581: fixes coding style issues in cx25821-cards.c - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/2efc7e44e0fe6505?hl=en
* kcore: fix test for end of list - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b36880f8a3424693?hl=en
* via-velocity: FLOW_CNTL_RX does not disable Asymmetric pause in set_mii_flow_
control() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/cf9030e0567f76de?hl=en
* netpoll: warn when there are spaces in parameters - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5f5228e52db25937?hl=en
* input/touchscreen: Synaptics Touchscreen Driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/007557dbf7e1dd33?hl=en
* timer: Provide config option for enabling timer tracepoints - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/d04cd128af8ac59d?hl=en
* BUG:write data to degrade raid5 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b4fddf64000ca82f?hl=en
* linux-next: manual merge of the kgdb tree with the input tree - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/e08124475cd090ed?hl=en
* Enhance perf to collect KVM guest os statistics from host side - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/728080d27436ebc6?hl=en
* lockdep warning during elevator_switch - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/1feb2563ac559b3f?hl=en
* forcedeth: cat /sys/class/net/eth0/carrier = Invalid argument - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/8c050068d62e9e88?hl=en
* intel-agp.c: Fix crash when accessing nonexistent GTT entries in i915 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/bcbed4037b6559cf?hl=en
==============================================================================
TOPIC: bridge: make bridge support netpoll
http://groups.google.com/group/linux.kernel/t/716f4d07472adb41?hl=en
==============================================================================
== 1 of 3 ==
Date: Mon, Mar 22 2010 7:10 pm
From: Cong Wang
Matt Mackall wrote:
> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> Based on the previous patch, make bridge support netpoll by:
>>
>> 1) implement the 4 methods to support netpoll for bridge;
>>
>> 2) modify netpoll during forwarding packets in bridge;
>>
>> 3) disable netpoll support of bridge when a netpoll-unabled device
>> is added to bridge;
>
> Not sure if this is the right thing to do. Shouldn't we simply enable
> polling on all devices that support it and warn about the others (aka
> best effort)?
>
I don't think it's a good idea, because we check if a device
supports netpoll by checking if it has ndo_poll_controller method.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 3 ==
Date: Mon, Mar 22 2010 7:20 pm
From: Cong Wang
Matt Mackall wrote:
> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> This whole patchset is for adding netpoll support to bridge and bonding
>> devices. I already tested it for bridge, bonding, bridge over bonding,
>> and bonding over bridge. It looks fine now.
>
> Ages ago, Jeff Moyer took a run at this, added him to the cc: on the off
> chance he still cares.
>
>> Please comment.
>>
>>
>> To make bridge and bonding support netpoll, we need to adjust
>> some netpoll generic code. This patch does the following things:
>>
>> 1) introduce two new priv_flags for struct net_device:
>> IFF_IN_NETPOLL which identifies we are processing a netpoll;
>> IFF_DISABLE_NETPOLL is used to disable netpoll support for a device
>> at run-time;
>
> This one is a little worrisome. I've tried to keep the netpoll code
> restricted to as tight an area as possible. Adding new flags like these
> that random drivers might try to fiddle with seems like a good way for a
> driver writer to get in trouble. Also flag space is filling up.
Somewhat, but currently I don't have other way to replace this.
Any suggestions?
>
>> 2) introduce three new methods for netdev_ops:
>> ->ndo_netpoll_setup() is used to setup netpoll for a device;
>> ->ndo_netpoll_xmit() is used to transmit netpoll requests;
>> ->ndo_netpoll_cleanup() is used to clean up netpoll when a device is
>> removed.
>
> Seems like a lot of interface for something to be used by only a couple
> core drivers. Hopefully Dave has an opinion here.
>
Yeah, I worry about this too, maybe we can group those methods
for netpoll together into another struct, and just put a pointer
here?
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 3 of 3 ==
Date: Mon, Mar 22 2010 8:50 pm
From: David Miller
From: Cong Wang <amwang@redhat.com>
Date: Tue, 23 Mar 2010 10:13:43 +0800
> Matt Mackall wrote:
>> Seems like a lot of interface for something to be used by only a
>> couple
>> core drivers. Hopefully Dave has an opinion here.
>>
>
> Yeah, I worry about this too, maybe we can group those methods
> for netpoll together into another struct, and just put a pointer
> here?
This looks like it's tackled at the wrong layer, to be honest.
Teaching all of these layers about eachother's states is
going to end up being a nightmare in the end.
All of this "where is the npinfo" business can be handled
generically in net/core/dev.c I think, with none of these
callbacks.
For example, something like "if dev lacks ->npinfo, check
it's master".
Another thing, I wouldn't iterate over all devices, like I
see in the bonding poll controller method. Just whichever
one supports netpoll you see first, use it and exit
immediately. Don't send it to every single port, I can't
see how that might be desirable or useful.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: proc: task->signal can't be NULL
http://groups.google.com/group/linux.kernel/t/f9a3055c2ddbc988?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Mar 22 2010 7:20 pm
From: ebiederm@xmission.com (Eric W. Biederman)
Oleg Nesterov <oleg@redhat.com> writes:
> With the recent changes in -mm it is always safe to dereference
> task->signal. It can't be NULL and it is pinned to task_struct.
>
> fs/proc becomes the only valid user of signal->count which should
> either die or become "int nr_threads".
>
>
> Alexey, Eric.
>
> Can't we kill this counter? Afaics, get_nr_threads() doesn't need to
> be "precise", we probably can estimate the number of threads using
> signal->live (yes sure, we can't use ->live as nr_threads).
>
> Except: first_tid() uses get_nr_threads() for optimization. Is this
> optimization really important? Afaics, it only helps in the unlikely
> case, probably in that case the extra lockless while_each_thread()
> doesn't hurt.
>
> IOW, how about
>
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -3071,11 +3071,6 @@ static struct task_struct *first_tid(str
> goto found;
> }
>
> - /* If nr exceeds the number of threads there is nothing todo */
> - pos = NULL;
> - if (nr && nr >= get_nr_threads(leader))
> - goto out;
> -
> /* If we haven't found our starting place yet start
> * with the leader and walk nr threads forward.
> */
>
> ?
>
> Not that I think it is terribly important to kill this counter, and
> probably signal->nr_threads can make sense anyway, so far I am just
> curious.
I think that was just a sanity check since it was easy. I want to say
it prevents a DOS attack with user space passing unreasonably large
file position but that DOS attack is handled by ensuring we don't walk
through the list if threads more than once.
However:
proc_task_getattr uses get_nr_threads to get it's nlink count correct.
Not walking the thread list to get the number of threads seems like an
important cpu time saving measure.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Build error with v2.6.34-rc2-51-g7b1f513
http://groups.google.com/group/linux.kernel/t/097b532060577d54?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Mar 22 2010 7:30 pm
From: Américo Wang
On Tue, Mar 23, 2010 at 5:15 AM, Chris Clayton <chris2553@googlemail.com> wrote:
> Hi,
>
> Commit 45575f5a426c01ec68cd33d998267ba2f6278fac seems to be causing the build
> error shown below on i386:
>
> CC ipc/syscall.o
> ipc/syscall.c:17: error: conflicting types for 'sys_ipc'
> include/linux/syscalls.h:691: note: previous declaration of 'sys_ipc' was
> here
> make[1]: *** [ipc/syscall.o] Error 1
> make: *** [ipc] Error 2
> make: *** Waiting for unfinished jobs....
>
> I can see that changing the type of the third arg to sys_ipc in
> include/linux/syscalls.h would probably avoid the error, but I am not
> knowledgeable enough to know whether that would be the right thing to do.
>
> Happy to test a patch, but please cc me as I'm not subscribed.
Linus already fixed this in his tree. Please check out.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: Netfilter: Fix integer overflow in net/ipv6/netfilter/ip6_tables.c
http://groups.google.com/group/linux.kernel/t/a3ad7f06fccbf122?hl=en
==============================================================================
== 1 of 6 ==
Date: Mon, Mar 22 2010 7:40 pm
From: Xiaotian Feng
On Tue, Mar 23, 2010 at 9:34 AM, wzt wzt <wzt.wzt@gmail.com> wrote:
>> I can see that the size might cause an overflow in the addition with
>> sizeof(struct ipt_get_entries)
> That's the integer overflow i pointed.
> get.size is copy from the user space, it can be set as 0x7fffffff,
> addition with sizeof(struct ipt_get_entries) can be overflow.
Patrick's point is that you're using "if (get.size >= INT_MAX /
sizeof(struct ipt_get_entries))"
So, did you find any chance that get.size * sizeof(struct
ipt_get_entries) >= INT_MAX ?
And, for the addition overflow, can it be caught by
"if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>
> if (*len != sizeof(struct ipt_get_entries) + get.size) {
> duprintf("get_entries: %u != %zu\n",
> *len, sizeof(get) + get.size);
> return -EINVAL;
> }
>
> so, check get.size max value before addition with sizeof(struct
> ipt_get_entries) to prevent the integer overflow.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 2 of 6 ==
Date: Mon, Mar 22 2010 7:40 pm
From: wzt wzt
> Patrick's point is that you're using "if (get.size >= INT_MAX /
> sizeof(struct ipt_get_entries))"
> So, did you find any chance that get.size * sizeof(struct
> ipt_get_entries) >= INT_MAX ?
>
would you carefully read my explain???
get.size is copy from the user space, it can be set as 0x7fffffff,
addition with sizeof(struct ipt_get_entries) can be overflow.
> And, for the addition overflow, can it be caught by
>
> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>
sizeof(struct ipt_get_entries) + get.size can be overflow as *len,
get.size is control by user space with copy_from_user().
On Tue, Mar 23, 2010 at 10:29 AM, Xiaotian Feng <xtfeng@gmail.com> wrote:
> On Tue, Mar 23, 2010 at 9:34 AM, wzt wzt <wzt.wzt@gmail.com> wrote:
>>> I can see that the size might cause an overflow in the addition with
>>> sizeof(struct ipt_get_entries)
>> That's the integer overflow i pointed.
>> get.size is copy from the user space, it can be set as 0x7fffffff,
>> addition with sizeof(struct ipt_get_entries) can be overflow.
>
> Patrick's point is that you're using "if (get.size >= INT_MAX /
> sizeof(struct ipt_get_entries))"
> So, did you find any chance that get.size * sizeof(struct
> ipt_get_entries) >= INT_MAX ?
>
> And, for the addition overflow, can it be caught by
>
> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>
>>
>> if (*len != sizeof(struct ipt_get_entries) + get.size) {
>> duprintf("get_entries: %u != %zu\n",
>> *len, sizeof(get) + get.size);
>> return -EINVAL;
>> }
>>
>> so, check get.size max value before addition with sizeof(struct
>> ipt_get_entries) to prevent the integer overflow.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 3 of 6 ==
Date: Mon, Mar 22 2010 8:10 pm
From: Jan Engelhardt
On Tuesday 2010-03-23 03:37, wzt wzt wrote:
>> And, for the addition overflow, can it be caught by
>>
>> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>
>sizeof(struct ipt_get_entries) + get.size can be overflow as *len,
>get.size is control by user space with copy_from_user().
The != should catch it.
For 64-bit environments:
* + invoked with size_t, unsigned int
=> right side promoted to size_t, result type is size_t
* != invoked with int and size_t
=> left-side promoted to ssize_t (probably; but something as large as size_t)
* get.size is 32-bit bounded, as is *len,
so no overflow to worry about at all unless you make
sizeof(X) hilariously big close to 2^64 which is rather unlikely.
For 32-bit environments:
* Let *len be a number of choice (e.g. 36)
* Find a sizeof(X)+get.size that equals 36 mod 2^32.
* Since sizeof(X) is const, get.size must be 0 mod 2^32.
* So get.size must be a multiple of 2^32 to fool the system.
* Since get.size itself is only a 32-bit quantity, you cannot
represent any value larger than 4294967295.
What Was What Was Wanted.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 4 of 6 ==
Date: Mon, Mar 22 2010 8:10 pm
From: Xiaotian Feng
On Tue, Mar 23, 2010 at 10:37 AM, wzt wzt <wzt.wzt@gmail.com> wrote:
>> Patrick's point is that you're using "if (get.size >= INT_MAX /
>> sizeof(struct ipt_get_entries))"
>> So, did you find any chance that get.size * sizeof(struct
>> ipt_get_entries) >= INT_MAX ?
>>
> would you carefully read my explain???
> get.size is copy from the user space, it can be set as 0x7fffffff,
> addition with sizeof(struct ipt_get_entries) can be overflow.
>
get.size is unsigned int, UINT_MAX is 0x FFFFFFFF, not 0x7FFFFFFF
And you're metioning "addition", then why you're checking as "multiplication"?
>> And, for the addition overflow, can it be caught by
>>
>> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>>
> sizeof(struct ipt_get_entries) + get.size can be overflow as *len,
> get.size is control by user space with copy_from_user().
>
> On Tue, Mar 23, 2010 at 10:29 AM, Xiaotian Feng <xtfeng@gmail.com> wrote:
>> On Tue, Mar 23, 2010 at 9:34 AM, wzt wzt <wzt.wzt@gmail.com> wrote:
>>>> I can see that the size might cause an overflow in the addition with
>>>> sizeof(struct ipt_get_entries)
>>> That's the integer overflow i pointed.
>>> get.size is copy from the user space, it can be set as 0x7fffffff,
>>> addition with sizeof(struct ipt_get_entries) can be overflow.
>>
>> Patrick's point is that you're using "if (get.size >= INT_MAX /
>> sizeof(struct ipt_get_entries))"
>> So, did you find any chance that get.size * sizeof(struct
>> ipt_get_entries) >= INT_MAX ?
>>
>> And, for the addition overflow, can it be caught by
>>
>> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>>
>>>
>>> if (*len != sizeof(struct ipt_get_entries) + get.size) {
>>> duprintf("get_entries: %u != %zu\n",
>>> *len, sizeof(get) + get.size);
>>> return -EINVAL;
>>> }
>>>
>>> so, check get.size max value before addition with sizeof(struct
>>> ipt_get_entries) to prevent the integer overflow.
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at http://www.tux.org/lkml/
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 5 of 6 ==
Date: Mon, Mar 22 2010 8:20 pm
From: wzt wzt
> get.size is unsigned int, UINT_MAX is 0x FFFFFFFF, not 0x7FFFFFFF
> And you're metioning "addition", then why you're checking as "multiplication"?
oh, my falut:( the patch is multiplication check, not addition check.
thanks for helping me:)
On Tue, Mar 23, 2010 at 11:05 AM, Xiaotian Feng <xtfeng@gmail.com> wrote:
> On Tue, Mar 23, 2010 at 10:37 AM, wzt wzt <wzt.wzt@gmail.com> wrote:
>>> Patrick's point is that you're using "if (get.size >= INT_MAX /
>>> sizeof(struct ipt_get_entries))"
>>> So, did you find any chance that get.size * sizeof(struct
>>> ipt_get_entries) >= INT_MAX ?
>>>
>> would you carefully read my explain???
>> get.size is copy from the user space, it can be set as 0x7fffffff,
>> addition with sizeof(struct ipt_get_entries) can be overflow.
>>
>
> get.size is unsigned int, UINT_MAX is 0x FFFFFFFF, not 0x7FFFFFFF
> And you're metioning "addition", then why you're checking as "multiplication"?
>
>>> And, for the addition overflow, can it be caught by
>>>
>>> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>>>
>> sizeof(struct ipt_get_entries) + get.size can be overflow as *len,
>> get.size is control by user space with copy_from_user().
>
>
>>
>> On Tue, Mar 23, 2010 at 10:29 AM, Xiaotian Feng <xtfeng@gmail.com> wrote:
>>> On Tue, Mar 23, 2010 at 9:34 AM, wzt wzt <wzt.wzt@gmail.com> wrote:
>>>>> I can see that the size might cause an overflow in the addition with
>>>>> sizeof(struct ipt_get_entries)
>>>> That's the integer overflow i pointed.
>>>> get.size is copy from the user space, it can be set as 0x7fffffff,
>>>> addition with sizeof(struct ipt_get_entries) can be overflow.
>>>
>>> Patrick's point is that you're using "if (get.size >= INT_MAX /
>>> sizeof(struct ipt_get_entries))"
>>> So, did you find any chance that get.size * sizeof(struct
>>> ipt_get_entries) >= INT_MAX ?
>>>
>>> And, for the addition overflow, can it be caught by
>>>
>>> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>>>
>>>>
>>>> if (*len != sizeof(struct ipt_get_entries) + get.size) {
>>>> duprintf("get_entries: %u != %zu\n",
>>>> *len, sizeof(get) + get.size);
>>>> return -EINVAL;
>>>> }
>>>>
>>>> so, check get.size max value before addition with sizeof(struct
>>>> ipt_get_entries) to prevent the integer overflow.
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> Please read the FAQ at http://www.tux.org/lkml/
>>>>
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
== 6 of 6 ==
Date: Mon, Mar 22 2010 8:50 pm
From: wzt wzt
1、 suppose *len = 35, sizeof(struct ipt_get_entries) = 36
2、 set get.size = 0xffffffff from user space
3、 sizeof(struct ipt_get_entries) + get.size = 36 + 0xffffffff = 35;
4、 if (*len != sizeof(struct ipt_get_entries) + get.size) was bypassed.
you can test with c code:
#include <stdio.h>
int main(void)
{
unsigned int arg = 0xffffffff;
printf("%u\n", arg + 36);
if (35 != arg + 36) {
printf("not over flow.\n");
return -1;
}
printf("arg over flow.\n");
return 0;
}
On Tue, Mar 23, 2010 at 11:04 AM, Jan Engelhardt <jengelh@medozas.de> wrote:
>
> On Tuesday 2010-03-23 03:37, wzt wzt wrote:
>>> And, for the addition overflow, can it be caught by
>>>
>>> "if (*len != sizeof(struct ipt_get_entries) + get.size)" ???
>>
>>sizeof(struct ipt_get_entries) + get.size can be overflow as *len,
>>get.size is control by user space with copy_from_user().
>
> The != should catch it.
>
> For 64-bit environments:
> * + invoked with size_t, unsigned int
> => right side promoted to size_t, result type is size_t
> * != invoked with int and size_t
> => left-side promoted to ssize_t (probably; but something as large as size_t)
> * get.size is 32-bit bounded, as is *len,
> so no overflow to worry about at all unless you make
> sizeof(X) hilariously big close to 2^64 which is rather unlikely.
>
> For 32-bit environments:
> * Let *len be a number of choice (e.g. 36)
> * Find a sizeof(X)+get.size that equals 36 mod 2^32.
> * Since sizeof(X) is const, get.size must be 0 mod 2^32.
> * So get.size must be a multiple of 2^32 to fool the system.
> * Since get.size itself is only a 32-bit quantity, you cannot
> represent any value larger than 4294967295.
>
>
> What Was What Was Wanted.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
==============================================================================
TOPIC: mm/nommu.c:Dynamic alloc/free percpu area for nommu
http://groups.google.com/group/linux.kernel/t/83a8db92f1b52963?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Mar 22 2010 7:40 pm
From: graff yang
On Mon, Mar 22, 2010 at 7:50 PM, David Howells <dhowells@redhat.com> wrote:
> <graff.yang@gmail.com> wrote:
>
>> - return virt_to_page(addr);
>> + return (struct page *)
>> + (virt_to_page(addr)->index) ? : virt_to_page(addr);
>
> Can the extra conditional operator be made subject to CONFIG_SMP?
OK.
Tejun is looking into the up layer percpu code. So I expecting there
is better way
to hook nommu in.
>
>> - return page_to_pfn(virt_to_page(addr));
>> + return page_to_pfn((struct page *)
>> + (virt_to_page(addr)->index) ? : virt_to_page(addr));
>
> Ditto.
>
>> +#ifdef CONFIG_SMP
>> ...
>> +
posted by twitter @ 9:01 PM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home