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=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 23BF7C64E7C for ; Mon, 23 Nov 2020 16:00:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E34F220782 for ; Mon, 23 Nov 2020 16:00:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732233AbgKWP7y (ORCPT ); Mon, 23 Nov 2020 10:59:54 -0500 Received: from mail.kernel.org ([198.145.29.99]:45736 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389608AbgKWP7y (ORCPT ); Mon, 23 Nov 2020 10:59:54 -0500 Received: from gaia (unknown [95.146.230.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DAAF320719; Mon, 23 Nov 2020 15:59:49 +0000 (UTC) Date: Mon, 23 Nov 2020 15:59:47 +0000 From: Catalin Marinas To: "Eric W. Biederman" Cc: Peter Collingbourne , Evgenii Stepanov , Kostya Serebryany , Vincenzo Frascino , Dave Martin , Will Deacon , Oleg Nesterov , "James E.J. Bottomley" , Linux ARM , Kevin Brodsky , Andrey Konovalov , linux-api@vger.kernel.org, Helge Deller , David Spickett Subject: Re: [PATCH v21 1/2] signal: define the SA_EXPOSE_TAGBITS bit in sa_flags Message-ID: <20201123155946.GA2438@gaia> References: <13cf24d00ebdd8e1f55caf1821c7c29d54100191.1605904350.git.pcc@google.com> <87h7pj1ulp.fsf@x220.int.ebiederm.org> <20201123114935.GD17833@gaia> <87y2isysra.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y2isysra.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Mon, Nov 23, 2020 at 09:53:13AM -0600, Eric W. Biederman wrote: > Catalin Marinas writes: > > On Fri, Nov 20, 2020 at 05:22:58PM -0600, Eric W. Biederman wrote: > >> Peter Collingbourne writes: > >> > Architectures that support address tagging, such as arm64, may want to > >> > expose fault address tag bits to the signal handler to help diagnose > >> > memory errors. However, these bits have not been previously set, > >> > and their presence may confuse unaware user applications. Therefore, > >> > introduce a SA_EXPOSE_TAGBITS flag bit in sa_flags that a signal > >> > handler may use to explicitly request that the bits are set. > >> > > >> > The generic signal handler APIs expect to receive tagged addresses. > >> > Architectures may specify how to untag addresses in the case where > >> > SA_EXPOSE_TAGBITS is clear by defining the arch_untagged_si_addr > >> > function. > >> > > >> > Signed-off-by: Peter Collingbourne > >> > Acked-by: "Eric W. Biederman" > >> > Link: https://linux-review.googlesource.com/id/I16dd0ed2081f091fce97be0190cb8caa874c26cb > >> > --- > >> > To be applied on top of: > >> > https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11 > >> > >> I have merged this first patch into signal-for-v5.11 and pushed > >> everything out to linux-next. > > > > Thank you Eric. Assuming this branch won't be rebased, I'll apply the > > arm64 changes on top (well, if you rebase it, just let me know so that > > we don't end up with duplicate commits in mainline). > > No. I won't be rebasing it. Not unless something serious problem shows > up, and at that point I will be more likely to apply a corrective change > on top that you can also grab. Thanks Eric. During the merging window, I'll probably wait for you to send the pull request first just to keep the arm64 diffstat simpler. BTW, did you mean to base them on v5.10-rc3-391-g9cfd9c45994b or just v5.10-rc3? It doesn't matter much as I'll generate the diffstat manually anyway in my pull request as I have different bases in other branches. -- Catalin 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=-15.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 3336FC2D0E4 for ; Mon, 23 Nov 2020 16:00:30 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 977012080A for ; Mon, 23 Nov 2020 16:00:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Wx4RybTh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 977012080A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Pl9esvK2LTfjcDLW2ZPzBR763MCmc9IooADZ7nBmTEc=; b=Wx4RybTh3que48DEXtc6nFkJK hi/2K3HuEeg8TwYrOL/ojUI+gRuvNSMPtkTxKLdjccmzC0Dl5ZGk7kcxWNAVn/S5uPqxKBzkdTw2w cc6LlNzFmvit+WbTr04CLREL7zWGiJxqUl4opaXbgjAoLbF7ki5hQXt8LijsEdS4DU0nDUG3syWlY EB/Ixq1NZy7eBHORLzWjrFTFrp/1+WHLe3HGnNGLYQ1Um9MHyVH0S+u+gePEP5E/eEXp/IZNqdvIp k2LBEyfAG9rZ0cxi1TpCYuCcU0AAGkgwA04Q378EgjZ4BUi+LuvDcE20Jo1JBZlJ3Ac1/GmftzcSo hvhyQbiGA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1khEFw-0002DV-Ri; Mon, 23 Nov 2020 15:59:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1khEFt-0002CK-Cg for linux-arm-kernel@lists.infradead.org; Mon, 23 Nov 2020 15:59:54 +0000 Received: from gaia (unknown [95.146.230.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DAAF320719; Mon, 23 Nov 2020 15:59:49 +0000 (UTC) Date: Mon, 23 Nov 2020 15:59:47 +0000 From: Catalin Marinas To: "Eric W. Biederman" Subject: Re: [PATCH v21 1/2] signal: define the SA_EXPOSE_TAGBITS bit in sa_flags Message-ID: <20201123155946.GA2438@gaia> References: <13cf24d00ebdd8e1f55caf1821c7c29d54100191.1605904350.git.pcc@google.com> <87h7pj1ulp.fsf@x220.int.ebiederm.org> <20201123114935.GD17833@gaia> <87y2isysra.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87y2isysra.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201123_105953_524981_4EA65BD8 X-CRM114-Status: GOOD ( 22.52 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Collingbourne , Helge Deller , Kevin Brodsky , Oleg Nesterov , linux-api@vger.kernel.org, "James E.J. Bottomley" , Kostya Serebryany , Linux ARM , Andrey Konovalov , David Spickett , Vincenzo Frascino , Will Deacon , Dave Martin , Evgenii Stepanov Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 23, 2020 at 09:53:13AM -0600, Eric W. Biederman wrote: > Catalin Marinas writes: > > On Fri, Nov 20, 2020 at 05:22:58PM -0600, Eric W. Biederman wrote: > >> Peter Collingbourne writes: > >> > Architectures that support address tagging, such as arm64, may want to > >> > expose fault address tag bits to the signal handler to help diagnose > >> > memory errors. However, these bits have not been previously set, > >> > and their presence may confuse unaware user applications. Therefore, > >> > introduce a SA_EXPOSE_TAGBITS flag bit in sa_flags that a signal > >> > handler may use to explicitly request that the bits are set. > >> > > >> > The generic signal handler APIs expect to receive tagged addresses. > >> > Architectures may specify how to untag addresses in the case where > >> > SA_EXPOSE_TAGBITS is clear by defining the arch_untagged_si_addr > >> > function. > >> > > >> > Signed-off-by: Peter Collingbourne > >> > Acked-by: "Eric W. Biederman" > >> > Link: https://linux-review.googlesource.com/id/I16dd0ed2081f091fce97be0190cb8caa874c26cb > >> > --- > >> > To be applied on top of: > >> > https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11 > >> > >> I have merged this first patch into signal-for-v5.11 and pushed > >> everything out to linux-next. > > > > Thank you Eric. Assuming this branch won't be rebased, I'll apply the > > arm64 changes on top (well, if you rebase it, just let me know so that > > we don't end up with duplicate commits in mainline). > > No. I won't be rebasing it. Not unless something serious problem shows > up, and at that point I will be more likely to apply a corrective change > on top that you can also grab. Thanks Eric. During the merging window, I'll probably wait for you to send the pull request first just to keep the arm64 diffstat simpler. BTW, did you mean to base them on v5.10-rc3-391-g9cfd9c45994b or just v5.10-rc3? It doesn't matter much as I'll generate the diffstat manually anyway in my pull request as I have different bases in other branches. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel