From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D48381AA83 for ; Wed, 9 Aug 2023 16:05:53 +0000 (UTC) Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A513E2103; Wed, 9 Aug 2023 09:05:52 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 5A4A91F390; Wed, 9 Aug 2023 16:05:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1691597151; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kvmDSTIaCdq8N61OTz119nERnXMiJknpEuxA3UCZiDI=; b=bcfatQtCYuUjWviw3S4UYIP6DEdvgv8Rf/eATZzlOX2Fy2JRHn4Ooj0LqKrtr+Nx3ceHvN FxlgvIkQ/FJRJDKFXk6/RNefuJ4M0adGg4pdcpzjy/s9/NFwaBPrNlB/ZZN0Tkvu+A+lp3 RMBenB2HrgAeOC1LnPfeYKq7SX+0t4s= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1691597151; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kvmDSTIaCdq8N61OTz119nERnXMiJknpEuxA3UCZiDI=; b=eyv81018VpTT+8NF3ZoW5Kuwr8nSJgVAGysPE9Zo2BLHAkN+XQGHck5gysUnW8lxCb4rMF pyAoz3NdZMSfxpAQ== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 1D4C0133B5; Wed, 9 Aug 2023 16:05:51 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id pF6iBV+502Q+WwAAMHmgww (envelope-from ); Wed, 09 Aug 2023 16:05:51 +0000 Date: Wed, 09 Aug 2023 18:05:50 +0200 Message-ID: <87wmy4ciap.wl-tiwai@suse.de> From: Takashi Iwai To: Linus Torvalds Cc: Christoph Hellwig , Takashi Iwai , linux-kernel@vger.kernel.org, Andy Shevchenko , Mark Brown , netdev@vger.kernel.org Subject: Re: [PATCH RFC] Introduce uniptr_t as a generic "universal" pointer In-Reply-To: References: <87edkce118.wl-tiwai@suse.de> <20230809143801.GA693@lst.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On Wed, 09 Aug 2023 17:48:11 +0200, Linus Torvalds wrote: > > On Wed, 9 Aug 2023 at 07:38, Christoph Hellwig wrote: > > > > The original set_fs removal series did that as uptr_t, and Linus > > hated it with passion. I somehow doubt he's going to like it more now. > > Christoph is right. I do hate this. The whole "pass a pointer that is > either user or kernel" concept is wrong. > > Now, if it was some kind of extended pointer that also included the > length of the area and had a way to deal with updating the pointer > sanely, maybe that would be a different thing. > > And it should guarantee that in the case of a user pointer it had gone > through access_ok(). > > And it also allowed the other common cases like having a raw page > array, along with a unified interface to copy and update this kind of > pointer either as a source or a destination, that would be a different > thing. > > But this kind of "if (uniptr_is_kernel(src))" special case thing is > just garbage and *not* acceptable. > > And oh, btw, we already *have* that extended kind of unipointer thing. > > It's called "struct iov_iter". > > And yes, it's a very complicated thing, exactly because it handles way > more cases than that uniptr_t. It's a *real* unified pointer of many > different types. > > Those iov_iter things are often so complicated that you really don't > want to use them, but if you really want a uniptr, that is what you > should do. It comes with a real cost, but it does come with real > advantages, one of which is "this is extensively tested > nfrastructure". Hmm. In one side, I tend to agree that it can go wrong easily. OTOH, it simplifies the code well for us; as of now, we have two callbacks for copying PCM memory from/to the device, distinct for kernel and user pointers. It's basically either copy_from_user() or memcpy() of the given size depending on the caller. The sockptr_t or its variant would allow us to unify those to a single callback. Of course, we can create yet another local type that is just for the specific code -- or just (ab)use sockptr_t as is. The fact is that it can simplify the code well, which in turn make more maintainable. Though, I have no strong opinion about this topic. If you believe this kind of code is way too dangerous, fine, we can go with the current code. OTOH, if the limited use is acceptable (as already seen with sockptr_t), we can either re-use it or have own one. (And yeah, iov_iter is there, but it's definitely overkill for the purpose.) Takashi