From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 996821E503C for ; Mon, 12 May 2025 14:51:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747061505; cv=none; b=noaxiKg9tc03KsdUsuwuRzId1V7OAJBWLIierpfsNH0TLYo7Hq0L6ZdYJzadK7J8OB7CnOsxOtMVBnDh/6Yl9vr2jVpOLtJimoCW4iGCuC13H51r9++1oUrWnHjb/SUIKc/MR97ChPj8WtWTOJg87IsRUUt/l8B/6S2bulYyD98= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747061505; c=relaxed/simple; bh=skKPBy1kNvIiJYBQKiVWoH27pofu9c5eyYPy/uPCdpQ=; h=From:In-Reply-To:References:To:Cc:Subject:MIME-Version: Content-Type:Date:Message-ID; b=IE3kZ5xUZRHdEHWakwpnnrdvtTczdm987Cfh6bgWfwiAgvPAFrA22Vk0syc62KMKcprr2+KREXB2DEnPGoNvgy0vjmmQIUfgTBnvHZewKcLmUQ/9ZQQB9wcma/ym4/peCoNPvyXSAY24I+guIAWSH0aaQn3tKqtSWhjUoU+tHQM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=X0TxoF4r; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="X0TxoF4r" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747061502; h=from:from:reply-to:subject:subject: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=ymBHISBoRGTxFMCkiuee6KTKTNeCUMLWNl/W6hAI6Kw=; b=X0TxoF4rflnr9K88PePZb5mqwiip//GiK5P3tm74VITwPf5/mfrvFLQqTABntrlLxG35bI OtWE7jh/RAQY+qMnv7p+sL4cQKLEOvlxzGcJDHo1FyWUboW/+my8lYerR5OkH5WUJEUeuK cM/ay5GOS/TpwOAjViCRNXkc3bFmhFM= Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-474-kDroPQX2Oc-xfnwc7e4WeQ-1; Mon, 12 May 2025 10:51:40 -0400 X-MC-Unique: kDroPQX2Oc-xfnwc7e4WeQ-1 X-Mimecast-MFC-AGG-ID: kDroPQX2Oc-xfnwc7e4WeQ_1747061498 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 653311955D7F; Mon, 12 May 2025 14:51:37 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.188]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id DFD7030001A1; Mon, 12 May 2025 14:51:31 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1069540.1746202908@warthog.procyon.org.uk> References: <1069540.1746202908@warthog.procyon.org.uk> <165f5d5b-34f2-40de-b0ec-8c1ca36babe8@lunn.ch> <0aa1b4a2-47b2-40a4-ae14-ce2dd457a1f7@lunn.ch> <1015189.1746187621@warthog.procyon.org.uk> <1021352.1746193306@warthog.procyon.org.uk> To: Andrew Lunn Cc: dhowells@redhat.com, Eric Dumazet , "David S. Miller" , Jakub Kicinski , David Hildenbrand , John Hubbard , Christoph Hellwig , willy@infradead.org, Christian Brauner , Al Viro , Miklos Szeredi , torvalds@linux-foundation.org, netdev@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: AF_UNIX/zerocopy/pipe/vmsplice/splice vs FOLL_PIN 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-ID: <2135906.1747061490.1@warthog.procyon.org.uk> Date: Mon, 12 May 2025 15:51:30 +0100 Message-ID: <2135907.1747061490@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 I'm looking at how to make sendmsg() handle page pinning - and also working towards supporting the page refcount eventually being removed and only being available with certain memory types. One of the outstanding issues is in sendmsg(). Analogously with DIO writes, sendmsg() should be pinning memory (FOLL_PIN/GUP) rather than simply getting refs on it before it attaches it to an sk_buff. Without this, if memory is spliced into an AF_UNIX socket and then the process forks, that memory gets attached to the child process, and the child can alter the data, probably by accident, if the memory is on the stack or in the heap. Further, kernel services can use MSG_SPLICE_PAGES to attach memory directly to an AF_UNIX pipe (though I'm not sure if anyone actually does this). (For writing to TCP/UDP with MSG_ZEROCOPY, MSG_SPLICE_PAGES or vmsplice, I think we're probably fine - assuming the loopback driver doesn't give the receiver the transmitter's buffers to use directly... This may be a big 'if'.) Now, this probably wouldn't be a problem, but for the fact that one can also splice this stuff back *out* of the socket. The same issues exist for pipes too. The question is what should happen here to a memory span for which the network layer or pipe driver is not allowed to take reference, but rather must call a destructor? Particularly if, say, it's just a small part of a larger span. It seems reasonable that we should allow pinned memory spans to be queued in a socket or a pipe - that way, we only have to copy the data once in the event that the data is extracted with read(), recvmsg() or similar. But if it's spliced out we then have all the fun of managing the lifetime - especially if it's a big transfer that gets split into bits. In such a case, I wonder if we can just duplicate the memory at splice-out rather than trying to keep all the tracking intact. If the memory was copied in, then moving the pages should be fine - though the memory may not be of a ref'able type (which would be fun if bits of such a page get spliced to different places). I'm sure there is some app somewhere (fuse maybe?) where this would be a performance problem, though. And then there's vmsplice(). The same goes for vmsplice() to AF_UNIX or to a pipe. That should also pin memory. It may also be possible to vmsplice a pinned page into the target process's VM or a page from a memory span with some other type of destruction. I don't suppose we can deprecate vmsplice()? David