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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 920D2C30658 for ; Tue, 2 Jul 2024 16:44:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 06B296B009D; Tue, 2 Jul 2024 12:44:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 019D96B00A0; Tue, 2 Jul 2024 12:44:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E242F6B00A2; Tue, 2 Jul 2024 12:44:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C366A6B009D for ; Tue, 2 Jul 2024 12:44:50 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4B229403E0 for ; Tue, 2 Jul 2024 16:44:50 +0000 (UTC) X-FDA: 82295386740.04.D949F75 Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by imf05.hostedemail.com (Postfix) with ESMTP id 5B977100004 for ; Tue, 2 Jul 2024 16:44:48 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of ldv@altlinux.org designates 194.107.17.57 as permitted sender) smtp.mailfrom=ldv@altlinux.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719938671; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=59lfciBacGAZ2RLbiF+jqHosemdXb6DiLPDlcrxf+gk=; b=cgJ9U2j5v22qFZzxGLsHYy/mLA1d4GChrZe105oAzNFYYeJrWaEC7+ymKNYm3q9cz+iYT1 HIK5V7Y/7eCWy3WV/Kj05SOICPboWCCJf90uPZpssxTsJhWuXXTJH6OhTmPh+4vD5DcgJM 3DcLEw0pas/ykNDUad1WUe1klYwENfE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of ldv@altlinux.org designates 194.107.17.57 as permitted sender) smtp.mailfrom=ldv@altlinux.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719938671; a=rsa-sha256; cv=none; b=SHpCBRsMSPkHLXCVAQNBFFUfHPAgsgM/eEN65gtDLyx1pl9g/EVoTKRdS/dDvguxm0eW1K 2z6aEtn6VBSg+dgnkeemY/onFxeMc16dF7yIQSoSEPJ3YBZ/z7mWq4IdnL2fsZUkBnYKiD ZfPcpApCJarduNbf7VG1QcItXEb3g60= Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id A673472C8CC; Tue, 2 Jul 2024 19:44:46 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 92B507CCB3A; Tue, 2 Jul 2024 19:44:46 +0300 (IDT) Date: Tue, 2 Jul 2024 19:44:46 +0300 From: "Dmitry V. Levin" To: Mathieu Desnoyers Cc: Steven Rostedt , Beau Belgrave , Vincent Donnefort , mhiramat@kernel.org, kernel-team@android.com, rdunlap@infradead.org, rppt@kernel.org, david@redhat.com, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Linus Torvalds Subject: Re: [PATCH v23 3/5] tracing: Allow user-space mapping of the ring-buffer Message-ID: <20240702164445.GA16225@altlinux.org> References: <20240510140435.3550353-1-vdonnefort@google.com> <20240510140435.3550353-4-vdonnefort@google.com> <20240630105322.GA17573@altlinux.org> <20240630084053.0b506916@rorschach.local.home> <9a9c8ea4-8e17-4e7e-95fe-7b51441a228c@efficios.com> <20240702111807.13d2dd2c@rorschach.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: mrgxqnnz7enrif5hox7q7bwepdj5myr9 X-Rspam-User: X-Rspamd-Queue-Id: 5B977100004 X-Rspamd-Server: rspam02 X-HE-Tag: 1719938688-967019 X-HE-Meta: U2FsdGVkX1+DWLvo+MFOWtKEZWeA6aKbqp+tdoxMYekEz3XMqAwu8NlI8S4HAH3N/Bu6DXh/46lNdB8+GzIpbZwpEg7/d92//NhW01bjoYnsjMuD/ouSj8EEA+PmIVKq3L9UEN4SL7H46LdXe4Zw/TodFSlseyEnYlYAhCDry7q5jJxRovuICFEdH82aQOjnF6o3ETfYmzADcykwPwADvmln1CoULW5OcJs/PsJRGrr3Kt3PCTLDhz/U+uiy0tisjkklOuLfClXQb7Uwmv9L9CuNMbZDKI3LFkMlv9vetm6IghbKYRjk+2KKwDLMATOE0cui7Jokh25VLdN2yXeVKmWPwCjv/qk55uq6swSqXN+0SFPqW71m2w/ey7CY6x8S/bhlxYnAOURgv5Ggbmdi1C2/qXa75AoYm0qNeWEt2jTixN2FbmdfbxDUxc0ALVjwYkfe01tqF/7O4nv9aOsQWPvAiY2LnAkCDu2jayyy6ng0h8F+S9LlhFXn53ZJCEl41ZQwaXc812Ud+wjlBATo97PNe+oFtqpqJdavHt7PMUh5OY5TRn8fmY2hqjDIUiI7R1/x/VGJzYFtW+kTTnyidxXftThLN0ugSNvND9h1Y5QjltrLkOACQlCgYp1h+XIhmgIg4bVdunx0om1xEn8Y+J4W2wFdz29FOCop25tcS6I9J+w9nloJUh4aE41YPMoCXaPq6DSWp8ID8TzbFje9B2WUcHRdbkd3kmv5J8KkPV1tQ1NmBAlB9zJ8C5zgZQLTE0EGzZ+nTK3lJYD21ft5fDNtcUt079twwNFsaZUJe4IvYYvXTyJKktD9U6VDrZ6VnqmWo1vpwlElBv7dcH8zTQTnrscJK2OWy7xU3xziK2zfTxmS6qOAM1+givrjcL8CLVcpqMvQbClFKoV930BSV3yzYmns7Ch8DKF0uTDa8mz1rPU7rCu7/mViDYQTDmBBEltv0G9RfS3dYC/DHKp 5DHZDoHp GPJTQhy9kNZxcmDQTv7Au9tSqmdgEe7mIiudQLeonfbwnklktUaiQhLdxqyc0QgoaY7/NJfv3OZyNYWIC3QApGaTalzDdwr7K1niw11PohxQ85YX1XSPc0SV/FejZSPtCRN4e5Mnqj0oR0EzLV8OfodZ/udkFsftYESDzNk+epWTl4ti8uSjA2JaDzWzfXigFaSUO97yACB5GhMyELrL9ebLsyr7H5J9GKe/tB2gE3w4h3IlCP2j6d/LBzA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Jul 02, 2024 at 11:32:53AM -0400, Mathieu Desnoyers wrote: [...] > Note that user events also has this issue: the ioctl is not reserved in > the ioctl-number.rst list. See include/uapi/linux/user_events.h: > > #define DIAG_IOC_MAGIC '*' > > /* Request to register a user_event */ > #define DIAG_IOCSREG _IOWR(DIAG_IOC_MAGIC, 0, struct user_reg *) > > /* Request to delete a user_event */ > #define DIAG_IOCSDEL _IOW(DIAG_IOC_MAGIC, 1, char *) > > /* Requests to unregister a user_event */ > #define DIAG_IOCSUNREG _IOW(DIAG_IOC_MAGIC, 2, struct user_unreg*) > > Where '*' maps to Code 0x2A. Looking at the list I don't see any > conflicts there, but we should definitely add it. > > If we use '*' for user events already, perhaps we'd want to consider > using the same range for the ring buffer ioctls ? Arguably one is > about instrumentation and the other is about ring buffer interaction > (data transport), but those are both related to tracing. FWIW, I've checked the list of ioctls known to strace and can confirm that currently there are no more users of 0x2a ioctl code besides these three DIAG_* ioctls. -- ldv