linux-mips
[Top] [All Lists]

Re: [PATCH] MIPS: use 32-bit wrapper for compat_sys_futex

To: David Daney <david.daney@cavium.com>
Subject: Re: [PATCH] MIPS: use 32-bit wrapper for compat_sys_futex
From: Yong Zhang <yong.zhang@windriver.com>
Date: Fri, 19 Aug 2011 09:56:07 +0800
Cc: <linux-mips@linux-mips.org>, <linux-kernel@vger.kernel.org>, Ralf Baechle <ralf@linux-mips.org>
In-reply-to: <4E4D3C8D.1040707@cavium.com>
References: <1313546094-11882-1-git-send-email-yong.zhang@windriver.com> <4E4BF7C0.80703@cavium.com> <20110818023247.GA3750@windriver.com> <4E4D3C8D.1040707@cavium.com>
Reply-to: Yong Zhang <yong.zhang@windriver.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Aug 18, 2011 at 09:23:41AM -0700, David Daney wrote:
> On 08/17/2011 07:32 PM, Yong Zhang wrote:
> >On Wed, Aug 17, 2011 at 10:17:52AM -0700, David Daney wrote:
> >>>diff --git a/arch/mips/kernel/scall64-o32.S 
> >>>b/arch/mips/kernel/scall64-o32.S
> >>>index 46c4763..f48b18e 100644
> >>>--- a/arch/mips/kernel/scall64-o32.S
> >>>+++ b/arch/mips/kernel/scall64-o32.S
> >>>@@ -441,7 +441,7 @@ sys_call_table:
> >>>   PTR     sys_fremovexattr                /* 4235 */
> >>>   PTR     sys_tkill
> >>>   PTR     sys_sendfile64
> >>>-  PTR     compat_sys_futex
> >>>+  PTR     sys_32_futex
> >>
> >>This change is redundant, scall64-o32.S already does the right thing
> >
> >My first virsion(not sent out) doesn't include scall64-o32.S either.
> >
> >>so additional zero extending is not needed and is just extra
> >>instructions to execute for no reason.
> >
> >Why I'm adding it here is for:
> >1)code consistent, otherwise we must move SYSCALL_DEFINE6(32_futex,...)
> >   under CONFIG_MIPS32_N32;
> 
> No, you don't have to move it.  Just don't call it.
> 
> 
> >2)I'm afraid there may be some other way to touch the high 32-bit of a
> >   register, so touching scall64-o32.S is also for safety(due to unknown
> >   reason, fix me if I'm wrong).
> 
> OK: You are mistaken.  You claim you don't understand what the code
> does.  That is really a poor justification for modifying it.

If you don't like it and you are sure there is no potential security problem,
just make a patch to remove it. Go ahead.

Thanks,
Yong

<Prev in Thread] Current Thread [Next in Thread>