>-----Original Message----- >From: Song, Barry >Sent: Wednesday, June 23, 2010 3:57 PM >To: Zhang, Sonic; 'Mike Frysinger' >Cc: '[email protected]'; >'[email protected]' >Subject: RE: [Linux-kernel-commits] [8926] >trunk/fs/binfmt_flat.c:[!no_src_qa!] > > > >>-----Original Message----- >>From: Zhang, Sonic >>Sent: Tuesday, June 22, 2010 5:12 PM >>To: Mike Frysinger; Song, Barry >>Cc: [email protected]; >>[email protected] >>Subject: RE: [Linux-kernel-commits] [8926] >>trunk/fs/binfmt_flat.c:[!no_src_qa!] >> >> >> >>>-----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. > >Maybe send a single patch to fix the current code style issue >in fs/binfmt_flat.c of mainline? >
Yes, please. Sonic >> >>>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
