>-----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? > >>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
