lkml.org 
[lkml]   [2011]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] unicore32, exec: remove redundant set_fs(USER_DS)
    From
    Date
    On Mon, 2011-06-13 at 18:02 +0200, Mathias Krause wrote:
    > On 13.06.2011, 11:19 Guan Xuetao wrote:
    > > On Fri, 2011-06-10 at 15:11 +0200, Mathias Krause wrote:
    > >> The address limit is already set in flush_old_exec() so this
    > >> set_fs(USER_DS) is redundant.
    > >>
    > >> Signed-off-by: Mathias Krause <minipli@googlemail.com>
    > >> ---
    > >> arch/unicore32/include/asm/processor.h | 1 -
    > >> 1 files changed, 0 insertions(+), 1 deletions(-)
    > >>
    > >> diff --git a/arch/unicore32/include/asm/processor.h b/arch/unicore32/include/asm/processor.h
    > >> index e11cb07..f0d780a 100644
    > >> --- a/arch/unicore32/include/asm/processor.h
    > >> +++ b/arch/unicore32/include/asm/processor.h
    > >> @@ -53,7 +53,6 @@ struct thread_struct {
    > >> #define start_thread(regs, pc, sp) \
    > >> ({ \
    > >> unsigned long *stack = (unsigned long *)sp; \
    > >> - set_fs(USER_DS); \
    > >> memset(regs->uregs, 0, sizeof(regs->uregs)); \
    > >> regs->UCreg_asr = USER_MODE; \
    > >> regs->UCreg_pc = pc & ~1; /* pc */ \
    > >
    > > Hi Mathias,
    > > I searched for the code in flush_old_exec(), but I can't find the code
    > > you mentioned. Could you make it more clear?
    >
    > Sorry, this statement is based on a commit post v3.0-rc2. Before dac853a (exec:
    > delay address limit change until point of no return) it was done in
    > search_binary_handler(), now it is done in flush_old_exec(). Either way
    > set_fs(USER_DS) gets called before start_thread() so the call there is
    > redundant.
    >
    > > And, if all fs codes (not only elf and aout) have the similar
    > > implementations,
    >
    > I've checked that all binary format handler call flush_old_exec() before
    > start_thread(). So: yes.
    >
    > > perhaps all arch-specific codes should be manipulated
    > > in the meanwhile.
    >
    > That's what this LKML thread is for: https://lkml.org/lkml/2011/6/10/65
    >
    > Thanks,
    > Mathias
    Thanks for your explanations.
    The patch looks good to me.

    Guan Xuetao




    \
     
     \ /
      Last update: 2011-06-14 09:05    [W:0.025 / U:1.212 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site