Re: 3.9-rc5: Encountedred INFO: rcu_sched self-detected stall on CPUdue to 09a9f1d27

From: Vivek Goyal
Date: Mon May 20 2013 - 16:23:39 EST


On Mon, Apr 29, 2013 at 09:29:52AM -0400, Vivek Goyal wrote:
> On Mon, Apr 29, 2013 at 01:57:18AM -0700, Michel Lespinasse wrote:
> > On Mon, Apr 15, 2013 at 6:27 PM, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
> > > On Mon, 15 Apr 2013, Michel Lespinasse wrote:
> > >> sys_brk() passes the length as the difference of two page aligned addresses, so it's fine. But vm_brk() doesn't - it calls do_brk() which page aligns the length, but then vm_brk passes the unaligned length to mm_populate().
> > >>
> > >> What do you think of the following ? len is already a PAGE_SIZE multiple when called from sys_brk()...
> > >
> > > Yes, that's good.
> > >>
> > >> diff --git a/mm/mmap.c b/mm/mmap.c
> > >> index 0db0de1c2fbe..6af8b0d1c7db 100644
> > >> --- a/mm/mmap.c
> > >> +++ b/mm/mmap.c
> > >> @@ -2557,10 +2557,6 @@ static unsigned long do_brk(unsigned long addr, unsigned long len)
> > >> pgoff_t pgoff = addr >> PAGE_SHIFT;
> > >> int error;
> > >>
> > >> - len = PAGE_ALIGN(len);
> > >> - if (!len)
> > >> - return addr;
> > >> -
> > >> flags = VM_DATA_DEFAULT_FLAGS | VM_ACCOUNT | mm->def_flags;
> > >>
> > >> error = get_unmapped_area(NULL, addr, len, 0, MAP_FIXED);
> > >> @@ -2643,6 +2639,10 @@ unsigned long vm_brk(unsigned long addr, unsigned long len)
> > >> unsigned long ret;
> > >> bool populate;
> > >>
> > >> + len = PAGE_ALIGN(len);
> > >> + if (!len)
> > >> + return addr;
> > >> +
> > >> down_write(&mm->mmap_sem);
> > >> ret = do_brk(addr, len);
> > >> populate = ((mm->def_flags & VM_LOCKED) != 0);
> >
> > Vivek - what should I do with this change ? Do you want to take it as
> > part of your series, or should I push to Linus/Andrew ?
> >
> > All vm_brk calls are in elf and aout loaders, so I don' t think we can
> > hit the issue without your changes. Still, it may be good to make
> > vm_brk robust anyway.
>
> Hi Michel,
>
> Thanks for the fix. Sorry, could not respond earlier as I was away from
> work.
>
> This patch did fix the issue for me. I think it is a good idea to push
> this fix to Andrew irrespective of my changes. My series is in RFC phase
> and there are no guarantees whether patches will be accespected or not.
>
> So please go ahead and send this fix to andrew for inclusion.

Hi Michel,

So are you planning to push this patch upstream?

Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/