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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 E1B64C433EA for ; Fri, 24 Jul 2020 11:03:07 +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 B03382074B for ; Fri, 24 Jul 2020 11:03:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AOxLNXOc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B03382074B Authentication-Results: mail.kernel.org; dmarc=none (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=8XJL3ed3bORY4EV8CGgeBrRDPN99tcoJB7jr0TrnIpc=; b=AOxLNXOcObXqy8TfG0Hc8WPWV ODDOEpqdpa4+EXCWO37Tqc287nj+X0XMfIiB+dTSwgJHfrFw9GOyiHqj1hP1V8Jg7szrJ0aup9gr9 cEUrGLjejxMWH+NoaulpX5pCUbcB5ATQkHxeQu4TUcQfWd0rfbUFtqMx3Y8v+aXnz3KOkxLnidZEV QcWWrUO1sWL2QSEYkV2AKYQ+OjSNtT9zJSX/StXmry3bmypaOCyYUrRylWSz25JLu0tRBS7D2UYFA yoOzy++M8FBT7kUdlm9y8+iB4jtuziLYsZ7UeGyk4053J6N1yArf2l8HfMIaUQEKUKeVHLewAYhcm 1iXNbHOhQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jyvSM-0006wv-Hz; Fri, 24 Jul 2020 11:01:38 +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 1jyvSL-0006wc-2U for linux-arm-kernel@lists.infradead.org; Fri, 24 Jul 2020 11:01:37 +0000 Received: from gaia (unknown [95.146.230.158]) (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 E0C2D2074A; Fri, 24 Jul 2020 11:01:34 +0000 (UTC) Date: Fri, 24 Jul 2020 12:01:32 +0100 From: Catalin Marinas To: Thomas Gleixner Subject: Re: [PATCH v5 0/6] arm64: add the time namespace support Message-ID: <20200724110131.GC23388@gaia> References: <20200624083321.144975-1-avagin@gmail.com> <20200705064055.GA28894@gmail.com> <20200714015743.GA843937@gmail.com> <20200722181506.GA4517@gaia> <20200723174140.GA3991167@gmail.com> <87d04mvv0g.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87d04mvv0g.fsf@nanos.tec.linutronix.de> 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-20200724_070137_226922_6FAE8FB6 X-CRM114-Status: GOOD ( 16.57 ) 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: Mark Rutland , Dmitry Safonov , linux-kernel@vger.kernel.org, Andrei Vagin , Christian Brauner , Vincenzo Frascino , Will Deacon , linux-arm-kernel@lists.infradead.org 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 Thu, Jul 23, 2020 at 10:25:35PM +0200, Thomas Gleixner wrote: > Andrei Vagin writes: > > On Wed, Jul 22, 2020 at 07:15:06PM +0100, Catalin Marinas wrote: > > > > I don't think that we need to handle this case in the kernel. Users > > must understand what they are doing and have to write code so that avoid > > these sort of situations. In general, I would say that in most cases it > > is a bad idea to call setns from a signal handler. > > This should not be supported in the first place and just let the > offender die right there. It would have been nice if we caught the offender easily but since signal handling doesn't have to be paired with sigreturn(), the kernel can't tell whether setns() is called in the wrong context. I guess we just have to live with this (maybe document the restriction in time_namespaces(7) or setns(2)). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel