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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5E241C433EF for ; Mon, 3 Jan 2022 18:22:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=PQNYBn2Y/M0tVr+rRF72T304Q3AvpPK7TyCpFcDWMuI=; b=hZVJKbMXNfzyFF OjjJ8S8is2a0H4iXzd6G1FqNuvSxCavwOF+6cGVk6gPoMQY4GSnqii6eDslOLm8E4smVnzeEU0BJZ +86CihjHT9DUeanHRpc1Df1Nxo6LwgkYBCC1JzPCyOcbZQV/J2MeqhoPKrZC+YvaqrXuuq1Wel93O mvVF4GeiElERkQJLiPC0FynqJDUwW3538UyfIpXUpH181dhj9r8+UG1N13qHeZeRFGgxjRSumjTH4 OW6CT+epUlcwzqcTht7ZrB8uEvh08fYchugGRzioQwhKHWyWIXb1d/zdndFkX1+8Dth4s9+0HjxVD 7fXrwbiAzbmByRHb44dA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n4Rxr-009oGL-DW; Mon, 03 Jan 2022 18:21:47 +0000 Received: from drummond.us ([74.95.14.229] helo=talisker.home.drummond.us) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1n4Rxn-009oFK-DG for linux-mtd@lists.infradead.org; Mon, 03 Jan 2022 18:21:45 +0000 Received: from talisker.home.drummond.us (localhost [127.0.0.1]) by talisker.home.drummond.us (8.15.2/8.15.2/Debian-20) with ESMTP id 203IKUrZ983478; Mon, 3 Jan 2022 10:20:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=home.drummond.us; s=default; t=1641234030; bh=E5fnl6UDJWZKDRpYiS+tfaqNC1+q8ROkLPZx/9dIiQE=; h=From:To:Cc:Subject:Date:From; b=zXbbImMEGQ9pUpv1DxfY2XmQttregvHgLm+qsl9EG8U8kPMhSbyKD5DQ25UYOdRzo BfoL/P72aybwUNV/dOsh0KUrU+F+6X19Cgfu7MENmFok86fj7YBUHIKHTe6B3r/2l0 iFHFBcYB/awOvzTkhHjnaPiTR52hfe6PHcBRzY7m0xTugBKuJxGGgsr0nguKo8yqGW 0VW8sn37JwEbBrD9p0qZEb9YsC8UbN/YcXTbNbKSZNHo8cvcUPBLwqbV6LWX9tWvlN QEeMhR0gHOFTcJtLQUs5HTxDDyu0MNDZscXnTgsu1kqViQK/ikejaInqcv0AX04Too CMrZIYqUTCwPQ== Received: (from walt@localhost) by talisker.home.drummond.us (8.15.2/8.15.2/Submit) id 203IKMj7983477; Mon, 3 Jan 2022 10:20:22 -0800 From: Walt Drummond To: aacraid@microsemi.com, viro@zeniv.linux.org.uk, anna.schumaker@netapp.com, arnd@arndb.de, bsegall@google.com, bp@alien8.de, chuck.lever@oracle.com, bristot@redhat.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, dietmar.eggemann@arm.com, dinguyen@kernel.org, geert@linux-m68k.org, gregkh@linuxfoundation.org, hpa@zytor.com, idryomov@gmail.com, mingo@redhat.com, yzaikin@google.com, ink@jurassic.park.msu.ru, jejb@linux.ibm.com, jmorris@namei.org, bfields@fieldses.org, jlayton@kernel.org, jirislaby@kernel.org, john.johansen@canonical.com, juri.lelli@redhat.com, keescook@chromium.org, mcgrof@kernel.org, martin.petersen@oracle.com, mattst88@gmail.com, mgorman@suse.de, oleg@redhat.com, pbonzini@redhat.com, peterz@infradead.org, rth@twiddle.net, richard@nod.at, serge@hallyn.com, rostedt@goodmis.org, tglx@linutronix.de, trond.myklebust@hammerspace.com, vincent.guittot@linaro.org, x86@kernel.org Cc: linux-kernel@vger.kernel.org, Walt Drummond , ceph-devel@vger.kernel.org, kvm@vger.kernel.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-scsi@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [RFC PATCH 0/8] signals: Support more than 64 signals Date: Mon, 3 Jan 2022 10:19:48 -0800 Message-Id: <20220103181956.983342-1-walt@drummond.us> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220103_102143_502155_62153C4C X-CRM114-Status: GOOD ( 30.74 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org VGhpcyBwYXRjaCBzZXQgZXhwYW5kcyB0aGUgbnVtYmVyIG9mIHNpZ25hbHMgaW4gTGludXggYmV5 b25kIHRoZQpjdXJyZW50IGNhcCBvZiA2NC4gIEl0IHNldHMgYSBuZXcgY2FwIGF0IHRoZSBzb21l d2hhdCBhcmJpdHJhcnkgbGltaXQKb2YgMTAyNCBzaWduYWxzLCBib3RoIGJlY2F1c2UgaXTigJlz IHdoYXQgR0xpYmMgYW5kIE1VU0wgc3VwcG9ydCBhbmQKYmVjYXVzZSBtYW55IGFyY2hpdGVjdHVy ZXMgcGFkIHNpZ3NldF90IG9yIHVjb250ZXh0X3QgaW4gdGhlIGtlcm5lbCB0bwp0aGlzIGNhcC4g IFRoaXMgbGltaXQgaXMgbm90IGZpeGVkIGFuZCBjYW4gYmUgZnVydGhlciBleHBhbmRlZCB3aXRo aW4KcmVhc29uLgoKRGVzcGl0ZSBiZXN0IGVmZm9ydHMsIHRoZXJlIGlzIHNvbWUgbm9uLXplcm8g cG90ZW50aWFsIHRoYXQgdGhpcyBjb3VsZApicmVhayB1c2VyIHNwYWNlOyBJJ2QgYXBwcmVjaWF0 ZSBhbnkgY29tbWVudHMsIHJldmlldyBhbmQvb3IgcG9pbnRlcnMKdG8gYXJlYXMgb2YgY29uY2Vy bi4KCkJhc2ljYWxseSwgdGhlc2UgY2hhbmdlcyBlbnRhaWw6CgogLSBNYWtlIGFsbCBzeXN0ZW0g Y2FsbHMgdGhhdCBhY2NlcHQgc2lnc2V0X3QgaG9ub3IgdGhlIGV4aXN0aW5nCiAgIHNpZ3NldHNp emUgcGFyYW1ldGVyIGZvciB2YWx1ZXMgYmV0d2VlbiA4IGFuZCAxMjgsIGFuZCB0byByZXR1cm4K ICAgc2lnc2V0c2l6ZSBieXRlcyB0byB1c2VyIHNwYWNlLgoKIC0gQWRkIEFUX1NJR1NFVF9TWiB0 byB0aGUgYXV4IHZlY3RvciB0byBzaWduYWwgdG8gdXNlciBzcGFjZSB0aGUKICAgbWF4aW11bSBz aXplIHNpZ3NldF90IHRoZSBrZXJuZWwgY2FuIGFjY2VwdC4KCiAtIFJlbW92ZSB0aGUgc2lnbWFz aygpIG1hY3JvIGV4Y2VwdCBpbiBjb21wYXRpYmlsaXR5IGNhc2VzLCBjaGFuZ2UKICAgdGhlIHNp Z2FkZHNldCgpL3NpZ2RlbHNldCgpL2V0Yy4gdG8gYWNjZXB0IGEgY29tbWEgc2VwYXJhdGVkIGxp c3QKICAgb2Ygc2lnbmFsIG51bWJlcnMuCgogLSBDaGFuZ2UgdGhlIF9OU0lHX1dPUkRTIGNhbGN1 bGF0aW9uIHRvIHJvdW5kIHVwIHdoZW4gbmVlZGVkIG9uCiAgIGdlbmVyaWMgYW5kIHg4Ni4KCiAt IFBsYWNlIHRoZSBjb21wbGV0ZSBzaWdtYXNrIGluIHRoZSByZWFsIHRpbWUgc2lnbmFsIGZyYW1l ICh4ODZfNjQsCiAgIHgzMiBhbmQgaWEzMikuCgogLSBWYXJpb3VzIGZpeGVzIHdoZXJlIHNpZ3Nl dF90IHNpemUgaXMgYXNzdW1lZC4KCiAtIEFkZCBCU0QgU0lHSU5GTyAoYW5kIFZTVEFUVVMpIGFz IGEgdGVzdC4KClRoZSBjaGFuZ2VzIHRoYXQgaGF2ZSB0aGUgbW9zdCByaXNrIG9mIGJyZWFraW5n IHVzZXIgc3BhY2UgYXJlIHRoZQpvbmVzIHRoYXQgcHV0IG1vcmUgdGhhbiA4IGJ5dGVzIG9mIHNp Z3NldF90IGluIHRoZSByZWFsIHRpbWUgc2lnbmFsCnN0YWNrIGZyYW1lIChQYXRjaGVzIDIgJiA2 KSwgYW5kIEkgc2hvdWxkIG5vdGUgdGhhdCBhbiBlYXJsaWVyIGFuZAppbmNvbXBsZXRlIHZlcnNp b24gb2YgcGF0Y2ggMiB3YXMgTkFL4oCZZWQgYnkgQWwgaW4KaHR0cHM6Ly9sb3JlLmtlcm5lbC5v cmcvbGttbC8yMDIwMTExOTIyMTEzMi4xNTE1Njk2LTEtd2FsdEBkcnVtbW9uZC51cy8uCgpBcyBm YXIgYXMgSSBoYXZlIGJlZW4gYWJsZSB0byBkZXRlcm1pbmUgdGhpcyBwYXRjaHNldCwgYW5kCnNw ZWNpZmljYWxseSBjaGFuZ2luZyB0aGUgc2l6ZSBvZiBzaWdzZXRfdCwgZG9lcyBub3QgYnJlYWsg dXNlciBzcGFjZS4KClRoZSB0d28gdXNlcyBvZiBzaWdzZXRfdCB0aGF0IHBvc2UgdGhlIG1vc3Qg dXNlciBzcGFjZSByaXNrIGFyZSAxKSBhcwphIG1lbWJlciBvZiB1Y29udGV4dF90IHBhc3NlZCBh cyBhIHBhcmFtZXRlciB0byB0aGUgc2lnbmFsIGhhbmRsZXIgYW5kCjIpIHdoZW4gdXNlciBzcGFj ZSBwZXJmb3JtcyBtYW51YWwgaW5zcGVjdGlvbiBvZiB0aGUgcmVhbC10aW1lIHNpZ25hbApzdGFj ayBmcmFtZS4KCkluIGNhc2UgKDEpLCB1c2VyIHNwYWNlIGhhcyBkZWZpbml0aW9ucyBvZiBib3Ro IHNpZ2V0X3QgYW5kIHVjb250ZXh0X3QKdGhhdCBhcmUgaW5kZXBlbmRlbnQgb2YsIGFuZCBtYXkg ZGlmZmVyIGZyb20sIHRoZSBrZXJuZWwgKGVnLCBzaWdzZXRfdAppbiB1Y2xpYmMtbmcgaXMgMTYg Ynl0ZXMsIG11c2wgaXMgMTI4IGJ5dGVzLCBnbGliYyBpcyAxMjggYnl0ZXMgb24gYWxsCmFyY2hp dGVjdHVyZXMgZXhjZXB0IEFyYywgZXRjLikuICBVc2VyIHNwYWNlIHdpbGwgaW50ZXJwcmV0IHRo ZSBkYXRhCm9uIHRoZSBzaWduYWwgc3RhY2sgdGhyb3VnaCB0aGVzZSBkZWZpbml0aW9ucywgYW5k IGV4dGVuc2lvbnMgdG8Kc2lnc2V0X3Qgd2lsbCBiZSBvcGFxdWUuICBPdGhlciBub24tQyBydW50 aW1lcyBhcmUgc2ltaWxhcmx5CmluZGVwZW5kZW50IGZyb20ga2VybmVsIHNpZ3NldF90IGFuZCB1 Y29udGV4dF90IGFuZCBkZXJpdmUgdGhlaXIKZGVmaW5pdGlvbiBvZiBzaWdzZXRfdCBmcm9tIGxp YmMgZWl0aGVyIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIGFuZCBkbwpub3QgbWFudWFsbHkgaW5z cGVjdCB0aGUgc2lnbmFsIHN0YWNrIChzcGVjaWZpY2FsbHkgT3BlbkpESywgR29sYW5nLApQeXRo b24zLCBSdXN0IGFuZCBQZXJsKS4KClRoZSBvbmx5IGluc3RhbmNlcyBJIGZvdW5kIG9mIGNhc2Ug KDIpLCBtYW51YWxseSBpbnNwZWN0aW5nIHRoZSBzaWduYWwKc3RhY2sgZnJhbWUsIGFyZSBpbiBz dGFjayB1bndpbmRlcnMvYmFja3RyYWNlcnMgKEdEQiwgR0NDLCBsaWJ1bndpbmQpCmFuZCBpbiBH REIgd2hlbiByZWNvcmRpbmcgcHJvZ3JhbSBleGVjdXRpb24sIGFuZCBvbmx5IG9uIHRoZSBpMzg2 LAp4ODZfNjQsIHMzOTAgYW5kIHBvd2VycGMgYXJjaGl0ZWN0dXJlcy4gIFRoZSBHREIsIEdDQyBh bmQgbGlidW53aW5kCmJlaGF2ZSBjb25zaXN0ZW50bHkgd2l0aCBhbmQgd2l0aG91dCB0aGlzIHBh dGNoc2V0LgoKR0RCJ3MgZXhlY3V0aW9uIHJlY29yZGluZyBpcyBzb21ld2hhdCBtb3JlIGNvbXBs aWNhdGVkLiAgSXQgdXNlcwppbnRlcm5hbGx5IGRlZmluZWQgYXJjaGl0ZWN0dXJlIHNwZWNpZmlj IGNvbnN0YW50cyB0byByZXByZXNlbnQgdGhlCnRvdGFsIHNpemUgb2YgdGhlIHNpZ25hbCBmcmFt ZSwgYW5kIHdpbGwgc2F2ZSB0aGF0IGVudGlyZSBmcmFtZSBmb3IKbGF0ZXIgdXNlLiAgSSBjYW5u b3QgY29uZmlybSB0aGF0IHRoZSB2YWx1ZXMgZm9yIHBvd2VycGMgYW5kIHMzOTAgYXJlCmNvcnJl Y3QsIGJ1dCBmb3IgdGhpcyBwdXJwb3NlIGl0IGRvZXNuJ3QgbWF0dGVyIGFzIHRoZXNlIGFyY2hp dGVjdHVyZXMKZXhwbGljaXRseSBwYWQgZm9yIGFuIGV4cGFuZGVkIHVjX3NpZ21hc2suICBJIGNh biwgaG93ZXZlciwgY29uZmlybQp0aGF0IHRoZSB2YWx1ZXMgZm9yIGkzODYgYW5kIHg4Nl82NCBh cmUgbm90IGNvcnJlY3QsIGFuZCB0aGF0IEdEQiBpcwpyZWNvcmRpbmcgYW4gaW5jb3JyZWN0IGFt b3VudCBvZiBzdGFjayBkYXRhLiAgVGhpcyBkb2VzbuKAmXQgYXBwZWFyIHRvCmJlIGFuIGlzc3Vl OyB3aGlsZSBJIGNhbm5vdCBidWlsZCBhIHRlc3QgY2FzZSBvbiB4ODZfNjQgZHVlIHRvIGEga25v d24KYnVnWzFdLCBhIGJhc2ljIHRlc3Qgb24gaTM4NiBzaG93cyB0aGF0IHRoZSBzdGFjayBpcyBj b3JyZWN0bHkgYmVpbmcKcmVjb3JkZWQsIGFuZCBmb3J3YXJkIGFuZCByZXZlcnNlIHJlcGxheSBz ZWVtcyB0byB3b3JrIGp1c3QgZmluZQphY3Jvc3Mgc2lnbmFsIGhhbmRsZXJzLgoKVGhlcmUgYXJl IG90aGVyIGNhc2VzIHRvIGNvbnNpZGVyIGlmIHRoZSBudW1iZXIgb2Ygc2lnbmFscyBhbmQKdGhl cmVmb3JlIHRoZSBzaXplIG9mIHNpZ3NldF90IGNoYW5nZXM6CgpJbXBhY3Qgb24gc3RydWN0IHJ0 X3NpZ2ZyYW1lIG1lbWJlciBlbGVtZW50cwoKICBUaGUgcGxhY2VtZW50IG9mIHVjb250ZXh0X3Qg aW4gc3RydWN0IHJ0X3NpZ2ZyYW1lIGhhcyB0aGUgcG90ZW50aWFsCiAgdG8gbW92ZSBmb2xsb3dp bmcgbWVtYmVyIGVsZW1lbnRzIGluIHdheXMgdGhhdCBjb3VsZCBicmVhayB1c2VyCiAgc3BhY2Ug aWYgdXNlciBzcGFjZSByZWxpZWQgb24gdGhlIG9mZnNldHMgb2YgdGhlc2UgZWxlbWVudHMuCiAg SG93ZXZlciBhIHJldmlldyBzaG93cyB0aGF0IGFueSBlbGVtZW50cyBpbiBydF9zaWdmcmFtZSBh ZnRlcgogIHVjb250ZXh0X3QudWNfc2lnbWFzayBhcmUgZWl0aGVyICgxKSB1bnVzZWQgb3Igb25s eSB1c2VkIGJ5IHRoZQogIGtlcm5lbCBvciAoMikgZmFsbCBpbnRvIHRoZSB4ODZfNjQvaTM4NiBm bG9hdGluZyBwb2ludCBzdGF0ZSBjYXNlCiAgYWJvdmUuCgpLZXJuZWwgaGFzIG5ldyBzaWduYWxz LCB1c2VyIHNwYWNlIGRvZXMgbm90CgogIEFueSBuZXcgYml0cyBpbiB1Y29udGV4dC51Y19zaWdt YXNrIHBsYWNlZCBvbiB0aGUgc2lnbmFsIHN0YWNrIGFyZQogIG9wYXF1ZSB0byB1c2VyIHNwYWNl IChleGNlcHQgaW4gY2FzZXMgd2hlcmUgdXNlciBzcGFjZSBhbHJlYWR5IGhhcyBhCiAgbGFyZ2Vy IHNpZ3NldF90LCBhcyBpbiBnbGliYykuCgogIFRoZXJlIGFyZSBubyBjaGFuZ2VzIHRvIHRoZSBy ZWFsLXRpbWUgc2lnbmFscyBzeXN0ZW0gY2FsbCBzZW1hbnRpY3MsCiAgYXMgdGhlIGtlcm5lbCB3 aWxsIGhvbm9yIHRoZSBoYXJkLWNvZGVkIHNpZ3NldHNpemUgdmFsdWUgb2YgOCBpbgogIGxpYmMg YW5kIGJlaGF2ZSBhcyBpdCBoYXMgYmVmb3JlIHRoZXNlIGNoYW5nZXMuCgogIFNpZ25hbCBudW1i ZXJzIGxhcmdlciB0aGFuIDY0IGNhbm5vdCBiZSBibG9ja2VkIG9yIGNhdWdodCB1bnRpbCB1c2Vy CiAgc3BhY2UgaXMgdXBkYXRlZCwgaG93ZXZlciB0aGVpciBkZWZhdWx0IGFjdGlvbiB3aWxsIHdv cmsgYXMKICBleHBlY3RlZC4gIFRoaXMgY2FuIGNhdXNlIG9uZSBwcm9ibGVtOiBhIHBhcmVudCBw cm9jZXNzIHRoYXQgdXNlcwogIHRoZSBzaWduYWwgbnVtYmVyIGEgY2hpbGQgZXhpdGVkIHdpdGgg YXMgYW4gaW5kZXggaW50byBhbiBhcnJheQogIHdpdGhvdXQgYm91bmRzIGNoZWNraW5nIGNhbiBj YXVzZSBhIGNyYXNoLiAgSeKAmXZlIHNlZW4gZXhhY3RseSBvbmUKICBpbnN0YW5jZSBvZiB0aGlz IGluIHRjc2gsIGFuZCBpcywgSSB0aGluaywgYSBidWcgaW4gdGNzaC4KClVzZXIgc3BhY2UgaGFz IG5ldyBzaWduYWxzLCBrZXJuZWwgZG9lcyBub3QKCiAgVXNlciBzcGFjZSBhdHRlbXB0aW5nIHRv IHVzZSBhIHNpZ25hbCBudW1iZXIgbm90IHN1cHBvcnRlZCBieSB0aGUKICBrZXJuZWwgaW4gc3lz dGVtIGNhbGxzIChlZywgc2lnYWN0aW9uKCkpIG9yIG90aGVyIGxpYmMgZnVuY3Rpb25zIChlZywK ICBzaWdhZGRzZXQoKSkgd2lsbCByZXN1bHQgaW4gRUlOVkFMLCBhcyBleHBlY3RlZC4KCiAgVXNl ciBzcGFjZSBuZWVkcyB0byBrbm93IGhvdyB0byBzZXQgdGhlIHNpZ3NldHNpemUgcGFyYW1ldGVy IHRvIHRoZQogIHJlYWwgdGltZSBzaWduYWwgc3lzdGVtIGNhbGxzIGFuZCBpdCBjYW4gdXNlIGdl dGF1eHZhbChBVF9TSUdTRVRfU1opCiAgdG8gZGV0ZXJtaW5lIHRoaXMuICBJZiBpdCByZXR1cm5z IHplcm8gdGhlIHNpZ3NldHNpemUgbXVzdCBiZSA4LAogIG90aGVyd2lzZSB0aGUga2VybmVsIHdp bGwgYWNjZXB0IHNpZ3NldHNpemUgYmV0d2VlbiA4IGFuZCB0aGUgcmV0dXJuCiAgdmFsdWUuCgpb MV0gaHR0cHM6Ly9zb3VyY2V3YXJlLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjMxODgK CldhbHQgRHJ1bW1vbmQgKDgpOgogIHNpZ25hbHM6IE1ha2UgdGhlIHJlYWwtdGltZSBzaWduYWwg c3lzdGVtIGNhbGxzIGFjY2VwdCBkaWZmZXJlbnQgc2l6ZWQKICAgIHNpZ3NldF90IGZyb20gdXNl ciBzcGFjZS4KICBzaWduYWxzOiBQdXQgdGhlIGZ1bGwgc2lnbmFsIG1hc2sgb24gdGhlIHNpZ25h bCBzdGFjayBmb3IgeDg2XzY0LCBYMzIKICAgIGFuZCBpYTMyIGNvbXBhdGliaWxpdHkgbW9kZQog IHNpZ25hbHM6IFVzZSBhIGhlbHBlciBmdW5jdGlvbiB0byB0ZXN0IGlmIGEgc2lnbmFsIGlzIGEg cmVhbC10aW1lCiAgICBzaWduYWwuCiAgc2lnbmFsczogUmVtb3ZlIHNpZ21hc2soKSBtYWNybwog IHNpZ25hbHM6IEJldHRlciBzdXBwb3J0IGNhc2VzIHdoZXJlIF9OU0lHX1dPUkRTIGlzIGdyZWF0 ZXIgdGhhbiAyCiAgc2lnbmFsczogUm91bmQgdXAgX05TSUdfV09SRFMKICBzaWduYWxzOiBBZGQg c2lnbmFsIGRlYnVnZ2luZwogIHNpZ25hbHM6IFN1cHBvcnQgQlNEIFZTVEFUVVMsIEtFUk5JTkZP IGFuZCBTSUdJTkZPCgogYXJjaC9hbHBoYS9rZXJuZWwvc2lnbmFsLmMgICAgICAgICAgfCAgIDQg Ky0KIGFyY2gvbTY4ay9pbmNsdWRlL2FzbS9zaWduYWwuaCAgICAgIHwgICA2ICstCiBhcmNoL25p b3MyL2tlcm5lbC9zaWduYWwuYyAgICAgICAgICB8ICAgMiAtCiBhcmNoL3g4Ni9pYTMyL2lhMzJf c2lnbmFsLmMgICAgICAgICB8ICAgNSArLQogYXJjaC94ODYvaW5jbHVkZS9hc20vc2lnaGFuZGxp bmcuaCAgfCAgMzQgKysrCiBhcmNoL3g4Ni9pbmNsdWRlL2FzbS9zaWduYWwuaCAgICAgICB8ICAx MCArLQogYXJjaC94ODYvaW5jbHVkZS91YXBpL2FzbS9zaWduYWwuaCAgfCAgIDQgKy0KIGFyY2gv eDg2L2tlcm5lbC9zaWduYWwuYyAgICAgICAgICAgIHwgIDExICstCiBkcml2ZXJzL3Njc2kvZHB0 aS5oICAgICAgICAgICAgICAgICB8ICAgMiAtCiBkcml2ZXJzL3R0eS9NYWtlZmlsZSAgICAgICAg ICAgICAgICB8ICAgMiArLQogZHJpdmVycy90dHkvbl90dHkuYyAgICAgICAgICAgICAgICAgfCAg MjEgKysKIGRyaXZlcnMvdHR5L3R0eV9pby5jICAgICAgICAgICAgICAgIHwgIDEwICstCiBkcml2 ZXJzL3R0eS90dHlfaW9jdGwuYyAgICAgICAgICAgICB8ICAgNCArCiBkcml2ZXJzL3R0eS90dHlf c3RhdHVzLmMgICAgICAgICAgICB8IDEzNSArKysrKysrKysrCiBmcy9iaW5mbXRfZWxmLmMgICAg ICAgICAgICAgICAgICAgICB8ICAgMSArCiBmcy9iaW5mbXRfZWxmX2ZkcGljLmMgICAgICAgICAg ICAgICB8ICAgMSArCiBmcy9jZXBoL2FkZHIuYyAgICAgICAgICAgICAgICAgICAgICB8ICAgMiAr LQogZnMvamZmczIvYmFja2dyb3VuZC5jICAgICAgICAgICAgICAgfCAgIDIgKy0KIGZzL2xvY2tk L3N2Yy5jICAgICAgICAgICAgICAgICAgICAgIHwgICAxIC0KIGZzL3Byb2MvYXJyYXkuYyAgICAg ICAgICAgICAgICAgICAgIHwgIDMyICstLQogZnMvcHJvYy9iYXNlLmMgICAgICAgICAgICAgICAg ICAgICAgfCAgNDggKysrKwogZnMvc2lnbmFsZmQuYyAgICAgICAgICAgICAgICAgICAgICAgfCAg MjYgKy0KIGluY2x1ZGUvYXNtLWdlbmVyaWMvdGVybWlvcy5oICAgICAgIHwgICA0ICstCiBpbmNs dWRlL2xpbnV4L2NvbXBhdC5oICAgICAgICAgICAgICB8ICA5OCArKysrKystCiBpbmNsdWRlL2xp bnV4L3NjaGVkLmggICAgICAgICAgICAgICB8ICA1MiArKystCiBpbmNsdWRlL2xpbnV4L3NpZ25h bC5oICAgICAgICAgICAgICB8IDM4OSArKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tCiBpbmNs dWRlL2xpbnV4L3R0eS5oICAgICAgICAgICAgICAgICB8ICAgOCArCiBpbmNsdWRlL3VhcGkvYXNt LWdlbmVyaWMvaW9jdGxzLmggICB8ICAgMiArCiBpbmNsdWRlL3VhcGkvYXNtLWdlbmVyaWMvc2ln bmFsLmggICB8ICAgOCArLQogaW5jbHVkZS91YXBpL2FzbS1nZW5lcmljL3Rlcm1iaXRzLmggfCAg MzQgKy0tCiBpbmNsdWRlL3VhcGkvbGludXgvYXV4dmVjLmggICAgICAgICB8ICAgMSArCiBrZXJu ZWwvY29tcGF0LmMgICAgICAgICAgICAgICAgICAgICB8ICAzMCArLS0KIGtlcm5lbC9mb3JrLmMg ICAgICAgICAgICAgICAgICAgICAgIHwgICAyICstCiBrZXJuZWwvcHRyYWNlLmMgICAgICAgICAg ICAgICAgICAgICB8ICAxOCArLQoga2VybmVsL3NpZ25hbC5jICAgICAgICAgICAgICAgICAgICAg fCAyODggKysrKysrKysrKy0tLS0tLS0tLS0KIGtlcm5lbC9zeXNjdGwuYyAgICAgICAgICAgICAg ICAgICAgIHwgIDQxICsrKwoga2VybmVsL3RpbWUvcG9zaXgtdGltZXJzLmMgICAgICAgICAgfCAg IDMgKy0KIGxpYi9LY29uZmlnLmRlYnVnICAgICAgICAgICAgICAgICAgIHwgIDEwICsKIHNlY3Vy aXR5L2FwcGFybW9yL2lwYy5jICAgICAgICAgICAgIHwgICA0ICstCiB2aXJ0L2t2bS9rdm1fbWFp bi5jICAgICAgICAgICAgICAgICB8ICAxOCArLQogNDAgZmlsZXMgY2hhbmdlZCwgOTc0IGluc2Vy dGlvbnMoKyksIDM5OSBkZWxldGlvbnMoLSkKIGNyZWF0ZSBtb2RlIDEwMDY0NCBkcml2ZXJzL3R0 eS90dHlfc3RhdHVzLmMKCi0tIAoyLjMwLjIKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBs aXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRk Lwo= 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12BFDC433F5 for ; Mon, 3 Jan 2022 18:36:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235840AbiACSgK (ORCPT ); Mon, 3 Jan 2022 13:36:10 -0500 Received: from drummond.us ([74.95.14.229]:40377 "EHLO talisker.home.drummond.us" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S235848AbiACSgG (ORCPT ); Mon, 3 Jan 2022 13:36:06 -0500 X-Greylist: delayed 829 seconds by postgrey-1.27 at vger.kernel.org; Mon, 03 Jan 2022 13:35:51 EST Received: from talisker.home.drummond.us (localhost [127.0.0.1]) by talisker.home.drummond.us (8.15.2/8.15.2/Debian-20) with ESMTP id 203IKUrZ983478; Mon, 3 Jan 2022 10:20:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=home.drummond.us; s=default; t=1641234030; bh=E5fnl6UDJWZKDRpYiS+tfaqNC1+q8ROkLPZx/9dIiQE=; h=From:To:Cc:Subject:Date:From; b=zXbbImMEGQ9pUpv1DxfY2XmQttregvHgLm+qsl9EG8U8kPMhSbyKD5DQ25UYOdRzo BfoL/P72aybwUNV/dOsh0KUrU+F+6X19Cgfu7MENmFok86fj7YBUHIKHTe6B3r/2l0 iFHFBcYB/awOvzTkhHjnaPiTR52hfe6PHcBRzY7m0xTugBKuJxGGgsr0nguKo8yqGW 0VW8sn37JwEbBrD9p0qZEb9YsC8UbN/YcXTbNbKSZNHo8cvcUPBLwqbV6LWX9tWvlN QEeMhR0gHOFTcJtLQUs5HTxDDyu0MNDZscXnTgsu1kqViQK/ikejaInqcv0AX04Too CMrZIYqUTCwPQ== Received: (from walt@localhost) by talisker.home.drummond.us (8.15.2/8.15.2/Submit) id 203IKMj7983477; Mon, 3 Jan 2022 10:20:22 -0800 From: Walt Drummond To: aacraid@microsemi.com, viro@zeniv.linux.org.uk, anna.schumaker@netapp.com, arnd@arndb.de, bsegall@google.com, bp@alien8.de, chuck.lever@oracle.com, bristot@redhat.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, dietmar.eggemann@arm.com, dinguyen@kernel.org, geert@linux-m68k.org, gregkh@linuxfoundation.org, hpa@zytor.com, idryomov@gmail.com, mingo@redhat.com, yzaikin@google.com, ink@jurassic.park.msu.ru, jejb@linux.ibm.com, jmorris@namei.org, bfields@fieldses.org, jlayton@kernel.org, jirislaby@kernel.org, john.johansen@canonical.com, juri.lelli@redhat.com, keescook@chromium.org, mcgrof@kernel.org, martin.petersen@oracle.com, mattst88@gmail.com, mgorman@suse.de, oleg@redhat.com, pbonzini@redhat.com, peterz@infradead.org, rth@twiddle.net, richard@nod.at, serge@hallyn.com, rostedt@goodmis.org, tglx@linutronix.de, trond.myklebust@hammerspace.com, vincent.guittot@linaro.org, x86@kernel.org Cc: linux-kernel@vger.kernel.org, Walt Drummond , ceph-devel@vger.kernel.org, kvm@vger.kernel.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-scsi@vger.kernel.org, linux-security-module@vger.kernel.org Subject: [RFC PATCH 0/8] signals: Support more than 64 signals Date: Mon, 3 Jan 2022 10:19:48 -0800 Message-Id: <20220103181956.983342-1-walt@drummond.us> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch set expands the number of signals in Linux beyond the current cap of 64. It sets a new cap at the somewhat arbitrary limit of 1024 signals, both because it’s what GLibc and MUSL support and because many architectures pad sigset_t or ucontext_t in the kernel to this cap. This limit is not fixed and can be further expanded within reason. Despite best efforts, there is some non-zero potential that this could break user space; I'd appreciate any comments, review and/or pointers to areas of concern. Basically, these changes entail: - Make all system calls that accept sigset_t honor the existing sigsetsize parameter for values between 8 and 128, and to return sigsetsize bytes to user space. - Add AT_SIGSET_SZ to the aux vector to signal to user space the maximum size sigset_t the kernel can accept. - Remove the sigmask() macro except in compatibility cases, change the sigaddset()/sigdelset()/etc. to accept a comma separated list of signal numbers. - Change the _NSIG_WORDS calculation to round up when needed on generic and x86. - Place the complete sigmask in the real time signal frame (x86_64, x32 and ia32). - Various fixes where sigset_t size is assumed. - Add BSD SIGINFO (and VSTATUS) as a test. The changes that have the most risk of breaking user space are the ones that put more than 8 bytes of sigset_t in the real time signal stack frame (Patches 2 & 6), and I should note that an earlier and incomplete version of patch 2 was NAK’ed by Al in https://lore.kernel.org/lkml/20201119221132.1515696-1-walt@drummond.us/. As far as I have been able to determine this patchset, and specifically changing the size of sigset_t, does not break user space. The two uses of sigset_t that pose the most user space risk are 1) as a member of ucontext_t passed as a parameter to the signal handler and 2) when user space performs manual inspection of the real-time signal stack frame. In case (1), user space has definitions of both siget_t and ucontext_t that are independent of, and may differ from, the kernel (eg, sigset_t in uclibc-ng is 16 bytes, musl is 128 bytes, glibc is 128 bytes on all architectures except Arc, etc.). User space will interpret the data on the signal stack through these definitions, and extensions to sigset_t will be opaque. Other non-C runtimes are similarly independent from kernel sigset_t and ucontext_t and derive their definition of sigset_t from libc either directly or indirectly, and do not manually inspect the signal stack (specifically OpenJDK, Golang, Python3, Rust and Perl). The only instances I found of case (2), manually inspecting the signal stack frame, are in stack unwinders/backtracers (GDB, GCC, libunwind) and in GDB when recording program execution, and only on the i386, x86_64, s390 and powerpc architectures. The GDB, GCC and libunwind behave consistently with and without this patchset. GDB's execution recording is somewhat more complicated. It uses internally defined architecture specific constants to represent the total size of the signal frame, and will save that entire frame for later use. I cannot confirm that the values for powerpc and s390 are correct, but for this purpose it doesn't matter as these architectures explicitly pad for an expanded uc_sigmask. I can, however, confirm that the values for i386 and x86_64 are not correct, and that GDB is recording an incorrect amount of stack data. This doesn’t appear to be an issue; while I cannot build a test case on x86_64 due to a known bug[1], a basic test on i386 shows that the stack is correctly being recorded, and forward and reverse replay seems to work just fine across signal handlers. There are other cases to consider if the number of signals and therefore the size of sigset_t changes: Impact on struct rt_sigframe member elements The placement of ucontext_t in struct rt_sigframe has the potential to move following member elements in ways that could break user space if user space relied on the offsets of these elements. However a review shows that any elements in rt_sigframe after ucontext_t.uc_sigmask are either (1) unused or only used by the kernel or (2) fall into the x86_64/i386 floating point state case above. Kernel has new signals, user space does not Any new bits in ucontext.uc_sigmask placed on the signal stack are opaque to user space (except in cases where user space already has a larger sigset_t, as in glibc). There are no changes to the real-time signals system call semantics, as the kernel will honor the hard-coded sigsetsize value of 8 in libc and behave as it has before these changes. Signal numbers larger than 64 cannot be blocked or caught until user space is updated, however their default action will work as expected. This can cause one problem: a parent process that uses the signal number a child exited with as an index into an array without bounds checking can cause a crash. I’ve seen exactly one instance of this in tcsh, and is, I think, a bug in tcsh. User space has new signals, kernel does not User space attempting to use a signal number not supported by the kernel in system calls (eg, sigaction()) or other libc functions (eg, sigaddset()) will result in EINVAL, as expected. User space needs to know how to set the sigsetsize parameter to the real time signal system calls and it can use getauxval(AT_SIGSET_SZ) to determine this. If it returns zero the sigsetsize must be 8, otherwise the kernel will accept sigsetsize between 8 and the return value. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23188 Walt Drummond (8): signals: Make the real-time signal system calls accept different sized sigset_t from user space. signals: Put the full signal mask on the signal stack for x86_64, X32 and ia32 compatibility mode signals: Use a helper function to test if a signal is a real-time signal. signals: Remove sigmask() macro signals: Better support cases where _NSIG_WORDS is greater than 2 signals: Round up _NSIG_WORDS signals: Add signal debugging signals: Support BSD VSTATUS, KERNINFO and SIGINFO arch/alpha/kernel/signal.c | 4 +- arch/m68k/include/asm/signal.h | 6 +- arch/nios2/kernel/signal.c | 2 - arch/x86/ia32/ia32_signal.c | 5 +- arch/x86/include/asm/sighandling.h | 34 +++ arch/x86/include/asm/signal.h | 10 +- arch/x86/include/uapi/asm/signal.h | 4 +- arch/x86/kernel/signal.c | 11 +- drivers/scsi/dpti.h | 2 - drivers/tty/Makefile | 2 +- drivers/tty/n_tty.c | 21 ++ drivers/tty/tty_io.c | 10 +- drivers/tty/tty_ioctl.c | 4 + drivers/tty/tty_status.c | 135 ++++++++++ fs/binfmt_elf.c | 1 + fs/binfmt_elf_fdpic.c | 1 + fs/ceph/addr.c | 2 +- fs/jffs2/background.c | 2 +- fs/lockd/svc.c | 1 - fs/proc/array.c | 32 +-- fs/proc/base.c | 48 ++++ fs/signalfd.c | 26 +- include/asm-generic/termios.h | 4 +- include/linux/compat.h | 98 ++++++- include/linux/sched.h | 52 +++- include/linux/signal.h | 389 ++++++++++++++++++++-------- include/linux/tty.h | 8 + include/uapi/asm-generic/ioctls.h | 2 + include/uapi/asm-generic/signal.h | 8 +- include/uapi/asm-generic/termbits.h | 34 +-- include/uapi/linux/auxvec.h | 1 + kernel/compat.c | 30 +-- kernel/fork.c | 2 +- kernel/ptrace.c | 18 +- kernel/signal.c | 288 ++++++++++---------- kernel/sysctl.c | 41 +++ kernel/time/posix-timers.c | 3 +- lib/Kconfig.debug | 10 + security/apparmor/ipc.c | 4 +- virt/kvm/kvm_main.c | 18 +- 40 files changed, 974 insertions(+), 399 deletions(-) create mode 100644 drivers/tty/tty_status.c -- 2.30.2 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Walt Drummond Subject: [RFC PATCH 0/8] signals: Support more than 64 signals Date: Mon, 3 Jan 2022 10:19:48 -0800 Message-ID: <20220103181956.983342-1-walt@drummond.us> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=home.drummond.us; s=default; t=1641234030; bh=E5fnl6UDJWZKDRpYiS+tfaqNC1+q8ROkLPZx/9dIiQE=; h=From:To:Cc:Subject:Date:From; b=zXbbImMEGQ9pUpv1DxfY2XmQttregvHgLm+qsl9EG8U8kPMhSbyKD5DQ25UYOdRzo BfoL/P72aybwUNV/dOsh0KUrU+F+6X19Cgfu7MENmFok86fj7YBUHIKHTe6B3r/2l0 iFHFBcYB/awOvzTkhHjnaPiTR52hfe6PHcBRzY7m0xTugBKuJxGGgsr0nguKo8yqGW 0VW8sn37JwEbBrD9p0qZEb9YsC8UbN/YcXTbNbKSZNHo8cvcUPBLwqbV6LWX9tWvlN QEeMhR0gHOFTcJtLQUs5HTxDDyu0MNDZscXnTgsu1kqViQK/ikejaInqcv0AX04Too CMrZIYqUTCwPQ== List-ID: Content-Type: text/plain; charset="utf-8" To: aacraid@microsemi.com, viro@zeniv.linux.org.uk, anna.schumaker@netapp.com, arnd@arndb.de, bsegall@google.com, bp@alien8.de, chuck.lever@oracle.com, bristot@redhat.com, dave.hansen@linux.intel.com, dwmw2@infradead.org, dietmar.eggemann@arm.com, dinguyen@kernel.org, geert@linux-m68k.org, gregkh@linuxfoundation.org, hpa@zytor.com, idryomov@gmail.com, mingo@redhat.com, yzaikin@google.com, ink@jurassic.park.msu.ru, jejb@linux.ibm.com, jmorris@namei.org, bfields@fieldses.org, jlayton@kernel.org, jirislaby@kernel.org, john.johansen@canonical.com, juri.lelli@redhat.com, keescook@chromium.org, mcgrof@kernel.org, martin.petersen@oracle.com, mattst88@gmail.com, mgorman@suse.de, oleg@redhat.com, pbonzini@redhat.com, peterz@infradead.org, rth@twiddle.net, richard@nod.at, serge@hallyn.com Cc: linux-kernel@vger.kernel.org, Walt Drummond , ceph-devel@vger.kernel.org, kvm@vger.kernel.org, linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-m68k@vger.kernel.org, linux-mtd@lists.infradead.org, linux-nfs@vger.kernel.org, linux-scsi@vger.kernel.org, linux-security-module@vger.kernel.org This patch set expands the number of signals in Linux beyond the current cap of 64. It sets a new cap at the somewhat arbitrary limit of 1024 signals, both because it’s what GLibc and MUSL support and because many architectures pad sigset_t or ucontext_t in the kernel to this cap. This limit is not fixed and can be further expanded within reason. Despite best efforts, there is some non-zero potential that this could break user space; I'd appreciate any comments, review and/or pointers to areas of concern. Basically, these changes entail: - Make all system calls that accept sigset_t honor the existing sigsetsize parameter for values between 8 and 128, and to return sigsetsize bytes to user space. - Add AT_SIGSET_SZ to the aux vector to signal to user space the maximum size sigset_t the kernel can accept. - Remove the sigmask() macro except in compatibility cases, change the sigaddset()/sigdelset()/etc. to accept a comma separated list of signal numbers. - Change the _NSIG_WORDS calculation to round up when needed on generic and x86. - Place the complete sigmask in the real time signal frame (x86_64, x32 and ia32). - Various fixes where sigset_t size is assumed. - Add BSD SIGINFO (and VSTATUS) as a test. The changes that have the most risk of breaking user space are the ones that put more than 8 bytes of sigset_t in the real time signal stack frame (Patches 2 & 6), and I should note that an earlier and incomplete version of patch 2 was NAK’ed by Al in https://lore.kernel.org/lkml/20201119221132.1515696-1-walt@drummond.us/. As far as I have been able to determine this patchset, and specifically changing the size of sigset_t, does not break user space. The two uses of sigset_t that pose the most user space risk are 1) as a member of ucontext_t passed as a parameter to the signal handler and 2) when user space performs manual inspection of the real-time signal stack frame. In case (1), user space has definitions of both siget_t and ucontext_t that are independent of, and may differ from, the kernel (eg, sigset_t in uclibc-ng is 16 bytes, musl is 128 bytes, glibc is 128 bytes on all architectures except Arc, etc.). User space will interpret the data on the signal stack through these definitions, and extensions to sigset_t will be opaque. Other non-C runtimes are similarly independent from kernel sigset_t and ucontext_t and derive their definition of sigset_t from libc either directly or indirectly, and do not manually inspect the signal stack (specifically OpenJDK, Golang, Python3, Rust and Perl). The only instances I found of case (2), manually inspecting the signal stack frame, are in stack unwinders/backtracers (GDB, GCC, libunwind) and in GDB when recording program execution, and only on the i386, x86_64, s390 and powerpc architectures. The GDB, GCC and libunwind behave consistently with and without this patchset. GDB's execution recording is somewhat more complicated. It uses internally defined architecture specific constants to represent the total size of the signal frame, and will save that entire frame for later use. I cannot confirm that the values for powerpc and s390 are correct, but for this purpose it doesn't matter as these architectures explicitly pad for an expanded uc_sigmask. I can, however, confirm that the values for i386 and x86_64 are not correct, and that GDB is recording an incorrect amount of stack data. This doesn’t appear to be an issue; while I cannot build a test case on x86_64 due to a known bug[1], a basic test on i386 shows that the stack is correctly being recorded, and forward and reverse replay seems to work just fine across signal handlers. There are other cases to consider if the number of signals and therefore the size of sigset_t changes: Impact on struct rt_sigframe member elements The placement of ucontext_t in struct rt_sigframe has the potential to move following member elements in ways that could break user space if user space relied on the offsets of these elements. However a review shows that any elements in rt_sigframe after ucontext_t.uc_sigmask are either (1) unused or only used by the kernel or (2) fall into the x86_64/i386 floating point state case above. Kernel has new signals, user space does not Any new bits in ucontext.uc_sigmask placed on the signal stack are opaque to user space (except in cases where user space already has a larger sigset_t, as in glibc). There are no changes to the real-time signals system call semantics, as the kernel will honor the hard-coded sigsetsize value of 8 in libc and behave as it has before these changes. Signal numbers larger than 64 cannot be blocked or caught until user space is updated, however their default action will work as expected. This can cause one problem: a parent process that uses the signal number a child exited with as an index into an array without bounds checking can cause a crash. I’ve seen exactly one instance of this in tcsh, and is, I think, a bug in tcsh. User space has new signals, kernel does not User space attempting to use a signal number not supported by the kernel in system calls (eg, sigaction()) or other libc functions (eg, sigaddset()) will result in EINVAL, as expected. User space needs to know how to set the sigsetsize parameter to the real time signal system calls and it can use getauxval(AT_SIGSET_SZ) to determine this. If it returns zero the sigsetsize must be 8, otherwise the kernel will accept sigsetsize between 8 and the return value. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23188 Walt Drummond (8): signals: Make the real-time signal system calls accept different sized sigset_t from user space. signals: Put the full signal mask on the signal stack for x86_64, X32 and ia32 compatibility mode signals: Use a helper function to test if a signal is a real-time signal. signals: Remove sigmask() macro signals: Better support cases where _NSIG_WORDS is greater than 2 signals: Round up _NSIG_WORDS signals: Add signal debugging signals: Support BSD VSTATUS, KERNINFO and SIGINFO arch/alpha/kernel/signal.c | 4 +- arch/m68k/include/asm/signal.h | 6 +- arch/nios2/kernel/signal.c | 2 - arch/x86/ia32/ia32_signal.c | 5 +- arch/x86/include/asm/sighandling.h | 34 +++ arch/x86/include/asm/signal.h | 10 +- arch/x86/include/uapi/asm/signal.h | 4 +- arch/x86/kernel/signal.c | 11 +- drivers/scsi/dpti.h | 2 - drivers/tty/Makefile | 2 +- drivers/tty/n_tty.c | 21 ++ drivers/tty/tty_io.c | 10 +- drivers/tty/tty_ioctl.c | 4 + drivers/tty/tty_status.c | 135 ++++++++++ fs/binfmt_elf.c | 1 + fs/binfmt_elf_fdpic.c | 1 + fs/ceph/addr.c | 2 +- fs/jffs2/background.c | 2 +- fs/lockd/svc.c | 1 - fs/proc/array.c | 32 +-- fs/proc/base.c | 48 ++++ fs/signalfd.c | 26 +- include/asm-generic/termios.h | 4 +- include/linux/compat.h | 98 ++++++- include/linux/sched.h | 52 +++- include/linux/signal.h | 389 ++++++++++++++++++++-------- include/linux/tty.h | 8 + include/uapi/asm-generic/ioctls.h | 2 + include/uapi/asm-generic/signal.h | 8 +- include/uapi/asm-generic/termbits.h | 34 +-- include/uapi/linux/auxvec.h | 1 + kernel/compat.c | 30 +-- kernel/fork.c | 2 +- kernel/ptrace.c | 18 +- kernel/signal.c | 288 ++++++++++---------- kernel/sysctl.c | 41 +++ kernel/time/posix-timers.c | 3 +- lib/Kconfig.debug | 10 + security/apparmor/ipc.c | 4 +- virt/kvm/kvm_main.c | 18 +- 40 files changed, 974 insertions(+), 399 deletions(-) create mode 100644 drivers/tty/tty_status.c -- 2.30.2