>-----Original Message----- >From: Mike Frysinger [mailto:[email protected]] >Sent: Friday, June 18, 2010 10:01 PM >To: [email protected] >Cc: [email protected] >Subject: Re: [Linux-kernel-commits] [8926] >trunk/fs/binfmt_flat.c: [!no_src_qa!] > >On Fri, Jun 18, 2010 at 04:33, <[email protected]> wrote: >> [#6034], fix argv and envp pointer while using L1 stack >> >> Modified: trunk/fs/binfmt_flat.c (8925 => 8926) >> >> put_user(argc, sp); >> current->mm->arg_start = (unsigned long) p; >> while (argc-->0) { >> +#ifndef CONFIG_APP_STACK_L1 >> put_user((unsigned long) p, argv++); >> +#else >> + put_user((unsigned long) p + l1_ram_offset, argv++); >> +#endif >> ... >> while (envc-->0) { >> - put_user((unsigned long)p, envp); envp++; >> +#ifndef CONFIG_APP_STACK_L1 >> + put_user((unsigned long)p, envp++); >> +#else >> + put_user((unsigned long)p + l1_ram_offset, envp++); >> +#endif > >i dont think we want this behavior. the argv/envp can easily exceed >the tiny 4k scratchpad, not to mention the app itself exceeding it. The origin codes actually have copied argv and env to L1 stack. Following the old logic, adjusting SP+1 is the right way to a fast fix. Then you mean we can place argv and env in ram and give a legal VMA to cover it? That will make a difference and mean a new small task, not a bug fix.
>-mike > _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
