linux.kernel - 3 new messages in 3 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* race condition in mm/page_alloc.c regarding page->lru? - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f97742bee2f6e05c?hl=en
* slub: fix bad scope checking - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0e0e030b21f9d6e7?hl=en
* Block: Fix block/elevator.c elevator_get() off-by-one error - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/0573c1f5ba91f5d7?hl=en

==============================================================================
TOPIC: race condition in mm/page_alloc.c regarding page->lru?
http://groups.google.com/group/linux.kernel/t/f97742bee2f6e05c?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 2 2010 12:10 am
From: Daniel Mack

On Fri, Apr 02, 2010 at 11:51:33AM +0800, TAO HU wrote:
> On Thu, Apr 1, 2010 at 12:05 PM, TAO HU <tghk48@motorola.com> wrote:
> > We got a panic on our ARM (OMAP) based HW.
> > Our code is based on 2.6.29 kernel (last commit for mm/page_alloc.c is
> > cc2559bccc72767cb446f79b071d96c30c26439b)
> >
> > It appears to crash while going through pcp->list in
> > buffered_rmqueue() of mm/page_alloc.c after checking vmlinux.
> > "00100100" implies LIST_POISON1 that suggests a race condition between
> > list_add() and list_del() in my personal view.
> > However we not yet figure out locking problem regarding page.lru.

I'm sure this is just a memory corruption which is unrelated to code in
the the memory management area. The code there just happens to trigger
it as it is called frequently and is very sensitive to bogus data

Did you see the other thread I started off yesterday?

http://lkml.indiana.edu/hypermail/linux/kernel/1004.0/00157.html

We could well see the same problem here. Not sure though as any kind of
memory corruption ends up in Ooopses like the ones you see, but it could
be a hint.

Daniel

--
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: slub: fix bad scope checking
http://groups.google.com/group/linux.kernel/t/0e0e030b21f9d6e7?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 2 2010 12:10 am
From: Pekka Enberg

Christoph Lameter wrote:
> On Thu, 1 Apr 2010, Zhang, Yanmin wrote:
>
>> Function init_kmem_cache_nodes is incorrect when checking upper limitation
>> of kmalloc_caches.
>
> True.
>
> Acked-by: Christoph Lameter <cl@linux-foundation.org>

Applied, 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: Block: Fix block/elevator.c elevator_get() off-by-one error
http://groups.google.com/group/linux.kernel/t/0573c1f5ba91f5d7?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 2 2010 12:20 am
From: Xiaotian Feng

On Tue, Mar 30, 2010 at 5:21 PM, <wzt.wzt@gmail.com> wrote:
> elevator_get() not check the name length, if the name length > sizeof(elv),
> elv will miss the '\0'. And elv buffer will be replace "-iosched" as something
> like aaaaaaaaa, then call request_module() can load an not trust module.
>
> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
>
> ---
>  block/elevator.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/block/elevator.c b/block/elevator.c
> index df75676..76e3702 100644
> --- a/block/elevator.c
> +++ b/block/elevator.c
> @@ -154,7 +154,7 @@ static struct elevator_type *elevator_get(const char *name)
>
>                spin_unlock(&elv_list_lock);
>
> -               sprintf(elv, "%s-iosched", name);
> +               snprintf(elv, sizeof(elv), "%s-iosched", name);
>

elv is defined as char elv[ELV_NAME_MAX + strlen("-iosched")];
so if name length > sizeof(elv), the name length must already bigger
than ELV_NAME_MAX

elevator_get is used in elevator_init, so if elevator_init is passing
a super long name, why not just return -EINVAL?
In this patch, if we pass a super long name, we're still trying to cut
it and request_module an invalid name, right?
Although '\0' is kept, but name is still invalid, right?

>                request_module("%s", elv);
>                spin_lock(&elv_list_lock);
> --
> 1.6.5.3
>
> --
> 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/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en