From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (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 B7B112E92C7 for ; Tue, 22 Jul 2025 14:33:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753194810; cv=none; b=RsXloPaYuK6NZRbHyOWPQvVFwUfRmJ5kG4xE1wq8xgC7pTsH3axc8J71sCfNjZOxiorFViyEjV+3tBvAt3ZR9iQeDOpNWsmPo1VyoNhcqfH8xapY/73qePqqS6hL4cboUhd9aodcFcNs1MnqswGUHbKZYCc2PQ76T0eyt0dow04= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753194810; c=relaxed/simple; bh=fv7AJ047lftjYrvdeOh9awJwbVijUB3ZG9yyk9jPZz0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TflFn/cxHe8AVKmqa0VhMG8I6RHKP4Ug5278yX0PewZGEgSkUWm4T/oG56kio0abYwX+0gkdKEycQ5wjNmd8TnG4rqWRPEXqxAhyEYF4atcjAvVp9U/5MQ2Oeife7YeMN26dQMNTDANztPR6wApbEOrhAykX1RMI+CWfGXuh9Ug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=furiosa.ai; spf=none smtp.mailfrom=furiosa.ai; dkim=pass (1024-bit key) header.d=furiosa.ai header.i=@furiosa.ai header.b=BEtMaDSW; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=furiosa.ai Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=furiosa.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=furiosa.ai header.i=@furiosa.ai header.b="BEtMaDSW" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-75ce780af03so1803141b3a.2 for ; Tue, 22 Jul 2025 07:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=furiosa.ai; s=google; t=1753194808; x=1753799608; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=M7fGZKT3ggFMUdBYkzEIRO465LQFB1F7egGN40OaEMk=; b=BEtMaDSWRnEErqlT7JMROzTBNDaniQfYpuvkkaLWdVuc8S/uZcH9ZMvOvWoCBql8j5 O0VLmGKvWpCx70qaln764Y2bXuHS7ZlA8U1kNnT421YQ7RFZojot5ittvwVjW5NsUMsr ZKoy93gkMtr+TpKupcYAdB8wQtVIAcY/VnVWA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753194808; x=1753799608; h=in-reply-to:content-transfer-encoding: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=M7fGZKT3ggFMUdBYkzEIRO465LQFB1F7egGN40OaEMk=; b=VsnifXrX95QLnOaXP3spcG2rxoIYjU++xH69EyMI5ThVTpGbaDrrXGz6IrO5evlJXT NEaLKsm6RnLyGgxh6aQyO9mu/TXX0qFbhVlGunaR+zDR2jtBZoJPFk9daW2POiQjrSvu jkftYvSbN2fzWHS6kGjH56+hIrGqnQoufBauhHL8cHhRmiL4tOBl0xOCeJs+XibUN+Qq wh/al2QgUuCoZy4V92kqKgiZTESn5Gecb1vEYySwrBFQV5w0JO103Dyf3+QEWJouq5dC GJgn0XeUCrTkaDjFFG0tQnmmEw/aSxl8/q9M0bPcj3luQoIazC0pWyTwf5iapnOZyBZd rv1w== X-Forwarded-Encrypted: i=1; AJvYcCUaEgKMf5nw5V/NUUhPpoWwa7km6lqZvSsl3UK5kw9JBOLvFbU/4iD+9uiRh9zziHqGzQ8plfVkH+npcWN+XA==@vger.kernel.org X-Gm-Message-State: AOJu0YyiABh3PJ8I6WmPEEw+D4Wu2jMX9vHs89hMDPZz2VJ+Ah9N9nSV LQ1Ic0LeIt3Wewe2IWcC63pjwS17MDTMA7wbbkFrMJZik1N6nCPUZm3t0IGNFvJanLc= X-Gm-Gg: ASbGnctU88bb9w1lZ3mvs9TGMRH5hH7wwqbw+tkb4OfxvAgoIjGwTxmeWQWgMQRV+/b ZonypAdjw585whTOs1a5UmOdeF9nZ4h5Mw6vcGAWMuwT1Nou/KmrfeB6UN+7Km0lidkJ5IbcEnX wnBZw+szl8yQVsJjWa3z0qWyNtX9aWt5SizSMsQ9MPt3e3nanPJef3n1V41qLqg0o6LznIKywZf huAMQNLErIjFD5yqTvE2dn17JVGDk6CUqMCy//UilQXlv9WNxkHCxE0xx3HPi8sTNnbtyP2GqVE DHPKTYrbWfFJiMRJU5efiDD7UyTdh1nj+1T20mOvv/Mnu9y7YQ7rR3DAn8PHOZV/WjGkD+SxpsJ SGzNs6ZsZDyak7YYOtu6YHic0MQWW5XMwhIzR+J4PLFKBh5hANPcQBtGA1MlCEw67kUxhDg== X-Google-Smtp-Source: AGHT+IFWFM/ezEnw+gUjX3lXlEi7sZO9lCCQrwj/IgdE0HPpAyeUUj5d+7M3EkDn2sTRy7/yVS+0Jg== X-Received: by 2002:a05:6300:6199:b0:232:9550:128f with SMTP id adf61e73a8af0-23813237521mr37395363637.36.1753194807942; Tue, 22 Jul 2025 07:33:27 -0700 (PDT) Received: from sidongui-MacBookPro.local ([61.83.209.48]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-759c84e2008sm7230211b3a.30.2025.07.22.07.33.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Jul 2025 07:33:27 -0700 (PDT) Date: Tue, 22 Jul 2025 23:33:21 +0900 From: Sidong Yang To: Benno Lossin Cc: Caleb Sander Mateos , Miguel Ojeda , Arnd Bergmann , Jens Axboe , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org Subject: Re: [PATCH 2/4] rust: io_uring: introduce rust abstraction for io-uring cmd Message-ID: References: <20250719143358.22363-1-sidong.yang@furiosa.ai> <20250719143358.22363-3-sidong.yang@furiosa.ai> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Jul 21, 2025 at 05:52:41PM +0200, Benno Lossin wrote: > On Mon Jul 21, 2025 at 5:04 PM CEST, Caleb Sander Mateos wrote: > > On Mon, Jul 21, 2025 at 1:23 AM Sidong Yang wrote: > >> On Sun, Jul 20, 2025 at 03:10:28PM -0400, Caleb Sander Mateos wrote: > >> > On Sat, Jul 19, 2025 at 10:34 AM Sidong Yang wrote: > >> > > + } > >> > > + > >> > > + // Called by consumers of io_uring_cmd, if they originally returned -EIOCBQUEUED upon receiving the command > >> > > + #[inline] > >> > > + pub fn done(self, ret: isize, res2: u64, issue_flags: u32) { > >> > > >> > I don't think it's safe to move io_uring_cmd. io_uring_cmd_done(), for > >> > example, calls cmd_to_io_kiocb() to turn struct io_uring_cmd *ioucmd > >> > into struct io_kiocb *req via a pointer cast. And struct io_kiocb's > >> > definitely need to be pinned in memory. For example, > >> > io_req_normal_work_add() inserts the struct io_kiocb into a linked > >> > list. Probably some sort of pinning is necessary for IoUringCmd. > >> > >> Understood, Normally the users wouldn't create IoUringCmd than use borrowed cmd > >> in uring_cmd() callback. How about change to &mut self and also uring_cmd provides > >> &mut IoUringCmd for arg. > > > > I'm still a little worried about exposing &mut IoUringCmd without > > pinning. It would allow swapping the fields of two IoUringCmd's (and > > therefore struct io_uring_cmd's), for example. If a struct > > io_uring_cmd belongs to a struct io_kiocb linked into task_list, > > swapping it with another struct io_uring_cmd would result in > > io_uring_cmd_work() being invoked on the wrong struct io_uring_cmd. > > Maybe it would be okay if IoUringCmd had an invariant that the struct > > io_uring_cmd is not on the task work list. But I would feel safer with > > using Pin<&mut IoUringCmd>. I don't have much experience with Rust in > > the kernel, though, so I would welcome other opinions. > > Pinning in the kernel isn't much different from userspace. From your > description of what normally happens with `struct io_uring_cmd`, it > definitely must be pinned. > > From a quick glance at the patch series, I don't see a way to create a > `IoUringCmd` by-value, which also means that the `done` function won't > be callable (also the `fn pdu(&mut self)` function won't be callable, > since you only ever create a `&IoUringCmd`). I'm not sure if I'm missing > something, do you plan on further patches in the future? Sure, this version is full of nonsence. v2 will be better than this. > > How (aside from `from_raw`) are `IoUringCmd` values going to be created > or exposed to the user? Nomrally user would gets Pin<&mut IoUringCmd> from MiscDevice::uring_cmd(). Thanks, Sidong > > --- > Cheers, > Benno