From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AFA033858D39 for ; Tue, 19 Jul 2022 02:33:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AFA033858D39 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-240-ldciDXSXM1ijdRJRmnAmew-1; Mon, 18 Jul 2022 22:33:37 -0400 X-MC-Unique: ldciDXSXM1ijdRJRmnAmew-1 Received: by mail-qk1-f198.google.com with SMTP id bm34-20020a05620a19a200b006b5f1d95ceeso2511425qkb.5 for ; Mon, 18 Jul 2022 19:33:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=kbIyL84Qx0J20+/AtZY/vl2LQ0nRb+SemZ1aZTLr/IM=; b=wh1AXeqx5AngOvAWkmkKzOks9xcyOToJA9+V69xmfWLW2ggz+o4bSjKTpUyeVAv74J 90eYr95Mle0TlBeapEBBo18lhD8ktsFl9TMBEB3L2CfiuF1zE1kK7jKki7xFH85zQyKf 0X7xVrVDazs4JBfI7k2x5EgVOprxy8LNiCza6ScAYJsfR8qQK5xxfq/rbBk7S61rul5P pqOlqfse6T6N/SLtrtIygRNqd9jIrxPK70jQYSCYI7C/o0YG8Z7veOtVJaNPEGst62Uw bN1OrdSKRJuUrAeKZwWaPLcqIJOWEdceACs75GE7Yz4ZK4pfsC89hWHTSgMXW9upOOaV XZjQ== X-Gm-Message-State: AJIora+NOCyQiD+4NR+Z8XquKXiirc7z/epEPYYhlhPLTSDIfY9PDzlW 0MuhqMEKGwB5g6rmAL90NX+6D5FookCOIFM6TuElgJ2TRu4ANEdTaNwFJsNoOKkRrmHfniKT+N/ 9hbA7+yhpWobfag16coNc X-Received: by 2002:a05:622a:315:b0:31e:e250:c5f with SMTP id q21-20020a05622a031500b0031ee2500c5fmr11286633qtw.206.1658198017316; Mon, 18 Jul 2022 19:33:37 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vLF0eQyEN8QGznQnYU7mG8IJJHAKpn51UeBFn8Wx8ypdWKqCXwKfwVbzZ0NDMWG3p6Dk724A== X-Received: by 2002:a05:622a:315:b0:31e:e250:c5f with SMTP id q21-20020a05622a031500b0031ee2500c5fmr11286625qtw.206.1658198017099; Mon, 18 Jul 2022 19:33:37 -0700 (PDT) Received: from [192.168.0.241] (192-0-145-146.cpe.teksavvy.com. [192.0.145.146]) by smtp.gmail.com with ESMTPSA id b2-20020ac86782000000b0031eb643c0f5sm4357270qtp.94.2022.07.18.19.33.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Jul 2022 19:33:36 -0700 (PDT) Message-ID: <0ca14781-62ab-208c-b190-5854b7b7925e@redhat.com> Date: Mon, 18 Jul 2022 22:33:35 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v5 0/2] Linux: Fix posix_spawn when user with time namespaces To: Adhemerval Zanella Cc: libc-alpha@sourceware.org References: <20220530174918.3056804-1-adhemerval.zanella@linaro.org> <55438381-3aee-01d4-bde0-7b61e2857057@redhat.com> <5F91F11D-5357-41B8-9943-7013FEE1D899@linaro.org> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <5F91F11D-5357-41B8-9943-7013FEE1D899@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2022 02:33:41 -0000 On 7/11/22 12:56, Adhemerval Zanella wrote: > > >> On 11 Jul 2022, at 12:32, Carlos O'Donell wrote: >> >> On 5/30/22 13:49, Adhemerval Zanella via Libc-alpha wrote: >>> The patchset also adds some support to tests the fallback code >>> to use only use CLONE_VFORK. It uses unshare directly because >>> it simpler than add container support. >>> >>> v5: Use a MAP_SHARED page to communicate error on prepare phase from >>> helper process. >> >> The current progress is that it seems we may get the upstream Linux kernel >> to change the semantics of the time namespace to take effect only after >> exec for vfork. If that goes forward we won't need these changes? >> >> I'm trying to determine if these changes constitute a blocker for 2.36. > > My understanding is even kernel does change or add a new flag to handle > it, we still have released kernels that might hit this issue. Thanks. In which case I don't consider this a blocker for 2.36. It's a bug that we can fix in 2.37 and backport to 2.36 when we've completed the review. I've started looking at these changes but I think we need more testing in downstream. If we fix this when 2.37 opens we can start testing it in Fedora Rawhide early, and backport after we know we don't have further issues. -- Cheers, Carlos.