From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (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 D14591FECCD for ; Fri, 3 Jul 2026 20:16:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=166.70.13.231 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783109809; cv=none; b=eI+nUfvM0xSBvMwM1ht36H+xCsULAXvNzQyVJYKw1/82dStsetqzeTpchXwcjm/aIhM0jIZTpCYAec0nDyBYZ1z7JMUWgplJ934uigK94A5/TAK2OlTPXj6ZUpd6ttagBa/EXRP6WGxdYVMEtJ+fJuVSLYRO/l+t7MoVQUDUQgk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783109809; c=relaxed/simple; bh=xzhwU6EMGdE/IzKeC6j9RtegfLouthE7Zd+yakAQ3xE=; h=From:To:Cc:In-Reply-To:References:Date:Message-ID:MIME-Version: Content-Type:Subject; b=TLZG1fg4MHJ2zopHzuGX++US4lmBXYhc4TnDaRLpM3WLxBuIbdGQcq3s2ckohpny+QUAOiKUDhlDKWykVrZMvq9/n17oc1xtrKJU+oPF9W4JKip/w8/dFo0vUUwJC86IO/v08wb7/8qFVt0ldbfoChg4jehmx3e89KhtKpX7xI0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=xmission.com; spf=pass smtp.mailfrom=xmission.com; dkim=pass (1024-bit key) header.d=xmission.com header.i=@xmission.com header.b=sfD7M3wl; arc=none smtp.client-ip=166.70.13.231 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=xmission.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=xmission.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=xmission.com header.i=@xmission.com header.b="sfD7M3wl" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=xmission.com; s=xmission; h=Subject:Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xzhwU6EMGdE/IzKeC6j9RtegfLouthE7Zd+yakAQ3xE=; b=sfD7M3wl1osTh76cB5wiw2HYyJ jI4zwsu5ewcM1cq5m5ZB+WjiOecagUWt/i2/oLQ7DwZZ4esMAnC+ITZ7pm8E5rEuJvVdCMAnQCyoS mzJe73eh1ZhgYl7TRavXVrHHdSXgLy6rFx84kRbCPUHUV28AaWZ7fbdlkf9E67n0ycTg=; Received: from in02.mta.xmission.com ([166.70.13.52]:37722) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1wfkJT-00H8wG-Iu; Fri, 03 Jul 2026 14:16:39 -0600 Received: from ip72-198-198-28.om.om.cox.net ([72.198.198.28]:41284 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1wfkJS-000Yvp-Jm; Fri, 03 Jul 2026 14:16:39 -0600 From: "Eric W. Biederman" To: Oleg Nesterov Cc: Andrew Morton , Andy Lutomirski , Kees Cook , Kusaram Devineni , Peter Zijlstra , Thomas Gleixner , Will Drewry , linux-kernel@vger.kernel.org, Linus Torvalds In-Reply-To: (Oleg Nesterov's message of "Thu, 2 Jul 2026 12:36:31 +0200") References: <87o6gx9rc4.fsf@email.froward.int.ebiederm.org> <877bnh7tnf.fsf@email.froward.int.ebiederm.org> <875x315jh0.fsf@email.froward.int.ebiederm.org> Date: Fri, 03 Jul 2026 15:16:32 -0500 Message-ID: <87ldbr4yn3.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1wfkJS-000Yvp-Jm;;;mid=<87ldbr4yn3.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=72.198.198.28;;;frm=ebiederm@xmission.com;;;sPfnum=0;;;sPf=pass X-XM-AID: U2FsdGVkX1/p2NT0uoPDr2PPvg3ch5X9VpIv+MGoOZg= X-Spam-Level: * X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.1 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5003] * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.2 XM_B_SpammyWords One or more commonly used spammy words X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 521 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 11 (2.0%), b_tie_ro: 9 (1.8%), parse: 0.96 (0.2%), extract_message_metadata: 12 (2.3%), get_uri_detail_list: 1.95 (0.4%), tests_pri_-2000: 13 (2.4%), tests_pri_-1000: 2.6 (0.5%), tests_pri_-950: 1.19 (0.2%), tests_pri_-900: 1.00 (0.2%), tests_pri_-90: 80 (15.4%), check_bayes: 78 (15.1%), b_tokenize: 8 (1.5%), b_tok_get_all: 8 (1.6%), b_comp_prob: 2.5 (0.5%), b_tok_touch_all: 56 (10.7%), b_finish: 1.14 (0.2%), tests_pri_0: 378 (72.6%), check_dkim_signature: 0.55 (0.1%), check_dkim_adsp: 2.7 (0.5%), poll_dns_idle: 0.87 (0.2%), tests_pri_10: 2.6 (0.5%), tests_pri_500: 17 (3.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/11] Short circuit delivery for coredump signals X-SA-Exim-Connect-IP: 166.70.13.52 X-SA-Exim-Rcpt-To: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, wad@chromium.org, tglx@kernel.org, peterz@infradead.org, kusaram@devineni.in, kees@kernel.org, luto@kernel.org, akpm@linux-foundation.org, oleg@redhat.com X-SA-Exim-Mail-From: ebiederm@xmission.com X-SA-Exim-Scanned: No (on out01.mta.xmission.com); SAEximRunCond expanded to false Oleg Nesterov writes: > On 06/29, Eric W. Biederman wrote: >> >> "Eric W. Biederman" writes: >> >> > Oleg Nesterov writes: >> > >> >> if (signal->flags & SIGNAL_GROUP_EXIT) { >> >> if (signal->core_state) >> >> return sig == SIGKILL; >> >> /* >> >> * The process is in the middle of dying, drop the signal. >> >> */ >> >> return false; >> >> >> >> This means that if SIGKILL comes before coredump_begin() sets signal->core_state, >> >> it will be lost. >> > >> > I will reexamine that. I used to have something to deal with this case >> > but somehow convinced myself it didn't matter. >> >> I was thinking of another related problem. >> >> In this case loosing SIGKILL before coredump_begin seems fine. The process >> is already dying of a signal. > > Hmm. I disagree... > >> The only point of supporting SIGKILL at all during a coredump is because >> writing the coredump out can be slow. So SIGKILL in that case just >> aborts the coredump. > > Yes, the coredumping process is not dead. Yet. It can do a lot of activity > and use a lot of resources. It is semantically dead. Pragmatically I completely agree. >> Do you know of something where userspace actually depends upon >> killing a coredump before it even starts? > > Well. I think a user has all rights to assume that SIGKILL must always > terminate the process asap, the process killed by SIGKILL must not start > the coredumping. If we arrange things so that semantically SIGKILL is delivered before the signal that triggers the coredump, we can do that without semantic complications. The window is tiny enough I am not certain it matters. There are other issues with that part of code as well. Can we please look at all of these issues after I post the next version of my patchset (later today)? I don't think anything else depends upon them. >> There is another corner case I just noticed. >> >> When force_sig_info_to_task is passed HANDLER_EXIT today get_signal >> skips ptrace stops when SA_IMMUTABLE is set. My change did not short >> circuit deliver those signals when the process was ptraced so my last >> change removing SA_IMMUTABLE was premature. > > Yes... and do_sigacttion() between send and delivery... HANDLER_EXIT implies the signal is fatal so there will be no userspace delivery. SA_IMMUTABLE only exists to ensure that when siglock is dropped that userspace won't change the way get_signal delivers the signal. If we can perform short circuited delivery of the fatal signal in all cases then SA_IMMUTABLE becomes unnecessary. Earlier you mentioned that force_sig_info_to_task combined with dequeue_synchronous signal could do a lot better. I looked back at my proof of concept branch and you are quite right. Especially once we can get short circuit delivery for the coredump signals. Eric