Received: by 2002:ab2:69cc:0:b0:1fd:c486:4f03 with SMTP id n12csp186965lqp; Tue, 11 Jun 2024 00:57:43 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWNUnedEoyHhkfgrG7lZBLdgM1V8GOvKU7ry8FDRGDa9ZgezM0rklqB2MdAGwsqo9DpT+wJzJKTd2n/j8KmrCzBUGlTeCBTNwyGjHTv4Q== X-Google-Smtp-Source: AGHT+IFGocYDLhIoNgDYQ5Jv22++iKkzCUZu/bThgG6OqXYGOj+QhCuDRuYCmShmiaBqtIvPSdfI X-Received: by 2002:a05:620a:319f:b0:795:55a1:9dd3 with SMTP id af79cd13be357-79555a19f78mr974101885a.16.1718092663058; Tue, 11 Jun 2024 00:57:43 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718092663; cv=pass; d=google.com; s=arc-20160816; b=zNw/mB6deWIYKhMoeT7upZM89ytf/q1XTjluzgmxH0X5LHSYBS1iRheQqxFWZLTAFy BB7fsbxeuyoG5n+R1nlLpkUYxNSXA4oByhUNvgpscu3M5AZrFF+coemQe+/q3uGMr/n9 dZz50AHz3xxwwZB8uqg59Klq0HZrBWsYMwsUu00zA+iNJ9Sq78snNEKQDgqmZqI/PgRY 5o+Htxn1UDlEnXA0QTeGqw/vY1+EgzYMWlcuZEkpGz/o6psb+gHj89gVT/YxGDiByeiK fMR+/F1bd5xcJHMYmA32sML6aT8F7V0uAwCP0SxLY8e94NBOUsvdZI8MqDP0JU35G04Q ZrlQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=5PMD/pT9HssoVLtoMDVgrtV/QV1xt3qUETxKwc+IcCE=; fh=KsNH1AQ9ZoAuCAPBKsivkA9+TAl2XIT+wY07MoKO8EA=; b=iBCMnHw9zbe5OF0qLHLamlb4z5kmZqQh+CmKaLFsuU9bu+aakp8aiMbyeCMUnAWUPH /X2kECUkCZlx7nlCta5lW3vXf0uBnluuuFBDMGhHqamKU7B+3G+vY+JbUe/mNHyNgkw3 1/LzF6GITfW2kNVREIGRCF9DDVfFYYTAlEjiWtjUjCuqy6FHf4wnv+ak2WoPR0TO6heY xBCUG8SD4Mzoqd/zS8qyPvGnRPSbe51iHtUQcDgSoSRF5W34uSeFqxV24T2eUMLLhd+s kCEoM6texm6FFJVKgV/AFMAvPhexLoWOFJmZ8eWI3A974sj7zsFIDxvxT7CITl5HU9I0 PNZw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-209432-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-209432-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id af79cd13be357-79532894404si983111485a.175.2024.06.11.00.57.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 00:57:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-209432-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-209432-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-209432-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 6BEF21C23097 for ; Tue, 11 Jun 2024 07:57:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id AF220174ED7; Tue, 11 Jun 2024 07:57:11 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A013173354; Tue, 11 Jun 2024 07:57:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718092631; cv=none; b=oMlC0FqjAfG+CRa6V3jbKDUrmWAmzTM5FZc3ZTVfQ4IQlZ4WGI2A0wfz0YCmNVd9VTBc5D7wLgx6UuqBZjcr/Fy3MbkUWJIKJwFo75u23rrXZKX7jyAQ8P004KzqHX258ifyiRgNq+JfNAX2cvLe01xockhiEaRJUNcx307jN/Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718092631; c=relaxed/simple; bh=JVs0dPQ5KkLuiQTfgcUkKGnKz+c/fwbbBiyZhmR5Bl0=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Cmdm4hgLZDlU3oX35K5kzDJJO+b844tOuAgOeO5/wBM6Rktk46JT/yrPUZ3/kOXmlEok9UU/tDIhoDprSoRaYnn0eR3LRF/738QskEXsQCjUQltaufbwwOOdwXmfoXdlLb7PY0w6hvKev94UeYN4skKQucRhXCA3HTtXCtInYcI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 02B9B1692; Tue, 11 Jun 2024 00:57:33 -0700 (PDT) Received: from e116581.blr.arm.com (e116581.arm.com [10.162.41.16]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 9EF223F64C; Tue, 11 Jun 2024 00:57:03 -0700 (PDT) From: Dev Jain To: shuah@kernel.org, oleg@redhat.com, stsp2@yandex.ru Cc: mingo@kernel.org, tglx@linutronix.de, mark.rutland@arm.com, ryan.roberts@arm.com, broonie@kernel.org, suzuki.poulose@arm.com, Anshuman.Khandual@arm.com, DeepakKumar.Mishra@arm.com, AneeshKumar.KizhakeVeetil@arm.com, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Dev Jain Subject: [PATCH v2 0/2] Add test to distinguish between thread's signal mask and ucontext_t Date: Tue, 11 Jun 2024 13:26:48 +0530 Message-Id: <20240611075650.814397-1-dev.jain@arm.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit This patch series is motivated by the following observation: Raise a signal, jump to signal handler. The ucontext_t structure dumped by kernel to userspace has a uc_sigmask field having the mask of blocked signals. If you run a fresh minimalistic program doing this, this field is empty, even if you block some signals while registering the handler with sigaction(). Here is what the man-pages have to say: sigaction(2): "sa_mask specifies a mask of signals which should be blocked (i.e., added to the signal mask of the thread in which the signal handler is invoked) during execution of the signal handler. In addition, the signal which triggered the handler will be blocked, unless the SA_NODEFER flag is used." signal(7): Under "Execution of signal handlers", (1.3) implies: "The thread's current signal mask is accessible via the ucontext_t object that is pointed to by the third argument of the signal handler." But, (1.4) states: "Any signals specified in act->sa_mask when registering the handler with sigprocmask(2) are added to the thread's signal mask. The signal being delivered is also added to the signal mask, unless SA_NODEFER was specified when registering the handler. These signals are thus blocked while the handler executes." There clearly is no distinction being made in the man pages between "Thread's signal mask" and ucontext_t; this logically should imply that a signal blocked by populating struct sigaction should be visible in ucontext_t. Here is what the kernel code does (for Aarch64): do_signal() -> handle_signal() -> sigmask_to_save(), which returns ¤t->blocked, is passed to setup_rt_frame() -> setup_sigframe() -> __copy_to_user(). Hence, ¤t->blocked is copied to ucontext_t exposed to userspace. Returning back to handle_signal(), signal_setup_done() -> signal_delivered() -> sigorsets() and set_current_blocked() are responsible for using information from struct ksignal ksig, which was populated through the sigaction() system call in kernel/signal.c: copy_from_user(&new_sa.sa, act, sizeof(new_sa.sa)), to update ¤t->blocked; hence, the set of blocked signals for the current thread is updated AFTER the kernel dumps ucontext_t to userspace. Assuming that the above is indeed the intended behaviour, because it semantically makes sense, since the signals blocked using sigaction() remain blocked only till the execution of the handler, and not in the context present before jumping to the handler (but nothing can be confirmed from the man-pages), the series introduces a test for mangling with uc_sigmask. I will send a separate series to fix the man-pages. The proposed selftest has been tested out on Aarch32, Aarch64 and x86_64. Changes in v2: - Replace all occurrences of SIGPIPE with SIGSEGV - Fixed a mismatch between code comment and ksft log - Add a testcase: Raise the same signal again; it must not be queued - Remove unneeded , - Give a detailed test description in the comments; also describe the exact meaning of delivered and blocked - Handle errors for all libc functions/syscalls - Mention tests in Makefile and .gitignore in alphabetical order Dev Jain (2): selftests: Rename sigaltstack to generic signal selftests: Add a test mangling with uc_sigmask tools/testing/selftests/Makefile | 2 +- .../{sigaltstack => signal}/.gitignore | 3 +- .../{sigaltstack => signal}/Makefile | 3 +- .../current_stack_pointer.h | 0 .../selftests/signal/mangle_uc_sigmask.c | 194 ++++++++++++++++++ .../sas.c => signal/sigaltstack.c} | 0 6 files changed, 199 insertions(+), 3 deletions(-) rename tools/testing/selftests/{sigaltstack => signal}/.gitignore (57%) rename tools/testing/selftests/{sigaltstack => signal}/Makefile (53%) rename tools/testing/selftests/{sigaltstack => signal}/current_stack_pointer.h (100%) create mode 100644 tools/testing/selftests/signal/mangle_uc_sigmask.c rename tools/testing/selftests/{sigaltstack/sas.c => signal/sigaltstack.c} (100%) -- 2.34.1