From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 48DDA3B71A8; Tue, 11 Aug 2026 15:28:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786462089; cv=none; b=DnAlQEhgzOtO3I9yzuVbt9UoUtK13ofPwjPQckE3ZBvnntPhg28/zjPfhxelsJj5r0YuorhtX2oKWjtFlPO00L7uOR9KPfYUF6+zF3arHAxPVZQPzSwxOe0XtYqz9gfzz27fryXqSyuhnel7cJ3FodH2cVrPSOPobl7WMYVI6kg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786462089; c=relaxed/simple; bh=uBST1XLQTUf+x0hFBtk8wUBZ/6YyWD5sMLzaZ6j7wCs=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=By9dTgXqMDkihiXrxsWuMygZlsczmJij00TJxvZO2iwzhjm2b1HYPDZmGI+BTIALIgwfvfFLbGQoMvDcdaHQcSGbSmPQ4q5zJvDCA7+wkzFVCfng/+raoV8eg3I8+Xt+DEcCE7vNav9YeGP+vH6xW2QhSeR+TzOt7ODt4HYOktQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eNbl9TI+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eNbl9TI+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 400961F000E9; Tue, 11 Aug 2026 15:28:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786462086; bh=sCoOreTJ2X/U61okovu+QNFm+oz9E14qwVyjp1SenYU=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=eNbl9TI+d6Es9bc/AmTgJ67rm9UG7VS/zO+HHdhXLVol8SmFRI47CW0i13SWMZym/ vePrh2c62xPxDOxkwoTu4jAO9P+Zgd+FeZgsvfV537P7hC4XaKsV/AN/EGkfHmc3tC sF3jx+JRyhJroiIU18oQaqIkABgUW8X3opwfY1YnylUO0lFoHUfvB/YChdsG7w3Bow 4dOlvRGU2Lk7+MVqdjht4kTqujXmvRhIUILx76jTqmyZmB8F7mR6hZO3oXgT0kgESI wD4qtuIgd6al2df5xUQGPK7RpYtcCc9Z0oddjUuKMYPArBgws7dLcGGsQeOh8FMkh1 by7tNafbgiprw== From: Christian Brauner Date: Tue, 11 Aug 2026 17:27:28 +0200 Subject: [PATCH 07/11] coredump: add COREDUMP_SPARSE to the coredump socket protocol 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="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260811-work-coredump-sparse-v1-7-cd3e8b1e356d@kernel.org> References: <20260811-work-coredump-sparse-v1-0-cd3e8b1e356d@kernel.org> In-Reply-To: <20260811-work-coredump-sparse-v1-0-cd3e8b1e356d@kernel.org> To: Jacob Lalonde , Josef Bacik Cc: Alexander Viro , Jan Kara , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Omar Sandoval , Jacob Lalonde , Shuah Khan , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "Christian Brauner (Amutable)" X-Mailer: b4 0.17-dev-362b8 X-Developer-Signature: v=1; a=openpgp-sha256; l=3305; i=brauner@kernel.org; h=from:subject:message-id; bh=uBST1XLQTUf+x0hFBtk8wUBZ/6YyWD5sMLzaZ6j7wCs=; b=owGbwMvMwCU28Zj0gdSKO4sYT6slMWRV2yfsV7+0jE90UseLxdeWPnmcv/RASONqk85bkzbMe Mrd1N6/raOUhUGMi0FWTJHFod0kXG45T8Vmo0wNmDmsTCBDGLg4BWAix+UZGZpz2R8uEL4yI//y rQ+5MlV69T2bTR5ksS7sFFVrMdjW2M/w31dBU37BJv7/Z34LL774sKnBTFuTe+tH2fj414HfJOy D+QE= X-Developer-Key: i=brauner@kernel.org; a=openpgp; fpr=4880B8C9BD0E5106FC070F4F7B3C391EFEA93624 A coredump with a lot of unpopulated mappings sends endless amounts of zero data to userspace. This is nonsensical. While __dump_skip() can seek over them when the target is a regular file a socket cannot do this. COREDUMP_HEADER framed the zeroes but it didn't get rid of them. Add a COREDUMP_SPARSE feature bit and a COREDUMP_FRAME_ZERO frame type. A zero frame is a bare header that tells userspace how many zero bytes where skipped. So a hole crosses the socket as one header no matter how long it is. The coredump server can recreate this sparsely. Zero frames only exist inside a framed stream. So COREDUMP_SPARSE requires COREDUMP_HEADER. Signed-off-by: Christian Brauner (Amutable) --- include/uapi/linux/coredump.h | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/include/uapi/linux/coredump.h b/include/uapi/linux/coredump.h index 5252480d3eec..312bafabb467 100644 --- a/include/uapi/linux/coredump.h +++ b/include/uapi/linux/coredump.h @@ -14,6 +14,8 @@ * @COREDUMP_HEADER: send the coredump as a sequence of frames instead of * as a plain byte stream, see struct coredump_frame_header; * requires COREDUMP_KERNEL + * @COREDUMP_SPARSE: describe the holes in the coredump as zero frames + * instead of transferring them; requires COREDUMP_HEADER */ enum { COREDUMP_KERNEL = (1ULL << 0), @@ -21,6 +23,7 @@ enum { COREDUMP_REJECT = (1ULL << 2), COREDUMP_WAIT = (1ULL << 3), COREDUMP_HEADER = (1ULL << 4), + COREDUMP_SPARSE = (1ULL << 5), }; /** @@ -109,10 +112,13 @@ enum coredump_mark { * enum coredump_frame_type - Type of a coredump frame * * @COREDUMP_FRAME_DATA: the header is followed by ->len bytes of data + * @COREDUMP_FRAME_ZERO: the header stands for ->len zero bytes and is not + * followed by any data * @__COREDUMP_FRAME_MAX: the maximum coredump frame type value */ enum coredump_frame_type { COREDUMP_FRAME_DATA = 0U, + COREDUMP_FRAME_ZERO = 1U, __COREDUMP_FRAME_MAX = (1U << 31), }; @@ -126,8 +132,10 @@ enum coredump_frame_type { * * If the coredump server raises COREDUMP_HEADER in coredump_ack->mask the * kernel doesn't send the coredump as a plain byte stream. It sends a - * sequence of frames instead. A struct coredump_frame_header is followed by - * @len bytes of actual coredump data. + * sequence of frames instead. A COREDUMP_FRAME_DATA frame is followed by + * @len bytes of actual coredump data. A COREDUMP_FRAME_ZERO frame is + * followed by nothing and stands for @len zero bytes. A server that didn't + * raise COREDUMP_SPARSE never sees a zero frame. * * The @size member is set to the size of struct coredump_frame_header the * kernel knows and lets the header grow later. It comes first so it can be @@ -139,7 +147,8 @@ enum coredump_frame_type { * interpreted. No flags are defined yet. Userspace must refuse a frame * carrying a flag it doesn't know. * - * COREDUMP_HEADER must be combined with COREDUMP_KERNEL. + * COREDUMP_HEADER must be combined with COREDUMP_KERNEL, and + * COREDUMP_SPARSE with COREDUMP_HEADER. */ struct coredump_frame_header { __u32 size; -- 2.53.0