From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Kaehlcke Subject: Re: [PATCH] kvm: x86: mmu: Add cast to negated bitmasks in update_permission_bitmask() Date: Fri, 15 Jun 2018 11:29:45 -0700 Message-ID: <20180615182945.GN88063@google.com> References: <20180615174731.47588-1-mka@chromium.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Nick Desaulniers , pbonzini@redhat.com, rkrcmar@redhat.com, Thomas Gleixner , hpa@zytor.com, x86@kernel.org, kvm@vger.kernel.org, LKML To: Joe Perches Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Fri, Jun 15, 2018 at 11:18:12AM -0700, Joe Perches wrote: > On Fri, 2018-06-15 at 11:04 -0700, Nick Desaulniers wrote: > > On Fri, Jun 15, 2018 at 10:47 AM Matthias Kaehlcke wrote: > > > > > > update_permission_bitmask() negates u8 bitmask values and assigns them > > > to variables of type u8. Since the MSB is set in the bitmask values the > > > compiler expands the negated values to int, which then are assigned to > > > u8 variables. Cast the negated values back to u8. > > > > > > This fixes several warnings like this when building with clang: > > > > > > arch/x86/kvm/mmu.c:4266:39: error: implicit conversion from 'int' to 'u8' > > > (aka 'unsigned char') changes value from -205 to 51 [-Werror, > > > -Wconstant-conversion] > > > u8 wf = (pfec & PFERR_WRITE_MASK) ? ~w : 0; > > > ~~ ^~ > > > > > > (gcc also raises a warning (see https://godbolt.org/g/6JWfWk), however it > > > doesn't seem to be universally enabled) > > Perhaps it's better to turn off the warning. > There are more of these in the kernel too. > > At least: > drivers/regulator/max8660.c: u8 mask = (rdev_get_id(rdev) == MAX8660_V3) ? ~1 : ~4; > drivers/regulator/max8660.c: u8 mask = (rdev_get_id(rdev) == MAX8660_V6) ? ~2 : ~4; > fs/ext4/resize.c: __u16 uninit_mask = (flexbg_size > 1) ? ~EXT4_BG_BLOCK_UNINIT : ~0; In my experience neither clang nor gcc should promote these values to int, since the MSB/sign bit is not set. In any case I think it it preferable to fix the code over disabling the warning, unless the warning is bogus or there are just too many occurrences.