Received: by 10.223.185.116 with SMTP id b49csp4024566wrg; Mon, 26 Feb 2018 09:51:48 -0800 (PST) X-Google-Smtp-Source: AH8x225ta822g2pajpy3INMt1+A8c+NTkPW8zzjwxYN/1+igokCY/UDxFULEYGBRo36Izddf3xz1 X-Received: by 10.101.97.139 with SMTP id c11mr9048810pgv.433.1519667507979; Mon, 26 Feb 2018 09:51:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519667507; cv=none; d=google.com; s=arc-20160816; b=F/985bV4oFAQAxwlHBtu5bWL7HUWULx3doO4WrWvwtLnz3vJjhkSK0JJ0MmoB6KeCs WqkMaUfDb9Dw+pW3zK0Rt0SEtIFaV81GcdBAis2JfAFMD+sILJmjDtov1IuKtWeu4rSa rtzpPdARB/9PiWi0pwTD231JudQ+UmNzkLqGh3RftL58DlQg83a18dRejO3nyQat6xBE t5UD70Olq7hkxn/efyeIvuPsTEIg/FNRDdDJvpGu2kJFFCShhTVWXUKE2F0qoFmAnVQz m068OS+8NMtv8BOP7gOjaWL5WWFybqQm/ANCB8ixjBFMNEx8A24plc/4WMsoF7ZaUznP NL5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=mRQ5AAROwRmNXsMv0IgghoXlSHhsZUKHvmNGk7XCjfk=; b=M0BbjRpWvdzPoy6VT6QqzNvNz60ahxlT/Bxc9VFSpkEilWFfk6/lhTh4gyyaGQ/7ul VdRx4PYgfVnfsnOyQPg41RgAp6AHJILmq/LkAmVWRQjXdV6QtYuxiuYkU2DTC8InK/1I r7336Aj2+HToEN7e6bpam2pDfmwfnWaFRIsWatHIAmuy5TAhRdL4rnkZ1FO6BRK30RIR oVdRhanHm50IlcBr0nwkA/WAMtevgdypOrIVjvWMYeyDXFed8Wa4z7CjXsZLn1VLtJn8 O7j0VOCvjuGzwJBtRu1rawTyzDbrBPxrYoGOSopXQ0DNL3dWD80fKth4eDiYmYrBJd3v iX3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=TqB81Qbz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z2-v6si5779565pll.382.2018.02.26.09.51.31; Mon, 26 Feb 2018 09:51:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=TqB81Qbz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751582AbeBZRue (ORCPT + 99 others); Mon, 26 Feb 2018 12:50:34 -0500 Received: from mail-vk0-f68.google.com ([209.85.213.68]:35953 "EHLO mail-vk0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbeBZRud (ORCPT ); Mon, 26 Feb 2018 12:50:33 -0500 Received: by mail-vk0-f68.google.com with SMTP id q7so10419804vkh.3 for ; Mon, 26 Feb 2018 09:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=mRQ5AAROwRmNXsMv0IgghoXlSHhsZUKHvmNGk7XCjfk=; b=TqB81Qbz/t+qW1OkY1h1lMqGL0WAkyEow5fE48g/dNgwSUYRjSGB5eiMsAjxR39l9V r03RgJkI6j8nQ/TaBNIY1mjdvJvLlL+0NIbcT2S96rA9X6avzGidHO0IDlr+8n7Qfeoi 2udx9fJmVMiVO5TGZ43epPvLR6LhdchLtob8ZC+PnmD5rzRkbgcef/4o1JQWWnt9DvXn E85/+LtMTcQnK0vJtns+1n0lnoP3FFA/xib7W5MuIH3WyT2XXXSPHmDqaOAa1jNPXWJ6 /MZjBrIlXA9CEXwQgjhsznW/RWOn+urE+WcSXB0BaFvSG6UYWOFHZBJ49KnvVfTWr0UD fxWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=mRQ5AAROwRmNXsMv0IgghoXlSHhsZUKHvmNGk7XCjfk=; b=hanmxPYH9g2b3SVxM5tV5q4jrlLOTFiwhx7dFpEOt5SJkz7uxIXLS1W39WL5BaMoJI IlXz325rxhSVbMWRZBgKB4Tjv0WdSXRezqAhcwW4n/KPQeD4WPjuDhFbyTet9azGRFFu vjZZcR/8gkXl1Bh2Gi8wPKsyLwMNdkXUaE+VlCXZQ5YZl/YfEqAf962Fs6TUx+MbleAz ttP8x47XjIxVodLH6ukZEKxjex46gVHCwBbrFoqYgPwA1HE4xG1ToA3sCAzJx1X3vsMO SIi2MBSX0+n69JHZ4gQv8Vh5mSjLdwANbqB4CcVaHAnD09n2CNAiIzcd62Gc+2B6adVX 0/Yw== X-Gm-Message-State: APf1xPDGj7oOkmzeguiUvqRryMZ9N3NbqsGjTw7FHwmFsum+uh8DsWg4 hKwKPpOqYbRrzAjkUpxFfNVeGl/oHG3UsoE/IA4= X-Received: by 10.31.178.69 with SMTP id b66mr5669020vkf.145.1519667432074; Mon, 26 Feb 2018 09:50:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.112.21 with HTTP; Mon, 26 Feb 2018 09:50:11 -0800 (PST) In-Reply-To: References: <20180225172236.29650-1-malat@debian.org> <20180225172236.29650-7-malat@debian.org> <8862c1e1-d161-3410-1b2a-502ad06cef57@c-s.fr> <6cba215c-127e-f3eb-b525-773b6aed0eb7@c-s.fr> From: Mathieu Malaterre Date: Mon, 26 Feb 2018 18:50:11 +0100 X-Google-Sender-Auth: o1fSPYWGg_5ZZsiYprS_6JompWI Message-ID: Subject: Re: [PATCH 06/21] powerpc: Avoid comparison of unsigned long >= 0 in __access_ok To: Christophe LEROY Cc: Michael Ellerman , LKML , Paul Mackerras , Jiri Slaby , linuxppc-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 26, 2018 at 8:44 AM, Mathieu Malaterre wrote= : > On Mon, Feb 26, 2018 at 7:50 AM, Christophe LEROY > wrote: >> >> >> Le 26/02/2018 =C3=A0 07:34, Christophe LEROY a =C3=A9crit : >>> >>> >>> >>> Le 25/02/2018 =C3=A0 18:22, Mathieu Malaterre a =C3=A9crit : >>>> >>>> Rewrite check size - 1 <=3D Y as size < Y since `size` is unsigned val= ue. >>>> Fix warning (treated as error in W=3D1): >>>> >>>> CC arch/powerpc/kernel/signal_32.o >>>> In file included from ./include/linux/uaccess.h:14:0, >>>> from ./include/asm-generic/termios-base.h:8, >>>> from ./arch/powerpc/include/asm/termios.h:20, >>>> from ./include/uapi/linux/termios.h:6, >>>> from ./include/linux/tty.h:7, >>>> from arch/powerpc/kernel/signal_32.c:36: >>>> ./include/asm-generic/termios-base.h: In function >>>> =E2=80=98user_termio_to_kernel_termios=E2=80=99: >>>> ./arch/powerpc/include/asm/uaccess.h:52:35: error: comparison of unsig= ned >>>> expression >=3D 0 is always true [-Werror=3Dtype-limits] >>>> (((size) =3D=3D 0) || (((size) - 1) <=3D ((segment).seg - (addr)))= )) >>>> ^ >>>> ./arch/powerpc/include/asm/uaccess.h:58:3: note: in expansion of macro >>>> =E2=80=98__access_ok=E2=80=99 >>>> __access_ok((__force unsigned long)(addr), (size), get_fs())) >>>> ^~~~~~~~~~~ >>>> ./arch/powerpc/include/asm/uaccess.h:262:6: note: in expansion of macr= o >>>> =E2=80=98access_ok=E2=80=99 >>>> if (access_ok(VERIFY_READ, __gu_addr, (size))) \ >>>> ^~~~~~~~~ >>>> ./arch/powerpc/include/asm/uaccess.h:80:2: note: in expansion of macro >>>> =E2=80=98__get_user_check=E2=80=99 >>>> __get_user_check((x), (ptr), sizeof(*(ptr))) >>>> ^~~~~~~~~~~~~~~~ >>>> ./include/asm-generic/termios-base.h:36:6: note: in expansion of macro >>>> =E2=80=98get_user=E2=80=99 >>>> if (get_user(termios->c_line, &termio->c_line) < 0) >>>> ^~~~~~~~ >>>> [...] >>>> cc1: all warnings being treated as errors >>>> >>>> Signed-off-by: Mathieu Malaterre >>>> --- >>>> arch/powerpc/include/asm/uaccess.h | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/arch/powerpc/include/asm/uaccess.h >>>> b/arch/powerpc/include/asm/uaccess.h >>>> index 51bfeb8777f0..fadc406bd39d 100644 >>>> --- a/arch/powerpc/include/asm/uaccess.h >>>> +++ b/arch/powerpc/include/asm/uaccess.h >>>> @@ -49,7 +49,7 @@ >>>> #define __access_ok(addr, size, segment) \ >>>> (((addr) <=3D (segment).seg) && \ >>>> - (((size) =3D=3D 0) || (((size) - 1) <=3D ((segment).seg - (addr)= )))) >>>> + (((size) =3D=3D 0) || ((size) < ((segment).seg - (addr))))) >>> >>> >>> IIUC, ((2 - 1) <=3D 1) is the same as (2 < 1) ????? >> > > The whole series was pretty mediocre, but this one was actually pretty > destructive. Thanks for catching this. > >> >> Note that I already try to submit a fix for this warning 3 years ago >> (https://patchwork.ozlabs.org/patch/418075/) and it was rejected with th= e >> following comment: Tested again today with gcc 6.3.0 and gcc is still producing the original warning (treated as error). >> Again, I don't think Linux enables this warning. What did you do to >> produce this? In any case, it's a bad warning that doesn't take macros >> into account, and the answer is not to make the code less clear by hidin= g >> the fact that zero is a special case. > > Right. I'll try to see how to make W=3D1 run without error with an > alternate solution. So the other alternative is to update a bunch of ppc32 defconfig(s) with: CONFIG_PPC_DISABLE_WERROR=3Dy. Would that be preferable ? >> Christophe >> >> >>> >>> Christophe >>> >>>> #endif >>>> >>