>-----Original Message----- >From: [email protected] >[mailto:[email protected]] On >Behalf Of Mike Frysinger >Sent: Tuesday, June 22, 2010 1:56 PM >To: Song, Barry >Cc: [email protected]; >[email protected] >Subject: Re: [Linux-kernel-commits] [8926] >trunk/fs/binfmt_flat.c:[!no_src_qa!] > >On Tue, Jun 22, 2010 at 01:29, Song, Barry wrote: >>From: Mike Frysinger [mailto:[email protected]] >>>On Mon, Jun 21, 2010 at 23:35, Song, Barry wrote: >>>>From: Mike Frysinger [mailto:[email protected]] >>>>>On Sun, Jun 20, 2010 at 22:27, Song, Barry wrote: >>>>>> If the string is not in L1, how could helloworld can be >printed in >>>>>> application by argv[1]. >>>>> >>>>>because argv[1] is not the same thing as argv[1][...]. >there is no >>>>>requirement that the strings themselves be placed on the >stack, only >>>>>the pointers to the strings. >>>> >>>> The fix was following the origin procedure. I have given a >>>definite reply at the first time that the current pointer >and content >>>are both in L1. >>>> If you want to place contents to RAM, there will be a new >>>little task. >>> >>>see, i dont think that's true. i just booted up 2007R1.1 >and it shows >>>argv/envp on the stack, but not the string contents >>> >>>2007R1.1: >>>&str : 0xffb00f28 >>> str : 0x5f3984 (Hello world!) >>>&argv : 0xffb00f38 >>> argv : 0xffb00f84 >>>&argv[0]: 0xffb00f84 >>> argv[0]: 0x5f7f9c (/helloworld) >>>&envp : 0x5f452c >>> envp : 0xffb00f8c >>>&envp[0]: 0xffb00f8c >>> envp[0]: 0x5f7fa8 (HOME=/) >>> >>>current trunk: >>>&str : 0xffb00f28 >>> str : 0x262b9a0 (Hello world!) >>>&argv : 0xffb00f38 >>> argv : 0xffb00f84 >>>&argv[0]: 0xffb00f84 >>> argv[0]: 0xffb00fa0 (/helloworld) >>>&envp : 0x262c548 >>> envp : 0xffb00f8c >>>&envp[0]: 0xffb00f8c >>> envp[0]: 0xffb00fac (TERM=linux) >>> >>>so i dont know why you think older versions placed their strings on >>>the stack when older versions dont actually do that >> >> Pls check the codes. It copied all to L1, but hasn't updated >the sp+1 pointer. Contents have been in L1, and also in RAM. >> How could "helloworld " be shown by argv[0] in the >scraptchpad program since my patch only changed the pointer? >> You should find my patch doesn't copy anything. > >assuming that's true (going by the offsets with the above >pointers, it looks like it just might be), that's a fair >point. but it's hard to review the patch when there's so much >junk in it. my previous point about cleaning up the commit >still needs addressing: drop the useless #ifdef checks and >restore the whitespace style. >
Barry will rollback his patch and code style changes. >once that is done, we can move on and open a tracker item >about fixing the string locations and stack space reservation for them. The CONFIG_APP_STACK_L1 Macro was fist applied to fs/binfmt_flat.c by Graf for SMP kernel tasks in middle 2008. Barry's new patch just follows the existing code. It looks Graf's patch should not depend on CONFIG_APP_STACK_L1. I will commit a fix. As to the argv in L1 bug, the old code copied both the argv pointers and env string to L1 while leave argv pointers still point to env string in SDRAM. In MPU mode, access to string in SDRAM without page table causes error. We either change the argv pointers to string in L1 in the cost of wasting L1 SRAM(Barry's patch with weak arch function called by binfmt_flat.c) or add proper MPU page table against string in SDRAM when load binary(may affect common code as well). Sonic >-mike >_______________________________________________ >Linux-kernel-commits mailing list >[email protected] >https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits > _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
