Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D185C64EC4 for ; Wed, 8 Mar 2023 18:50:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230207AbjCHSuO (ORCPT ); Wed, 8 Mar 2023 13:50:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230200AbjCHSuA (ORCPT ); Wed, 8 Mar 2023 13:50:00 -0500 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B3E2DC5AD6 for ; Wed, 8 Mar 2023 10:49:53 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id m8-20020a17090a4d8800b002377bced051so3467603pjh.0 for ; Wed, 08 Mar 2023 10:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678301393; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gDSGMnsH4iLzycmIWjYuFo4vdBUomtvXvRZ+aBAg2KM=; b=FzogeeILd8HnwKeT2ZvFT2CYiOLNldXbC1nJeLKihK+Huxaq+nYiDMwlLcnYK/EEDo kf2fTN+UR19AaMmOiyNMrdWHoNjxZbYJZRpVMep1Amx9brsHRlaldlqqkOd0aUQvK/Bi WBLM4B7YHznpL3mU3fxdcRh46KOMOtlYXzoxTumMdkHS55+95OpqQFJO5mitOu5hMOjA OqWLrRDNqNjAbzaAwo4x9B3ymuqbt0+l1h1F9d8iOuH8UWi6TyquaJJuxgTLMB4gorb3 qZrN5yi8fEEBhU2L91bYnb4cO2E+MCPDCJJ1R6IlUl5+h4FzBrLehLklDLE4Hk9+lJSn 8hdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678301393; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gDSGMnsH4iLzycmIWjYuFo4vdBUomtvXvRZ+aBAg2KM=; b=ROl1/BhFRE9PhTJNzDwdjmge+JP+lLPopqlNd1O0jyR3xdTdwURKpPQuFtp7otjb5y xAK2xVQ7L/3+ERDeCvwpmn9aofA8bmCyQeWVtZ+qg+rbEiUzR6cwEU7eIDfWz7lPjtik YAr4h3ciaR1JF/ATb52gZazyR9gXuMLo89CYKDJ6e6Nusy54x1Z6XgdvKXJ1JnYtmjil QIre4ysJKVBk2hCbmJvh/yqzjQVEaXOPChK5AlE+UhnnJCEVIdZ5QDdv2+JFTmDgY90J uCSq/xpvtvz11siwC4PhEzchsnFP9C0sgCdviN4DQBUzZomSmU5F/2Pzb7+jvmVKQNmu CseQ== X-Gm-Message-State: AO0yUKXNrGtBlRyKY/GWm2SILroww/oqAVZPGU+PzrgD/iZzFHalG/Cn RfrlLHKg46Fz20IdUnXBMaLb/qIxYKeQzwtDRCLPcg== X-Google-Smtp-Source: AK7set+nFVT3xiGjx+/Yc43iwIrku80Ndj0a/ne77ymYRpAbVEvBr3ZASV5TY0s6WbACCk+/DGqIYFBDKboF6fgit5I= X-Received: by 2002:a17:903:280f:b0:19e:f660:81ee with SMTP id kp15-20020a170903280f00b0019ef66081eemr1301893plb.2.1678301392881; Wed, 08 Mar 2023 10:49:52 -0800 (PST) MIME-Version: 1.0 References: <50a96bb9-113a-cb06-919c-f544f6b59493@intel.com> In-Reply-To: From: Nick Desaulniers Date: Wed, 8 Mar 2023 10:49:41 -0800 Message-ID: Subject: Re: selftests: sigaltstack: sas # exit=1 - # Bail out! SP is not on sigaltstack - on clang build To: Andy Lutomirski Cc: Naresh Kamboju , "Chang S. Bae" , llvm@lists.linux.dev, "open list:KERNEL SELFTEST FRAMEWORK" , linux-api@vger.kernel.org, open list , lkft-triage@lists.linaro.org, Shuah Khan , Thomas Gleixner , Len Brown , Borislav Petkov , Stas Sergeev , Arnd Bergmann , Anders Roxell , Nathan Chancellor , Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 8, 2023 at 8:23=E2=80=AFAM Andy Lutomirski wr= ote: > > On Tue, Mar 7, 2023 at 7:14=E2=80=AFPM Naresh Kamboju wrote: > > > > + LLVM > > The offending code seems to be: > > #if __s390x__ > register unsigned long sp asm("%15"); > #else > register unsigned long sp asm("sp"); > #endif > > if (sp < (unsigned long)sstack || > sp >=3D (unsigned long)sstack + stack_size) { > ksft_exit_fail_msg("SP is not on sigaltstack\n"); > } > > Is that actually expected to work? asm("sp") is a horrible hack. I > would, maybe naively, expect a compiler to analyze this code, think > "sp is unconditionally uninitialized", and treat the comparison as > always-UB and thus generate whatever code seems convenient. Spot-on. -Wuninitialized should warn about that. https://godbolt.org/z/do9Kqa3cG Kees mentioned we should be using `current_stack_pointer`. I'll whip up a patch using that. > > --Andy > > > > > On Wed, 8 Mar 2023 at 00:58, Chang S. Bae wr= ote: > > > > > > On 3/6/2023 10:57 PM, Naresh Kamboju wrote: > > > > kselftest: sigaltstack built with clang-16 getting failed but passe= d with > > > > gcc-12 build. Please find more details about test logs on clang-16 = and > > > > gcc-12 and steps to reproduce locally on your machine by using tuxr= un. > > > > > > > > Reported-by: Linux Kernel Functional Testing > > > > > > > > Test log: > > > > ---------- > > > > > > > > Linux version 6.3.0-rc1-next-20230307 (tuxmake@tuxmake) (Debian cla= ng > > > > version 16.0.0 (++20230228093516+60692a66ced6-1~exp1~20230228093525= .41), > > > > Debian LLD 16.0.0) #1 SMP PREEMPT @1678159722 > > > > ... > > > > kselftest: Running tests in sigaltstack > > > > TAP version 13 > > > > 1..1 > > > > # selftests: sigaltstack: sas > > > > # # [NOTE] the stack size is 21104 > > > > # TAP version 13 > > > > # 1..3 > > > > # ok 1 Initial sigaltstack state was SS_DISABLE > > > > # Bail out! SP is not on sigaltstack > > > > # # Planned tests !=3D run tests (3 !=3D 1) > > > > # # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 > > > > not ok 1 selftests: sigaltstack: sas # exit=3D1 > > > > > > > > > > Linux version 6.3.0-rc1-next-20230307 (tuxmake@tuxmake) > > > > (aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binut= ils > > > > for Debian) 2.40) #1 SMP PREEMPT @1678159736 > > > > ... > > > > kselftest: Running tests in sigaltstack > > > > TAP version 13 > > > > 1..1 > > > > # selftests: sigaltstack: sas > > > > # # [NOTE] the stack size is 50080 > > > > # TAP version 13 > > > > # 1..3 > > > > # ok 1 Initial sigaltstack state was SS_DISABLE > > > > # # [RUN] signal USR1 > > > > # ok 2 sigaltstack is disabled in sighandler > > > > # # [RUN] switched to user ctx > > > > # # [RUN] signal USR2 > > > > # # [OK] Stack preserved > > > > # ok 3 sigaltstack is still SS_AUTODISARM after signal > > > > # # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 > > > > ok 1 selftests: sigaltstack: sas > > > > > > At glance, the log shows the altstack size difference between LLVM an= d GCC. > > > > > > But, when I tried with the LLVM that I have, > > > > > > $ clang --version > > > clang version 13.0.0 ... > > > > > > it failed only with this compiler: > > > > > > $ rm sas;clang -o sas sas.c;./sas > > > # [NOTE] the stack size is 8192 > > > TAP version 13 > > > 1..3 > > > ok 1 Initial sigaltstack state was SS_DISABLE > > > Bail out! SP is not on sigaltstack > > > # Planned tests !=3D run tests (3 !=3D 1) > > > # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 > > > > > > $ rm sas;gcc -o sas sas.c;./sas > > > # [NOTE] the stack size is 8192 > > > TAP version 13 > > > 1..3 > > > ok 1 Initial sigaltstack state was SS_DISABLE > > > # [RUN] signal USR1 > > > ok 2 sigaltstack is disabled in sighandler > > > # [RUN] switched to user ctx > > > # [RUN] signal USR2 > > > # [OK] Stack preserved > > > ok 3 sigaltstack is still SS_AUTODISARM after signal > > > # Totals: pass:3 fail:0 xfail:0 xpass:0 skip:0 error:0 > > > > > > The same is true with some old versions -- e.g. the one that came wit= h > > > commit 0c49ad415512 ("tools/testing/selftests/sigaltstack/sas.c: impr= ove > > > output of sigaltstack testcase"): > > > > > > $ rm sas;clang -o sas sas.c;./sas > > > [OK] Initial sigaltstack state was SS_DISABLE > > > [FAIL] SP is not on sigaltstack > > > > > > $ rm sas;gcc -o sas sas.c;./sas > > > [OK] Initial sigaltstack state was SS_DISABLE > > > [RUN] signal USR1 > > > [OK] sigaltstack is disabled in sighandler > > > [RUN] switched to user ctx > > > [RUN] signal USR2 > > > [OK] Stack preserved > > > [OK] sigaltstack is still SS_AUTODISARM after signal > > > [OK] Test passed > > > > > > So, this test failure appears to have been there for a while. I think > > > the LLVM folks need to take a look at it. > > > > > > Thanks, > > > Chang > --=20 Thanks, ~Nick Desaulniers