Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2079996ybh; Fri, 24 Jul 2020 04:02:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJweHa+F6gRQ6PWWgozVyoByK8Qqd7TVQmq6aCYZC5OmFpm3BR/d8U+2J3dmBxqJzyHA+PML X-Received: by 2002:a05:6402:cb9:: with SMTP id cn25mr8566392edb.247.1595588537053; Fri, 24 Jul 2020 04:02:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595588537; cv=none; d=google.com; s=arc-20160816; b=UMsC14usvjUYDzQQHE7kCF2zKnEOEz9BbcpfIKRyj5kRERe6kYotfWzaDrz5Tw716w bdu8wIcq/7JszsPHWmO4GN6H9qQTN9fOWxDjh9ocFfQkkA+WHl/KkfUGvI14ady/LA+V dBmcy59QBW0Cp7T7+9DVmEKWJMRLiCtqPmas6+6RdwWkL2UhofWRcYujk49k/s3kvDEY 9HU01dH7YH+x60giJHgqFj14aIbXmSYxCr24wUkIde50Rzdd2ZkF1Pq10l2k80O9dOnn 87tjB73UAs6MQB3KaxlBI4fn5u+yv3qDbc2KawJkZQEsM7hdrVu66Pe/2SsHULJOPqKD FO5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=3VLwU4dV8QxjeFWYOAHNQNk0jvlT6ThzKFYkZdoHraI=; b=uvEArYBohziiHkDImaUq427tFemFU2Md3E2WL03/gh6TcbOnsyAnGLRAXnNFfuuIXi 6zoA/2ibduKHh7YXXGfnFLYM+ceP47EaKNWGHilJJ8fnJ5GgswOb5X4XocUDzO16RhHN /T+hNHqhFKoifQ2ODG2Gsup9w1MllgYsbjLj52VBA5+ChQjHJ48quNloAshnvG/5LiDF YY8ux4u+mUCoSKTCeYtGF4fKrKxmCyuQxm6tfEg+9dDN97gVFssaAYavtNiXW4GBHRMv ruUYDHIPQ6apxfh/7G6cOKNlwpWC0LAVHhnznDHSxoUTqi0DKHGXrFM5dBeERpiODaJ3 rkuA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id sa7si386067ejb.564.2020.07.24.04.01.54; Fri, 24 Jul 2020 04:02:17 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726607AbgGXLBg (ORCPT + 99 others); Fri, 24 Jul 2020 07:01:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:45476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbgGXLBg (ORCPT ); Fri, 24 Jul 2020 07:01:36 -0400 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 Cc: Andrei Vagin , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Vincenzo Frascino , Mark Rutland , Dmitry Safonov , Christian Brauner 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d04mvv0g.fsf@nanos.tec.linutronix.de> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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