From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 1FC1954B1C6; Wed, 9 Sep 2026 16:05:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788969934; cv=none; b=MjNpcTNC0zPKrG5aEuzYIh3iZJJffD5389IWlcYhwCJB5abSDtU5lPvc5S8WRRJ0YllHBUJgmjOmD98zimSqdHtcWpAIvy9Dt49Kwv1ygEigQwRF5IxKUZZ3elGnyD3kGEidycgnW25n3zXue7x64jm6E1vZg+YdTbGFvOUVUcs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788969934; c=relaxed/simple; bh=cDu/EeEV7vknSc9oLwLPJNP3u+P7qVsPdokeNHKqJgU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=s/c20z0fO5dH0TYcKBYXyrvcYDJ7EC23OLLE7x+pU6sZIY2nkUpKMxEHNL/qceb3G+PljV5AZnwpIj7sJkK88n5GnaJiWICAsEQQ70IpYnoJVdL3KesLQ8atZpggKWzi4fB8vez6BOtum5hsWdNPiBYTrsYDDrWbrOk+yudbUhQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=DJ6RaqBT; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="DJ6RaqBT" Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 689B1Wt42665907; Wed, 9 Sep 2026 16:05:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=pp1; bh=BxpIWW pfWt6a5bq/PoqTerqtGwcRCmRL26GVsAZYkak=; b=DJ6RaqBTo5rXc4WJZ3tn9D Kno3K4pRTQN1CQICFG713XBtMcYyCPBDt/vjKgkihtnZgEoZvA1aM1M9JkEsZF3q qH81SCrsbmF23mX0nlz7plGPBTqGfVx5W2RPQ1qtSl4DSKGKX1s/8kuiskFD8OMq WPdgIyyenV+RSXg+6I2XjZ1egSjKamcVhXJw4WNnwVRuFDAJ4KiTlbbdFsnisO2Z VZ0wcNOoPdwJTZWMXYlDl8Aw7yn1ka6sVAZzsBSzliv6JaCBJ2Gnj1DNnI6mwikG R1Cph3r6XlfmYTtf3EJea6zQXQgtLmDUL4U+MfoGvBdrS9ksYF4pgHGGqYsrLfXw == Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4ggbjrxkgn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Sep 2026 16:05:03 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 689FuHdq015849; Wed, 9 Sep 2026 16:05:02 GMT Received: from smtprelay07.fra02v.mail.ibm.com ([9.218.2.229]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gh03yk02h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Sep 2026 16:05:02 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay07.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 689G514W30671324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 9 Sep 2026 16:05:01 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 048E12004E; Wed, 9 Sep 2026 16:05:01 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1F86420040; Wed, 9 Sep 2026 16:04:51 +0000 (GMT) Received: from [9.61.255.18] (unknown [9.61.255.18]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTPS; Wed, 9 Sep 2026 16:04:50 +0000 (GMT) Message-ID: <119b7dab-7eda-4e7e-95c2-a16d975ce8c2@linux.ibm.com> Date: Wed, 9 Sep 2026 21:34:47 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 17/22] coredump: describe the holes when COREDUMP_SPARSE is negotiated To: Christian Brauner , linux-fsdevel@vger.kernel.org Cc: Jacob Lalonde , Josef Bacik , Jann Horn , 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-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <20260820-work-coredump-sparse-v2-0-ba32dd718c51@kernel.org> <20260820-work-coredump-sparse-v2-17-ba32dd718c51@kernel.org> Content-Language: en-US From: R Nageswara Sastry In-Reply-To: <20260820-work-coredump-sparse-v2-17-ba32dd718c51@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=E7T9Y6dl c=1 sm=1 tr=0 ts=6aa183b0 cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=IkcTkHD0fZMA:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=V8glGbnc2Ofi9Qvn3v5h:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=0oirLGmFVzLU5AZUCiwA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA5MDE3OCBTYWx0ZWRfXzFr14SImq1Zw etpmNE52agBAYcn8Aw0AgxPkNu80hrBWrdADHHqm+GX/TGs47C5QWmTaYXaAvx5u/hBgr1aP0jN x36podZJC+pQOTqN6n+NQb4SizlbKlg= X-Proofpoint-ORIG-GUID: 3tq0ggk9puNw5zj6n0W9si4xwHdX5SCK X-Proofpoint-GUID: SzLUF0XWB0_cZWOdbTiLdMd6PLVgMgZM X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA5MDE3OCBTYWx0ZWRfX+NpOTGsU92Gs SsdsX9hD0MgzjGOxKWXjnhaLMXX8OUy85/Dcqwku4+0BvHVVcL4Io40cM87bhXOSPEVtP117H2X 4/hd2+bdNrdBGTCD5gYRlsDX4mGIMcRxEneLmzbkX4W4l8i3/lAm/LFZPTkIgz2Iy7BPr+r7GO0 ESgCU93UCQnkmQ6MeVzFOfd3Pk1FU37cpj/LXRKOZ0tC6ASvSrn3r2BlWwtSU8LXVgeijtl9woq BqrLUfKQf9/E2o5W/ffpJQo8UqnhByQ/ovtBxHa7CIYrF9Hwme5cSYpOkz/ZA9bOYfssb5h81vH UmL3rg9dp9GK43TzR8hASlszzlZSJYYMz1J2eqzLNicX1ZBJ1URNLJpN31wZykg1vHesjT5yMCp XAFn9SCH69tqaVDhB1Bz7yIjcPkn15Nh6ZEYEpofThqiVGEemWjnuQI7qo2nk4s/q26LYonPGjt Nabsq5GxjyvWACfVuzw== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-08_03,2026-09-09_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 phishscore=0 spamscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609090178 On 20.08.2026 4:39 AM, Christian Brauner wrote: > Make use of COREDUMP_SPARSE. Refuse it without COREDUMP_RECORDS. > > Actual holes are sent as a record with length indicating how much zero > data there was. > > coredump_write() flushes a trailing hole if the coredump is done. > Instead of writing the actual byte for pipes and sockets, collapse it. > This stops wasting a header with coredump records for a single byte. So > we now only write it when the coredump can be seeked. TL;DR a trailing > hole is a zero record like any other and the records still cover the > whole coredump. > > Signed-off-by: Christian Brauner (Amutable) Tested-by: R Nageswara Sastry System: ppc64le LPAR (IBM POWER), Linux 7.3-rc2 > --- > fs/coredump.c | 41 +++++++++++++++++----- > .../selftests/coredump/coredump_test_helpers.c | 3 +- > 2 files changed, 35 insertions(+), 9 deletions(-) > > diff --git a/fs/coredump.c b/fs/coredump.c > index b1679930094c..7b568d25887c 100644 > --- a/fs/coredump.c > +++ b/fs/coredump.c > @@ -68,6 +68,7 @@ > static bool dump_vma_snapshot(struct coredump_params *cprm); > static void free_vma_snapshot(struct coredump_params *cprm); > static void dump_end_record(struct coredump_params *cprm); > +static bool dump_flush_skip(struct coredump_params *cprm); > > #define CORE_FILE_NOTE_SIZE_DEFAULT (4*1024*1024) > /* Define a reasonable max cap */ > @@ -806,7 +807,7 @@ static bool coredump_sock_request(struct core_name *cn, struct coredump_params * > .size = sizeof(struct coredump_req), > .mask = COREDUMP_KERNEL | COREDUMP_USERSPACE | > COREDUMP_REJECT | COREDUMP_WAIT | > - COREDUMP_RECORDS, > + COREDUMP_RECORDS | COREDUMP_SPARSE, > .size_ack = sizeof(struct coredump_ack), > }; > struct coredump_ack ack = {}; > @@ -866,6 +867,12 @@ static bool coredump_sock_request(struct core_name *cn, struct coredump_params * > return false; > } > > + /* Zero records only exist inside a record stream. */ > + if ((ack.mask & COREDUMP_SPARSE) && !(ack.mask & COREDUMP_RECORDS)) { > + coredump_sock_mark(cprm->file, COREDUMP_MARK_CONFLICTING); > + return false; > + } > + > /* Record header scratch; a bvec can't point at the stack. */ > if (ack.mask & COREDUMP_RECORDS) { > cprm->record_hdr = kmalloc_obj(*cprm->record_hdr); > @@ -1076,15 +1083,21 @@ static bool coredump_write(struct coredump_params *cprm, > if (!binfmt->core_dump(cprm)) > cprm->state |= COREDUMP_STATE_TRUNCATED; > /* > - * Ensures that file size is big enough to contain the current > - * file position. This prevents gdb from complaining about > - * a truncated file if the last "write" to the file was > - * dump_skip. A record stream relies on it too: the flush > - * emits the records that cover a trailing hole. > + * A trailing hole still has to land in the coredump. Seeking over > + * it doesn't grow the file, so the last byte of it is written > + * instead and gdb doesn't see a truncated file. Everything else > + * puts the hole on the wire as it flushes it. > */ > if (cprm->to_skip) { > - cprm->to_skip--; > - if (!dump_emit(cprm, "", 1)) > + bool flushed; > + > + if (cprm->file->f_mode & FMODE_LSEEK) { > + cprm->to_skip--; > + flushed = dump_emit(cprm, "", 1); > + } else { > + flushed = dump_flush_skip(cprm); > + } > + if (!flushed) > cprm->state |= COREDUMP_STATE_TRUNCATED; > } > dump_end_record(cprm); > @@ -1241,6 +1254,11 @@ static bool dump_records(const struct coredump_params *cprm) > return cprm->mask & COREDUMP_RECORDS; > } > > +static bool dump_sparse(const struct coredump_params *cprm) > +{ > + return cprm->mask & COREDUMP_SPARSE; > +} > + > /* Describe the next @len bytes of the coredump. Returns the header size. */ > static size_t dump_record_init(struct coredump_params *cprm, > enum coredump_record_type type, u64 flags, > @@ -1357,6 +1375,13 @@ static bool __dump_skip(struct coredump_params *cprm, size_t nr) > static char zeroes[PAGE_SIZE]; > struct file *file = cprm->file; > > + if (dump_sparse(cprm)) { > + /* Hand the server the length of the hole instead of the hole itself. */ > + if (dump_interrupted()) > + return false; > + return dump_emit_record(cprm, COREDUMP_RECORD_ZERO, 0, nr); > + } > + > if (file->f_mode & FMODE_LSEEK) { > if (dump_interrupted() || vfs_llseek(file, nr, SEEK_CUR) < 0) > return false; > diff --git a/tools/testing/selftests/coredump/coredump_test_helpers.c b/tools/testing/selftests/coredump/coredump_test_helpers.c > index 1c8658f35735..a5b9cde47239 100644 > --- a/tools/testing/selftests/coredump/coredump_test_helpers.c > +++ b/tools/testing/selftests/coredump/coredump_test_helpers.c > @@ -275,7 +275,8 @@ bool send_coredump_ack(int fd, const struct coredump_req *req, > /* Every option the kernel is expected to advertise in coredump_req->mask. */ > #define TEST_REQ_MASK_ALL \ > (COREDUMP_KERNEL | COREDUMP_USERSPACE | \ > - COREDUMP_REJECT | COREDUMP_WAIT | COREDUMP_RECORDS) > + COREDUMP_REJECT | COREDUMP_WAIT | \ > + COREDUMP_RECORDS | COREDUMP_SPARSE) > > bool check_coredump_req(const struct coredump_req *req) > { > -- Thanks and Regards R.Nageswara Sastry