From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937996AbdJRKky (ORCPT ); Wed, 18 Oct 2017 06:40:54 -0400 Received: from mail-io0-f178.google.com ([209.85.223.178]:44073 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932918AbdJRKkt (ORCPT ); Wed, 18 Oct 2017 06:40:49 -0400 X-Google-Smtp-Source: AOwi7QBaqFXKTem6FnlQCGw9XyOkB3oOvhLpigMvawOsR3Bjpp0JeY+9QXAaw2XvlTPDcMCHb4NNwYtUqRQ6APInZv8= MIME-Version: 1.0 In-Reply-To: <20171017073326.GA23865@js1304-P5Q-DELUXE> References: <20171010121513.GC5445@yexl-desktop> <20171011023106.izaulhwjcoam55jt@treble> <20171011170120.7flnk6r77dords7a@treble> <20171017073326.GA23865@js1304-P5Q-DELUXE> From: Linus Torvalds Date: Wed, 18 Oct 2017 06:40:48 -0400 X-Google-Sender-Auth: r7GpM79vBCYK6aI0D1x1RRjzowU Message-ID: Subject: Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel To: Joonsoo Kim Cc: Josh Poimboeuf , kernel test robot , Ingo Molnar , Andy Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Jiri Slaby , Mike Galbraith , Peter Zijlstra , Thomas Gleixner , LKML , LKP , linux-mm , Pekka Enberg , David Rientjes , Andrew Morton , Christoph Lameter Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 17, 2017 at 3:33 AM, Joonsoo Kim wrote: > > It looks like a compiler bug. The code of slob_units() try to read two > bytes at ffff88001c4afffe. It's valid. But the compiler generates > wrong code that try to read four bytes. > > static slobidx_t slob_units(slob_t *s) > { > if (s->units > 0) > return s->units; > return 1; > } > > s->units is defined as two bytes in this setup. > > Wrongly generated code for this part. > > 'mov 0x0(%rbp), %ebp' > > %ebp is four bytes. > > I guess that this wrong four bytes read cross over the valid memory > boundary and this issue happend. Hmm. I can see why the compiler would do that (16-bit accesses are slow), but it's definitely wrong. Does it work ok if that slob_units() code is written as static slobidx_t slob_units(slob_t *s) { int units = READ_ONCE(s->units); if (units > 0) return units; return 1; } which might be an acceptable workaround for now? Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f199.google.com (mail-io0-f199.google.com [209.85.223.199]) by kanga.kvack.org (Postfix) with ESMTP id B66D66B0033 for ; Wed, 18 Oct 2017 06:40:50 -0400 (EDT) Received: by mail-io0-f199.google.com with SMTP id 101so4445732ioj.6 for ; Wed, 18 Oct 2017 03:40:50 -0700 (PDT) Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id g35sor5297681iod.292.2017.10.18.03.40.49 for (Google Transport Security); Wed, 18 Oct 2017 03:40:49 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20171017073326.GA23865@js1304-P5Q-DELUXE> References: <20171010121513.GC5445@yexl-desktop> <20171011023106.izaulhwjcoam55jt@treble> <20171011170120.7flnk6r77dords7a@treble> <20171017073326.GA23865@js1304-P5Q-DELUXE> From: Linus Torvalds Date: Wed, 18 Oct 2017 06:40:48 -0400 Message-ID: Subject: Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: Josh Poimboeuf , kernel test robot , Ingo Molnar , Andy Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Jiri Slaby , Mike Galbraith , Peter Zijlstra , Thomas Gleixner , LKML , LKP , linux-mm , Pekka Enberg , David Rientjes , Andrew Morton , Christoph Lameter On Tue, Oct 17, 2017 at 3:33 AM, Joonsoo Kim wrote: > > It looks like a compiler bug. The code of slob_units() try to read two > bytes at ffff88001c4afffe. It's valid. But the compiler generates > wrong code that try to read four bytes. > > static slobidx_t slob_units(slob_t *s) > { > if (s->units > 0) > return s->units; > return 1; > } > > s->units is defined as two bytes in this setup. > > Wrongly generated code for this part. > > 'mov 0x0(%rbp), %ebp' > > %ebp is four bytes. > > I guess that this wrong four bytes read cross over the valid memory > boundary and this issue happend. Hmm. I can see why the compiler would do that (16-bit accesses are slow), but it's definitely wrong. Does it work ok if that slob_units() code is written as static slobidx_t slob_units(slob_t *s) { int units = READ_ONCE(s->units); if (units > 0) return units; return 1; } which might be an acceptable workaround for now? Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4748283813969534496==" MIME-Version: 1.0 From: Linus Torvalds To: lkp@lists.01.org Subject: Re: [lkp-robot] [x86/kconfig] 81d3871900: BUG:unable_to_handle_kernel Date: Wed, 18 Oct 2017 06:40:48 -0400 Message-ID: In-Reply-To: <20171017073326.GA23865@js1304-P5Q-DELUXE> List-Id: --===============4748283813969534496== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2017 at 3:33 AM, Joonsoo Kim wro= te: > > It looks like a compiler bug. The code of slob_units() try to read two > bytes at ffff88001c4afffe. It's valid. But the compiler generates > wrong code that try to read four bytes. > > static slobidx_t slob_units(slob_t *s) > { > if (s->units > 0) > return s->units; > return 1; > } > > s->units is defined as two bytes in this setup. > > Wrongly generated code for this part. > > 'mov 0x0(%rbp), %ebp' > > %ebp is four bytes. > > I guess that this wrong four bytes read cross over the valid memory > boundary and this issue happend. Hmm. I can see why the compiler would do that (16-bit accesses are slow), but it's definitely wrong. Does it work ok if that slob_units() code is written as static slobidx_t slob_units(slob_t *s) { int units =3D READ_ONCE(s->units); if (units > 0) return units; return 1; } which might be an acceptable workaround for now? Linus --===============4748283813969534496==--