On Wed 30 Jun 2010 02:05, Mike Frysinger pondered: > On Mon, Jun 28, 2010 at 17:55, Robin Getz wrote: > > On Thu 24 Jun 2010 06:19, Song, Barry pondered: > >> On Mon 21 Jun 2010 06:19, [email protected] pondered: > >> > Modified: trunk/arch/blackfin/kernel/ptrace.c (8929 => 8930) > >> > > >> > --- trunk/arch/blackfin/kernel/ptrace.c 2010-06-21 03:21:30 UTC (rev 8929) > >> > +++ trunk/arch/blackfin/kernel/ptrace.c 2010-06-21 10:19:50 UTC (rev 8930) > >> > @@ -27,6 +27,7 @@ > >> > #include <asm/fixed_code.h> > >> > #include <asm/cacheflush.h> > >> > #include <asm/mem_map.h> > >> > +#include <asm/mmu_context.h> > >> > > >> > /* > >> > * does not yet catch signals sent when the child dies. > >> > @@ -135,6 +136,13 @@ > >> > if (start >= FIXED_CODE_START && start + len < FIXED_CODE_END) > >> > return 0; > >> > > >> > +#ifdef CONFIG_APP_STACK_L1 > >> > + if (child->mm->context.l1_stack_save) > >> > + if (start >= (unsigned long)l1_stack_base && > >> > + start + len < (unsigned long)l1_stack_base + > >> > + l1_stack_len) > >> > + return 0; > >> > +#endif > >> > + > >> > >> > Does this need to have the #ifdef/stack check? or should we just > >> > allow scratchpad all the time? > >> > > >> I guess we can allow scratchpad all the time. Whether there is L1 stack > >> depends on applications, not kernel. > >> That means we will delete this configuration option and related > >> references. > >> > >> There is still a reason to keep APP_STACK_L1 option(L1 is shared by > >> application stack and exception stack): > > > > Thanks - that makes sense - How about: > > > > #ifndef CONFIG_EXCEPTION_L1_SCRATCH then? > > > > And (in theory) we should have the same in _access_ok - shouldn't we? > > It looks like only allow core B scratch? > > what about the next option that uses L1 scratch ? do we change every > location to check that define too ?
I guess I thought the only thing that should preclude userspace from using L1 scratch (in any manner) is if the exception stack is there... Adding run time locking is a better way to do resource management (same way we do L1 data, or L1 instruction) than a compile time configuration. IMO > i think the current Kconfig keeps things cleanly separated according > to functionality. But that's the point - the next time someone wants to use L1 scratch for something - its a new Kconfig, rather than just telling the kernel they are going to use it, and not to let anyone else use it... (It would not be as flexible going forward). _______________________________________________ Linux-kernel-commits mailing list [email protected] https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits
