Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934254AbdHYVOB (ORCPT ); Fri, 25 Aug 2017 17:14:01 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:42750 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932374AbdHYVOA (ORCPT ); Fri, 25 Aug 2017 17:14:00 -0400 Date: Fri, 25 Aug 2017 23:13:47 +0200 (CEST) From: Thomas Gleixner To: zhong jiang cc: Ingo Molnar , akpm@linux-foundation.org, mingo@redhat.com, minchan@kernel.org, mhocko@suse.com, hpa@zytor.com, x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhen Lei Subject: Re: [PATCH] futex: avoid undefined behaviour when shift exponent is negative In-Reply-To: <599FB3C4.6000009@huawei.com> Message-ID: References: <1498045437-7675-1-git-send-email-zhongjiang@huawei.com> <20170621164036.4findvvz7jj4cvqo@gmail.com> <595331FE.3090700@huawei.com> <599FB3C4.6000009@huawei.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 987 Lines: 26 On Fri, 25 Aug 2017, zhong jiang wrote: > From: zhong jiang > Date: Fri, 25 Aug 2017 12:05:56 +0800 > Subject: [PATCH v2] futex: avoid undefined behaviour when shift exponent is > negative Please do not send patches without changing the subject line so it's clear that there is a new patch. > using a shift value < 0 or > 31 will get crap as a result. because > it's just undefined. The issue still disturb me, so I try to fix > it again by excluding the especially condition. Which is obsolete now as this code is unified accross all architectures and the shift issue is addressed in the generic version of it. So all architectures get the same fix. See: http://git.kernel.org/tip/30d6e0a4190d37740e9447e4e4815f06992dd8c3 And no, we won't add that x86 fix before that unification hits mainline because that undefined behaviour is harmless as it only affects the user space value of the futex. IOW, the caller gets what it asked for: crap. Thanks, tglx