All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jslaby@suse.cz>
To: Stafford Horne <shorne@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	Richard Henderson <rth@twiddle.net>,
	Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
	Matt Turner <mattst88@gmail.com>,
	Vineet Gupta <vgupta@synopsys.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Richard Kuo <rkuo@codeaurora.org>,
	Tony Luck <tony.luck@intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Michal Simek <monstr@monstr.eu>,
	Ralf Baechle <ralf@linux-mips.org>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>,
	DavidS.Miller@zytor.com
Subject: Re: [PATCH 1/3] futex: remove duplicated code
Date: Mon, 6 Mar 2017 09:46:26 +0100	[thread overview]
Message-ID: <3662dd60-2467-f858-dc32-0b0fb6abb33b@suse.cz> (raw)
In-Reply-To: <20170304233919.GB2449@lianli.shorne-pla.net>

On 03/05/2017, 12:39 AM, Stafford Horne wrote:
> On Sat, Mar 04, 2017 at 03:08:50PM -0800, H. Peter Anvin wrote:
>> <davem@davemloft.net>,Chris Metcalf <cmetcalf@mellanox.com>,Thomas Gleixner <tglx@linutronix.de>,Ingo Molnar <mingo@redhat.com>,Chris Zankel <chris@zankel.net>,Max Filippov <jcmvbkbc@gmail.com>,Arnd Bergmann <arnd@arndb.de>,x86@kernel.org,linux-alpha@vger.kernel.org,linux-snps-arc@lists.infradead.org,linux-arm-kernel@lists.infradead.org,linux-hexagon@vger.kernel.org,linux-ia64@vger.kernel.org,linux-mips@linux-mips.org,openrisc@lists.librecores.org,linux-parisc@vger.kernel.org,linuxppc-dev@lists.ozlabs.org,linux-s390@vger.kernel.org,linux-sh@vger.kernel.org,sparclinux@vger.kernel.org,linux-xtensa@linux-xtensa.org,linux-arch@vger.kernel.org
>> From: hpa@zytor.com
>> Message-ID: <CF18535E-39E7-44D3-88D0-80B9961E6681@zytor.com>
>>
>> On March 4, 2017 1:38:05 PM PST, Stafford Horne <shorne@gmail.com> wrote:
>>> On Sat, Mar 04, 2017 at 11:15:17AM -0800, H. Peter Anvin wrote:
>>>> On 03/04/17 05:05, Russell King - ARM Linux wrote:
>>>>>>  
>>>>>> +static int futex_atomic_op_inuser(int encoded_op, u32 __user
>>> *uaddr)
>>>>>> +{
>>>>>> +	int op = (encoded_op >> 28) & 7;
>>>>>> +	int cmp = (encoded_op >> 24) & 15;
>>>>>> +	int oparg = (encoded_op << 8) >> 20;
>>>>>> +	int cmparg = (encoded_op << 20) >> 20;
>>>>>
>>>>> Hmm.  oparg and cmparg look like they're doing these shifts to get
>>> sign
>>>>> extension of the 12-bit values by assuming that "int" is 32-bit -
>>>>> probably worth a comment, or for safety, they should be "s32" so
>>> it's
>>>>> not dependent on the bit-width of "int".
>>>>>
>>>>
>>>> For readability, perhaps we should make sign- and zero-extension an
>>>> explicit facility?
>>>
>>> There is some of this in already here, 32 and 64 bit versions:
>>>
>>>  include/linux/bitops.h
>>>
>>> Do we really need zero extension? It seems the same.
>>>
>>> Example implementation from bitops.h
>>>
>>> static inline __s32 sign_extend32(__u32 value, int index)
>>> {
>>>        __u8 shift = 31 - index;
>>>        return (__s32)(value << shift) >> shift;
>>> }
>>>
>>>> /*
>>>>  * Truncate an integer x to n bits, using sign- or
>>>>  * zero-extension, respectively.
>>>>  */
>>>> static inline __const_func__ s32 sex32(s32 x, int n)
>>>> {
>>>>   return (x << (32-n)) >> (32-n);
>>>> }
>>>>
>>>> static inline __const_func__ s64 sex64(s64 x, int n)
>>>> {
>>>>   return (x << (64-n)) >> (64-n);
>>>> }
>>>>
>>>> #define sex(x,y)						\
>>>> 	((__typeof__(x))					\
>>>> 	 (((__builtin_constant_p(y) && ((y) <= 32)) ||		\
>>>> 	   (sizeof(x) <= sizeof(s32)))				\
>>>> 	  ? sex32((x),(y)) : sex64((x),(y))))
>>>>
>>>> static inline __const_func__ u32 zex32(u32 x, int n)
>>>> {
>>>>   return (x << (32-n)) >> (32-n);
>>>> }
>>>>
>>>> static inline __const_func__ u64 zex64(u64 x, int n)
>>>> {
>>>>   return (x << (64-n)) >> (64-n);
>>>> }
>>>>
>>>> #define zex(x,y)						\
>>>> 	((__typeof__(x))					\
>>>> 	 (((__builtin_constant_p(y) && ((y) <= 32)) ||		\
>>>> 	   (sizeof(x) <= sizeof(u32)))				\
>>>> 	  ? zex32((x),(y)) : zex64((x),(y))))
>>>>
>>
>> Also, i strongly believe that making it syntactically cumbersome encodes people to open-code it which is bad...
> 
> Right, I missed the signed vs unsigned bit.

What about this?

commit 811c8c60ea83727e77f92117e3301a4f30a66e8c
Author: Jiri Slaby <jslaby@suse.cz>
Date:   Fri Nov 4 13:38:34 2016 +0100

    futex: make the encoded_op decoding readable

    Decoding of encoded_op is a bit unreadable. It contains shifts to the
    left and to the right by some constants. Make it clearly visible what
    part of the bit mask is taken and shift the values only to the right
    appropriately. And make sure sign extension takes place using
    sign_extend32.

    Signed-off-by: Jiri Slaby <jslaby@suse.cz>

diff --git a/kernel/futex.c b/kernel/futex.c
index 0ead0756a593..f90314bd42cb 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1461,10 +1461,10 @@ futex_wake(u32 __user *uaddr, unsigned int
flags, int nr_wake, u32 bitset)

 static int futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
 {
-       int op = (encoded_op >> 28) & 7;
-       int cmp = (encoded_op >> 24) & 15;
-       int oparg = (encoded_op << 8) >> 20;
-       int cmparg = (encoded_op << 20) >> 20;
+       int op =                  (encoded_op & 0x70000000) >> 28;
+       int cmp =                 (encoded_op & 0x0f000000) >> 24;
+       int oparg = sign_extend32((encoded_op & 0x00fff000) >> 12, 12);
+       int cmparg = sign_extend32(encoded_op & 0x00000fff, 12);
        int oldval, ret;

        if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28)) {

thanks,
-- 
js
suse labs

  reply	other threads:[~2017-03-06  8:47 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-03 12:27 [PATCH 1/3] futex: remove duplicated code Jiri Slaby
2017-03-03 12:27 ` [OpenRISC] " Jiri Slaby
2017-03-03 12:27 ` Jiri Slaby
2017-03-03 12:27 ` Jiri Slaby
2017-03-03 12:27 ` Jiri Slaby
2017-03-03 12:27 ` Jiri Slaby
2017-03-03 12:27 ` [PATCH 2/3] futex: fix decoding of operation Jiri Slaby
2017-03-03 12:27 ` [PATCH 3/3] futex: make the encoded_op decoding readable Jiri Slaby
2017-03-05  7:55   ` Jiri Slaby
2017-03-03 14:08 ` [PATCH 1/3] futex: remove duplicated code Heiko Carstens
2017-03-03 14:08   ` Heiko Carstens
2017-03-03 14:08   ` Heiko Carstens
2017-03-03 14:08   ` Heiko Carstens
2017-03-03 14:08   ` Heiko Carstens
2017-03-03 14:08   ` Heiko Carstens
2017-03-03 14:48 ` Chris Metcalf
2017-03-03 14:48   ` Chris Metcalf
2017-03-03 14:48   ` Chris Metcalf
2017-03-03 14:48   ` Chris Metcalf
2017-03-03 14:48   ` Chris Metcalf
2017-03-03 14:48   ` Chris Metcalf
2017-03-03 14:48   ` Chris Metcalf
2017-03-04 12:49 ` Michael Ellerman
2017-03-04 12:49   ` Michael Ellerman
2017-03-04 12:49   ` Michael Ellerman
2017-03-04 12:49   ` Michael Ellerman
2017-03-04 12:49   ` Michael Ellerman
2017-03-04 12:49   ` Michael Ellerman
2017-03-04 12:49   ` Michael Ellerman
2017-03-04 13:05 ` Russell King - ARM Linux
2017-03-04 13:05   ` Russell King - ARM Linux
2017-03-04 13:05   ` Russell King - ARM Linux
2017-03-04 13:05   ` Russell King - ARM Linux
2017-03-04 13:05   ` Russell King - ARM Linux
2017-03-04 13:05   ` Russell King - ARM Linux
2017-03-04 19:15   ` H. Peter Anvin
2017-03-04 19:15     ` H. Peter Anvin
2017-03-04 19:15     ` H. Peter Anvin
2017-03-04 19:15     ` H. Peter Anvin
2017-03-04 19:15     ` H. Peter Anvin
2017-03-04 19:15     ` H. Peter Anvin
2017-03-04 21:38     ` Stafford Horne
2017-03-04 21:38       ` [OpenRISC] " Stafford Horne
2017-03-04 21:38       ` Stafford Horne
2017-03-04 21:38       ` Stafford Horne
2017-03-04 21:38       ` Stafford Horne
2017-03-04 21:38       ` Stafford Horne
2017-03-04 21:38       ` Stafford Horne
2017-03-04 23:03       ` H. Peter Anvin
2017-03-04 23:03         ` H. Peter Anvin
2017-03-04 23:03         ` H. Peter Anvin
2017-03-04 23:03         ` H. Peter Anvin
2017-03-04 23:03       ` H. Peter Anvin
2017-03-04 23:03       ` H. Peter Anvin
2017-03-04 23:03       ` H. Peter Anvin
2017-03-04 23:03       ` H. Peter Anvin
2017-03-04 23:08       ` H. Peter Anvin
2017-03-04 23:08       ` H. Peter Anvin
2017-03-04 23:08       ` H. Peter Anvin
2017-03-04 23:08       ` H. Peter Anvin
2017-03-04 23:08         ` H. Peter Anvin
2017-03-04 23:08         ` H. Peter Anvin
2017-03-04 23:08         ` H. Peter Anvin
2017-03-04 23:39         ` Stafford Horne
2017-03-06  8:46           ` Jiri Slaby [this message]
2017-03-06  9:13             ` H. Peter Anvin
2017-03-06 14:14             ` Geert Uytterhoeven
2017-03-04 23:08       ` H. Peter Anvin
2017-03-09  4:16   ` Rob Landley
2017-03-09  4:16     ` Rob Landley
2017-03-09  4:16     ` Rob Landley
2017-03-09  4:16     ` Rob Landley
2017-03-09  4:16     ` Rob Landley
2017-03-09  4:36     ` H. Peter Anvin
2017-03-09  4:36     ` H. Peter Anvin
2017-03-09  4:36     ` H. Peter Anvin
2017-03-09  4:36     ` H. Peter Anvin
2017-03-09  4:36     ` H. Peter Anvin
2017-03-09  4:36       ` H. Peter Anvin
2017-03-09  4:36       ` H. Peter Anvin
2017-03-09  4:36       ` H. Peter Anvin
2017-03-09 22:37       ` Rich Felker
2017-03-06  1:52 ` Rich Felker
2017-03-06  1:52   ` Rich Felker
2017-03-06  1:52   ` Rich Felker
2017-03-06  1:52   ` Rich Felker
2017-03-06  1:52   ` Rich Felker
2017-03-06  1:52   ` Rich Felker
2017-03-09 22:43 ` Vineet Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3662dd60-2467-f858-dc32-0b0fb6abb33b@suse.cz \
    --to=jslaby@suse.cz \
    --cc=DavidS.Miller@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=dalias@libc.org \
    --cc=deller@gmx.de \
    --cc=fenghua.yu@intel.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=ink@jurassic.park.msu.ru \
    --cc=jejb@parisc-linux.org \
    --cc=jonas@southpole.se \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mattst88@gmail.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=ralf@linux-mips.org \
    --cc=rkuo@codeaurora.org \
    --cc=rth@twiddle.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=will.deacon@arm.com \
    --cc=ysato@users.sourceforge.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.