From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 937D31D63D6 for ; Thu, 16 Jan 2025 21:47:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737064035; cv=none; b=ZLr7ZOfcSOYnZ3wYRWqRfy5rncvESl73JA4+HeW5ZonebOSjBzqIHB5jurXWgSnZPtAVDo+QFMa7OulsMgmIDmCXHGxIcVGEc42pUnmX0DQrRiU+Rsz7X13HVU17e1dANs3iGPE7fFCZYCtgmQJWay1C1tES7uk87JGckQaBG1U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737064035; c=relaxed/simple; bh=DbWdv2pgPh8ds9v9nhyPObQU2NpiBzVxcHxxNVg34oI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XWnhBCbcI6BkwMTOzFtN7evFNJrygXXNE5+HbGJuI8slFMFtGiJsfhtSurspFAR0qZL++5PgDeKubf1kKbVjVZI4RMGX2Fjyh3QBqDqvAg9p+eL5b4fwpx00CCvajx85AzdjWvCxaua3Y4ySDNftcFniXUYLSSLB0e4/SLsVjVA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=fc2OAxKp; arc=none smtp.client-ip=209.85.216.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="fc2OAxKp" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2ef87d24c2dso2082777a91.1 for ; Thu, 16 Jan 2025 13:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1737064033; x=1737668833; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=AUjGjdMfJB9QfNhG0/N12UqZ6Jr6QZ9KZ+1u+irK9iQ=; b=fc2OAxKpBHpnmpYn1SzcQaReDS4iAMCNzPJVP4V3jzPTT4IWgZD5W2cvKGtuAQ3DnG FcC5XGdJ9z/PrJ3hjRa/EmwArB/25d3UVN9lFfRjkHnznI9lLvyPJsspC2bfD+ciVO/Q qiDTIVbdZTZxzuZHcZb+pUo3vrGnTKkRqjkUghPjf9HAg0LVZOQnqicgwDufAvf06DxF KDY7rKq7c1Eyiln3RBwQPOR2HIjSWPGrqXb4QxXwMUdeW+gcyd9K1BjFRYweeBN00g7Q JZbkFfG3990XmzDzVm0OA9SF/L2SYpdU9y45cCWZiemXQfFswN+RSGrh1FxfOcaclguR ZTvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737064033; x=1737668833; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AUjGjdMfJB9QfNhG0/N12UqZ6Jr6QZ9KZ+1u+irK9iQ=; b=j6BxaCbByug07S2iLijyp5J0zUAOQx1EdtFUpjGcuw9T3bGg4NeaPfTWN69wgMAiq7 9dixNFoF39S8lrCYHl0Ft8uPZeo8yC8VIntRCiXcla5EEWSyYOYpStsNkzS/LX5eVDBw cubvmMdY5Q59nG/SvEX2KUk2qd9xffxaB/pZ5i9c/fWf7dg+6pfHyQePMN1hpre/Bqmk BaZavszQoO4+QqlxXvMTzpzdPgg2LFC9BW+1dXUtmNybzPqvAvx5A6JeahrvBDAl02QC dMMJAI8WP7E5Wga8jIHcvqSn+tmUXxLCDN/OyPT2MZcHBmokYAqeIoKhcao7+K0Y/2HY 6UDw== X-Forwarded-Encrypted: i=1; AJvYcCXN6J/OFyH8wmkPlZnim6F8uRHut8mLBlhYUClRj8UzNexaljznit26yf7Vi1U8AHBo8XKznUFr8vFGKeM=@vger.kernel.org X-Gm-Message-State: AOJu0YxmJAs6qXgxjHmqM9V36A5nPMk2JO1z/oYk7YeTokTrtol3DB4u Cr/P/MvwR9ZyCKSy6LgGTqvSHaRnR6vzqDqhF6ZG7Rc+eR/rCljsIEE50f3+PS8= X-Gm-Gg: ASbGncuMMJXg++Y6SK9KZJEq1f3A5Js/kEYV8vkbwr9ybsJ568/Kh6OOdQN4iR8/MwM ZUbLCFdh1IuYpbebxQ+YwykBzPOpiCn4c3lDNz2+XJAav+1Fu9hny83/YAU3/TLD9/vD9WAtXIl b0zcQzgqjspiCEDII4hbp780ra+pABX3ZvMStFYtWWCw4tVqTp6G9wmhuCDBeTpoov18g6fUlAC kLAK2FwBN6MxRNbiru9ZdLjG2hKZzA/L9Ne3KfHP15gstg= X-Google-Smtp-Source: AGHT+IHtLEnbdesCbqY0qN5EM2QLUnnF86VdNxs05PScoQX0z/O6MEZlEHUv3uHkySsa7l26IPeeTg== X-Received: by 2002:a17:90b:1f91:b0:2f1:4715:5987 with SMTP id 98e67ed59e1d1-2f782c92749mr257291a91.9.1737064032832; Thu, 16 Jan 2025 13:47:12 -0800 (PST) Received: from ghost ([50.145.13.30]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2f77616117bsm598578a91.20.2025.01.16.13.47.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 13:47:12 -0800 (PST) Date: Thu, 16 Jan 2025 13:47:09 -0800 From: Charlie Jenkins To: "Dmitry V. Levin" Cc: Oleg Nesterov , Eugene Syromyatnikov , Mike Frysinger , Renzo Davoli , Davide Berardi , Celeste Liu , strace-devel@lists.strace.io, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH v2 6/7] ptrace: introduce PTRACE_SET_SYSCALL_INFO request Message-ID: References: <20250113170925.GA392@strace.io> <20250113171208.GF589@strace.io> <20250116083328.GA32173@strace.io> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Thu, Jan 16, 2025 at 01:07:59PM -0800, Charlie Jenkins wrote: > On Thu, Jan 16, 2025 at 10:33:28AM +0200, Dmitry V. Levin wrote: > > On Wed, Jan 15, 2025 at 05:55:31PM -0800, Charlie Jenkins wrote: > > > On Mon, Jan 13, 2025 at 07:12:08PM +0200, Dmitry V. Levin wrote: > > [...] > > > > + /* Changing the type of the system call stop is not supported. */ > > > > + if (ptrace_get_syscall_info_op(child) != info.op) > > > > > > Since this isn't supported anyway, would it make sense to set the > > > info.op to ptrace_get_syscall_info_op(child) like is done for > > > get_syscall_info? The usecase I see for this is simplifying when the > > > user doesn't call PTRACE_GET_SYSCALL_INFO before calling > > > PTRACE_SET_SYSCALL_INFO. > > > > struct ptrace_syscall_info.op is a field that specifies how to interpret > > the union fields of the structure, so if "op" is ignored, then the > > kernel would infer the meaning of the structure specified by the userspace > > tracer from the kernel state of the tracee. This looks a bit too > > error-prone to allow. For example, nothing good is expected to happen > > if syscall entry information is applied in a syscall exit stop. > > Yes that's a good point. > > > > > The tracer is not obliged to call PTRACE_GET_SYSCALL_INFO to set > > struct ptrace_syscall_info.op. If the tracer keeps track of ptrace stops > > by other means, it can assign the right value by itself. > > > > And, btw, the comment should say "is not currently supported", > > I'll update it in the next iteration. > > > > An idea mentioned in prior discussions was that it would make sense to > > specify syscall return value along with skipping the syscall in seccomp stop, > > and this would require a different value for "op" field, but > > I decided not to introduce this extra complexity yet. > > Makes sense, thank you! > > - Charlie I am no longer convinced that we need Celeste's patch that solves this problem on riscv [1]. That patch is necessary without this change, but PTRACE_SET_SYSCALL_INFO seems like a cleaner solution. Reviewed-by: Charlie Jenkins Tested-by: Charlie Jenkins - Charlie [1] https://lore.kernel.org/lkml/20250115-13cc73c36c7bb3b9f046f614@orel/T/ > > > > > > > -- > > ldv