From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACAF8143C59 for ; Thu, 18 Jul 2024 16:14:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721319288; cv=none; b=HMJMHNo2UH4y3riIxHGM9rHCMoAdMCYBMtBaXAcBlEwLH++JruaRaoQ+Hq/Lr2SuOijSf4oGsKuODM9Nu8oEiLn6Nfpo7KMvQYoQwzycvGO1sF9bi9s4QfUyHyy0XNVWd3gw5TUi92DWihOKpd/4FuH70vLBFNKd5pfVybaf2I8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1721319288; c=relaxed/simple; bh=Igl5C4XQG84DDkmNlndYaVvzyi1zpEMAcWa5IkHXl5o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=cqjbAFD38AnS6ovsO3nphHATPgtSOuYmXbjjXl5U7Ta9GqSZJFvqFc1jMxJvCfJPeThiVDINgzWmP/3mRpW0vEuTmKNXxqm82uQ0Jng6sSZzdKEkB1uBcxN5Ob0CyohRIkZ7vRV1H9PnT97nepA9eqpYzu7/bKIqIm3wz6uF1t8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=hSX69WVF; arc=none smtp.client-ip=209.85.166.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="hSX69WVF" Received: by mail-io1-f49.google.com with SMTP id ca18e2360f4ac-7f97e794f34so37297139f.3 for ; Thu, 18 Jul 2024 09:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1721319285; x=1721924085; darn=lists.linux.dev; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=hSX69WVFXkqBimkb0eGvBuPqE2g+gM1sKu1cDk2fg/Q1+le0wziGVbmpd765nR0+RM Xo10AtfubBj4cCQR+1KISw05gOniRrTwFHallOLQJQgZtsi4AfwnwSObh8EhcSd65rRg Ti+k0H7snlBJJu3f9MUF1VVY6q4AAo6l9u6Wy3N8ouIp0GuypMCqjGM3hBjU13J+6T7N CfF9LpUTY0xaye2b41Cp83iOcqPXejJlw1Rs+Mblx0tFVyrrQParfnmCZP/FIwxkQaRP ttF0sTcl8LIeKJzuqc4EyrOqzvEGyp99lILmnpHV2/0z1FiURMQkfGiBFGOJZ1P5ZrUE ET3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721319285; x=1721924085; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=JCcQW/HrntUqbzakI4ZbxSbDi1BIohOOFqycbj3u3gQ0jZgFW8fzprnQ6J6B5kfngw MOWIApMIZHmooBcCuNVJtYGcWx52MHLcYcTLHZciZ7jxnFp8uIN5gT5yWwTZWCZiVM3i slrGqq0qK60sz5cJdUKp0QcnzQsnkWZZWq8PSIYxK6rOsPHH3314vuOytmvR0x73pEKq JnKtNsaEz8OoXpoC7jgsefp0Hge4Za4/pPZI/aoiCAOE4BKsCjuBOWMxgXdW2NWl/aDY quOo3x8R3hZwGcgWVWHQa4zAd/5zGWurvxjc9a/m2hvAeNDOIY1XERukzQ8YHfzMqfTT 5fjQ== X-Forwarded-Encrypted: i=1; AJvYcCVt6CSiNLfvkNBkoS6lfuNgnJScGgB3eGtSxJNFaI9FF7dz9yR+n3kzJfkagwIi8bDo/oMdU6xruhPJg5so+62cjarnwEa3 X-Gm-Message-State: AOJu0YyygkgqLUbPPuXM3JIiBE20bXLBjZ2zni/TBRFddOThfO50K91S aBN06rwhIEw84wmofYQNvlC2vKBYXmfjdxDAPGxG9cLOluWG8OR6/9D5WYPN4Js= X-Google-Smtp-Source: AGHT+IGBl5SUOSetZ7hpvAsBcsY+3Cb2iftUEXypwidAC9j+tfeb4FVk4PWmNhC4HY+kt6K5hLBh4A== X-Received: by 2002:a05:6602:3fcc:b0:804:657d:92fc with SMTP id ca18e2360f4ac-817123e1bb4mr642950839f.18.1721319284795; Thu, 18 Jul 2024 09:14:44 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:49aa:ec5c:43c8:2afb]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-78e34d2c7e2sm7993415a12.54.2024.07.18.09.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jul 2024 09:14:44 -0700 (PDT) From: Thiago Jung Bauermann To: Mark Brown Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v9 35/39] kselftest/arm64: Add a GCS test program built with the system libc In-Reply-To: <20240625-arm64-gcs-v9-35-0f634469b8f0@kernel.org> (Mark Brown's message of "Tue, 25 Jun 2024 15:58:03 +0100") References: <20240625-arm64-gcs-v9-0-0f634469b8f0@kernel.org> <20240625-arm64-gcs-v9-35-0f634469b8f0@kernel.org> Date: Thu, 18 Jul 2024 13:14:41 -0300 Message-ID: <87plray8we.fsf@linaro.org> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Mark Brown writes: > There are things like threads which nolibc struggles with which we want > to add coverage for, and the ABI allows us to test most of these even if > libc itself does not understand GCS so add a test application built > using the system libc. > > Reviewed-by: Thiago Jung Bauermann > Signed-off-by: Mark Brown > --- > tools/testing/selftests/arm64/gcs/.gitignore | 1 + > tools/testing/selftests/arm64/gcs/Makefile | 4 +- > tools/testing/selftests/arm64/gcs/gcs-util.h | 10 + > tools/testing/selftests/arm64/gcs/libc-gcs.c | 736 +++++++++++++++++++++++++++ > 4 files changed, 750 insertions(+), 1 deletion(-) In my FVP VM, this test gets a GCS SIGSEGV before running the first test: $ sudo ./run_kselftest.sh -t arm64:libc-gcs [sudo] password for bauermann: TAP version 13 1..1 # timeout set to 45 # selftests: arm64: libc-gcs # TAP version 13 # 1..118 # # Starting 118 tests from 32 test cases. # # RUN global.can_call_function ... # Segmentation fault not ok 1 selftests: arm64: libc-gcs # exit=139 $ It happens when returning from the syscall() glibc function that does the clone3 syscall in kselftest_harness.h: $ /var/tmp/gdb-gcs/bin/gdb -q arm64/libc-gcs Reading symbols from arm64/libc-gcs... (gdb) r Starting program: /var/tmp/selftests-v9/arm64/libc-gcs [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". TAP version 13 1..118 # Starting 118 tests from 32 test cases. # RUN global.can_call_function ... [Detaching after vfork from child process 823] Program received signal SIGSEGV, Segmentation fault Guarded Control Stack error. syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:41 [GCS error] warning: 41 ../sysdeps/unix/sysv/linux/aarch64/syscall.S: No such file or directory (gdb) p $_siginfo.si_signo $1 = 11 (gdb) p $_siginfo.si_code $2 = 10 (gdb) p $_siginfo._sifields._sigfault.si_addr $3 = (void *) 0xfffff7ed96b0 (gdb) disassemble Dump of assembler code for function syscall: 0x0000fffff7ed9680 <+0>: nop 0x0000fffff7ed9684 <+4>: mov w8, w0 0x0000fffff7ed9688 <+8>: mov x0, x1 0x0000fffff7ed968c <+12>: mov x1, x2 0x0000fffff7ed9690 <+16>: mov x2, x3 0x0000fffff7ed9694 <+20>: mov x3, x4 0x0000fffff7ed9698 <+24>: mov x4, x5 0x0000fffff7ed969c <+28>: mov x5, x6 0x0000fffff7ed96a0 <+32>: mov x6, x7 0x0000fffff7ed96a4 <+36>: svc #0x0 0x0000fffff7ed96a8 <+40>: cmn x0, #0xfff 0x0000fffff7ed96ac <+44>: b.cs 0xfffff7ed96b4 // b.hs, b.nlast => 0x0000fffff7ed96b0 <+48>: ret 0x0000fffff7ed96b4 <+52>: b 0xfffff7e18660 <__GI___syscall_error> 0x0000fffff7ed96b8 <+56>: b 0xfffff7e18660 <__GI___syscall_error> End of assembler dump. (gdb) bt #0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:41 [GCS error] #1 0x0000aaaaaaaa4acc in clone3_vfork () at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:93 #2 __run_test (f=f@entry=0xaaaaaaac0b88 <_fixture_global>, variant=variant@entry=0xffffffffee00, t=t@entry=0xaaaaaaac0018 <_can_call_function_object>) at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:1239 [GCS error] #3 0x0000aaaaaaaa2c40 in test_harness_run (argv=0xfffffffff008, argc=1) at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:1314 #4 main (argc=1, argv=0xfffffffff008) at libc-gcs.c:735 [GCS error] (gdb) And indeed, the svc call in the disassemble above corrupts the GCS. This is the GCS and lr values right before the svc call: (gdb) x/i $pc => 0xfffff7ed96a4 : svc #0x0 (gdb) p/x $lr $3 = 0xaaaaaaaa4acc (gdb) p/x $gcspr $4 = 0xfffff7bfffe8 (gdb) x/g $gcspr 0xfffff7bfffe8: 0x0000aaaaaaaa4acc So far so good, the tip of the GCS matches $lr. But then: (gdb) stepi [Detaching after vfork from child process 2491] 39 in ../sysdeps/unix/sysv/linux/aarch64/syscall.S (gdb) x/i $pc => 0xfffff7ed96a8 : cmn x0, #0xfff (gdb) p/x $gcspr $5 = 0xfffff7bfffe8 (gdb) x/g $gcspr 0xfffff7bfffe8: 0x0000aaaaaaaa4c04 (gdb) p/x $lr $6 = 0xaaaaaaaa4acc So, right after svc returns, the tip of the GCS is corrupted and will cause the GCS error. -- Thiago From mboxrd@z Thu Jan 1 00:00:00 1970 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 86074C3DA49 for ; Thu, 18 Jul 2024 16:14:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GpHlL4lQqYhsAJKHRO+GnYuI6KwOjlOIgzHoz3xspxY=; b=rxrjw6rXls4VxE vVLlI5lPKpIin0EgF4OGKmTSmH9rr19C7fEDYU9Sr4YJNHfbx9l8TYUPZxXOEydfutfE5st+RQdvF Lpk5Cf95YNGwDbA+STs8vRI77VqtDUcGF53G33wU+YKsURGSM+Wyl19Y4D4cOpqkEYva2c2AizgFc goHsXwVnGNzIb+b8t/cu9Q45qvI76io48tDyb1mW98GKmKf1l1V62AktjYCj7nqkXmgHx0hGr78Yk XAcRNwXu4qHEa83ZrLO5nn09GSsVt7XsxV+W8VsApTPxvSsPanl9BKLEsIC23NF2jQfRjcAA7Xzq8 k9G2/VR6tSXpTyhMILVA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUTmM-0000000HY0m-1S1B; Thu, 18 Jul 2024 16:14:50 +0000 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sUTmI-0000000HXzy-2jOP for linux-riscv@lists.infradead.org; Thu, 18 Jul 2024 16:14:48 +0000 Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-7f97e794f34so37297039f.3 for ; Thu, 18 Jul 2024 09:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1721319285; x=1721924085; darn=lists.infradead.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=YGTeyyHil/vS7xOYHGXaITKXBfrOMLNEUzAXL2pOPfOSIPo5RUGkVV+5iuHCoQ9Igk 9j3Z0tgxiflkpu+BXiEeyP/afqJeKiBuNu1TOAju1qoX51G29WeWxLRRNwQogiQOhHv5 RvZY1cp9OOc3tHdGVpUI8LSQUP80JLQrSDPetqt9YgdKrU4n2m2CRrFlNJHh4rMrC3Rs VIL1L77aV8dmZNC52kExZ/vWzDcWpMHYe2uqoK1ME90OK90luYUEBhCDVEg7hbR35SEj pOY7A5qAnTPGtSAztQUJKFcHGz5FVDdeRGkTdPDKXwaQhRUqIAdqF9MXkmp1fcduaVKG XMxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721319285; x=1721924085; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cKUm2Sno0VCM0sKj4rcn5Z8Kw9gJMdGTQrF0ZDE8JgQ=; b=t5PUVzQHYOP3C3vfFd9a9FZ1NZE95jdNq+0FyzB8bEs/3qJVasxMKOP24rWT+3GXpE /ccdGVSx8/5h6Z88LT4jD5o5BoW16lQgxqSMrAYXQUg93zqR2Zqlk15iMKbc/AKmNFSj tKEx1xl2eeJur0HJ+pOYYsYWlGDOcoLEMaIRIF3DdANY/qGSMq+xC74ZYTq2GYmbGyC7 EZy1qE/tMGvPFvZZR3to91kUQIhta6jhknrxXrLV8YeYNTdD9pk/v2/59O4JmSS9ZbkA 40sJKwlkrQYXNACtfjfraj2GV+7Pfx167zngIqmvGBJX6lfjQ8DdOTC6hhFmT8GhqZJd 667Q== X-Forwarded-Encrypted: i=1; AJvYcCUmk9whMCOGGh2We//eT7ll9RbDiDnV4lAtOsqn2QoBu+e5bc41danVDOLEdMZ59XFhnBotTEAKVSnN+ipaMSlOY3NuVoxO/d+UOm8SsFxA X-Gm-Message-State: AOJu0YwlrtGtrVp7DQdfAKPcJ7XtxIEsTqRPfMLK63PshP7EMiK7FR1a 9o/Vs0WhwRxxix+fah/UeP+ytKNDTtoX4HlAwajX2gDoK+DIqb9+whZC/VRAErY7c/6gvDuD6rD j0DM= X-Google-Smtp-Source: AGHT+IGBl5SUOSetZ7hpvAsBcsY+3Cb2iftUEXypwidAC9j+tfeb4FVk4PWmNhC4HY+kt6K5hLBh4A== X-Received: by 2002:a05:6602:3fcc:b0:804:657d:92fc with SMTP id ca18e2360f4ac-817123e1bb4mr642950839f.18.1721319284795; Thu, 18 Jul 2024 09:14:44 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:49aa:ec5c:43c8:2afb]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-78e34d2c7e2sm7993415a12.54.2024.07.18.09.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jul 2024 09:14:44 -0700 (PDT) From: Thiago Jung Bauermann To: Mark Brown Cc: Catalin Marinas , Will Deacon , Jonathan Corbet , Andrew Morton , Marc Zyngier , Oliver Upton , James Morse , Suzuki K Poulose , Arnd Bergmann , Oleg Nesterov , Eric Biederman , Shuah Khan , "Rick P. Edgecombe" , Deepak Gupta , Ard Biesheuvel , Szabolcs Nagy , Kees Cook , "H.J. Lu" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Florian Weimer , Christian Brauner , Ross Burton , linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v9 35/39] kselftest/arm64: Add a GCS test program built with the system libc In-Reply-To: <20240625-arm64-gcs-v9-35-0f634469b8f0@kernel.org> (Mark Brown's message of "Tue, 25 Jun 2024 15:58:03 +0100") References: <20240625-arm64-gcs-v9-0-0f634469b8f0@kernel.org> <20240625-arm64-gcs-v9-35-0f634469b8f0@kernel.org> Date: Thu, 18 Jul 2024 13:14:41 -0300 Message-ID: <87plray8we.fsf@linaro.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240718_091446_724464_74E97114 X-CRM114-Status: GOOD ( 15.19 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org Mark Brown writes: > There are things like threads which nolibc struggles with which we want > to add coverage for, and the ABI allows us to test most of these even if > libc itself does not understand GCS so add a test application built > using the system libc. > > Reviewed-by: Thiago Jung Bauermann > Signed-off-by: Mark Brown > --- > tools/testing/selftests/arm64/gcs/.gitignore | 1 + > tools/testing/selftests/arm64/gcs/Makefile | 4 +- > tools/testing/selftests/arm64/gcs/gcs-util.h | 10 + > tools/testing/selftests/arm64/gcs/libc-gcs.c | 736 +++++++++++++++++++++++++++ > 4 files changed, 750 insertions(+), 1 deletion(-) In my FVP VM, this test gets a GCS SIGSEGV before running the first test: $ sudo ./run_kselftest.sh -t arm64:libc-gcs [sudo] password for bauermann: TAP version 13 1..1 # timeout set to 45 # selftests: arm64: libc-gcs # TAP version 13 # 1..118 # # Starting 118 tests from 32 test cases. # # RUN global.can_call_function ... # Segmentation fault not ok 1 selftests: arm64: libc-gcs # exit=139 $ It happens when returning from the syscall() glibc function that does the clone3 syscall in kselftest_harness.h: $ /var/tmp/gdb-gcs/bin/gdb -q arm64/libc-gcs Reading symbols from arm64/libc-gcs... (gdb) r Starting program: /var/tmp/selftests-v9/arm64/libc-gcs [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". TAP version 13 1..118 # Starting 118 tests from 32 test cases. # RUN global.can_call_function ... [Detaching after vfork from child process 823] Program received signal SIGSEGV, Segmentation fault Guarded Control Stack error. syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:41 [GCS error] warning: 41 ../sysdeps/unix/sysv/linux/aarch64/syscall.S: No such file or directory (gdb) p $_siginfo.si_signo $1 = 11 (gdb) p $_siginfo.si_code $2 = 10 (gdb) p $_siginfo._sifields._sigfault.si_addr $3 = (void *) 0xfffff7ed96b0 (gdb) disassemble Dump of assembler code for function syscall: 0x0000fffff7ed9680 <+0>: nop 0x0000fffff7ed9684 <+4>: mov w8, w0 0x0000fffff7ed9688 <+8>: mov x0, x1 0x0000fffff7ed968c <+12>: mov x1, x2 0x0000fffff7ed9690 <+16>: mov x2, x3 0x0000fffff7ed9694 <+20>: mov x3, x4 0x0000fffff7ed9698 <+24>: mov x4, x5 0x0000fffff7ed969c <+28>: mov x5, x6 0x0000fffff7ed96a0 <+32>: mov x6, x7 0x0000fffff7ed96a4 <+36>: svc #0x0 0x0000fffff7ed96a8 <+40>: cmn x0, #0xfff 0x0000fffff7ed96ac <+44>: b.cs 0xfffff7ed96b4 // b.hs, b.nlast => 0x0000fffff7ed96b0 <+48>: ret 0x0000fffff7ed96b4 <+52>: b 0xfffff7e18660 <__GI___syscall_error> 0x0000fffff7ed96b8 <+56>: b 0xfffff7e18660 <__GI___syscall_error> End of assembler dump. (gdb) bt #0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:41 [GCS error] #1 0x0000aaaaaaaa4acc in clone3_vfork () at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:93 #2 __run_test (f=f@entry=0xaaaaaaac0b88 <_fixture_global>, variant=variant@entry=0xffffffffee00, t=t@entry=0xaaaaaaac0018 <_can_call_function_object>) at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:1239 [GCS error] #3 0x0000aaaaaaaa2c40 in test_harness_run (argv=0xfffffffff008, argc=1) at /home/bauermann/src/linux/tools/testing/selftests/kselftest_harness.h:1314 #4 main (argc=1, argv=0xfffffffff008) at libc-gcs.c:735 [GCS error] (gdb) And indeed, the svc call in the disassemble above corrupts the GCS. This is the GCS and lr values right before the svc call: (gdb) x/i $pc => 0xfffff7ed96a4 : svc #0x0 (gdb) p/x $lr $3 = 0xaaaaaaaa4acc (gdb) p/x $gcspr $4 = 0xfffff7bfffe8 (gdb) x/g $gcspr 0xfffff7bfffe8: 0x0000aaaaaaaa4acc So far so good, the tip of the GCS matches $lr. But then: (gdb) stepi [Detaching after vfork from child process 2491] 39 in ../sysdeps/unix/sysv/linux/aarch64/syscall.S (gdb) x/i $pc => 0xfffff7ed96a8 : cmn x0, #0xfff (gdb) p/x $gcspr $5 = 0xfffff7bfffe8 (gdb) x/g $gcspr 0xfffff7bfffe8: 0x0000aaaaaaaa4c04 (gdb) p/x $lr $6 = 0xaaaaaaaa4acc So, right after svc returns, the tip of the GCS is corrupted and will cause the GCS error. -- Thiago _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv