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 think the current Kconfig keeps things cleanly separated according
to functionality.
-mike
_______________________________________________
Linux-kernel-commits mailing list
[email protected]
https://blackfin.uclinux.org/mailman/listinfo/linux-kernel-commits

Reply via email to