From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10594C07E94 for ; Fri, 4 Jun 2021 14:33:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DAB8F613F3 for ; Fri, 4 Jun 2021 14:33:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229881AbhFDOfR (ORCPT ); Fri, 4 Jun 2021 10:35:17 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:58936 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229656AbhFDOfM (ORCPT ); Fri, 4 Jun 2021 10:35:12 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1lpAsz-00AYcY-6V; Fri, 04 Jun 2021 08:33:21 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=email.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 1lpAsx-003ohO-PT; Fri, 04 Jun 2021 08:33:20 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Borislav Petkov Cc: Jiashuo Liang , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , x86@kernel.org, "H. Peter Anvin" , linux-kernel@vger.kernel.org References: <20210601085203.40214-1-liangjs@pku.edu.cn> <87lf7qocsd.fsf@disp2133> Date: Fri, 04 Jun 2021 09:33:12 -0500 In-Reply-To: (Borislav Petkov's message of "Fri, 4 Jun 2021 15:06:59 +0200") Message-ID: <878s3plmxj.fsf@disp2133> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1lpAsx-003ohO-PT;;;mid=<878s3plmxj.fsf@disp2133>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/W0KjWVkzEriQCg2OLrnADsP+D+vNme+Q= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH] signal/x86: Don't send SIGSEGV twice on SEGV_PKUERR X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Borislav Petkov writes: > On Thu, Jun 03, 2021 at 04:31:46PM -0500, Eric W. Biederman wrote: >> There are two ways signals get delivered. The old fashioned way in the >> signal bitmap, and the new fangled way by queuing sigqueue_info. > > By that you mean that third arg siginfo_t to > > SYSCALL_DEFINE3(rt_sigqueueinfo, pid_t, pid, int, sig, > siginfo_t __user *, uinfo) > > I presume? Oh yes. siginfo_t. I don't know why I was thinking sigqueue_info. > Which, as sigqueue(3) says, is what is called on Linux. > >> In the old fashioned way there is no information except that the >> signal itself was delivered, and if the signal is sent twice it >> is impossible to find out. In the new fangled way because the >> sigqueue_info can vary between different times a signal is sent you >> can both see that a signal was delivered twice (because there are two >> distinct entries in the queue), but also possibly tell those two times >> a signal was sent apart. >> >> The new real time signals can queue as many sigqueue_info's as their >> rlimit allows. The old signals are limited to exactly one sigqueue_info >> per signal number. > > Aha. > >> In this case the legacy_queue check tests to see if the signal is >> already pending (present in the signal bitmap) and not a new real time >> signal (which means only one sigqueue_info entry is allowed in the >> signal queue). > > Aha, that sigismember() call in legacy_queue(). > >> Or in short I think everything turns out ok because the first signal is >> delivered, and the second just happens to get dropped as a duplicate by >> __send_signal. > > Right, it is a SIGSEGV in both cases. So it is a legacy signal, and > that'll get marked in that sigset->sig array. Which is per task... ok. > >> That is fragile and confusing to depend on so we should just fix the >> code to not send the wrong signal. > > Yap. > >> I hope that clears things up. > > Very much so, thanks for taking the time! No worries. It was my bug in the first place. At some point I just figured someone needs to take the time to understand the linux signal handling and get as many bugs out as we can. It may not be flashy but it is one of those core things that everything is built on so we need code that works. Eric