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 1A255385841A for ; Fri, 23 Sep 2022 18:57:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A255385841A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663959459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bWW0wgI8/p3c6jhorGICHUepRrta4FvDpMKsinI6HEg=; b=DpG4TcrJQAFRESuvzqG5s8ZqAslB7ICyTKl07713ljirXPhEe5hT56NgMY8W66T417YDUA yTqC6FTQPsiOc+aIIT6NwiVI+fj7fRF7uC/JUaZ+DuF2w016qWPTfd05Z6SBKI3oquRqdY 7rDXgDlPRe2A/6JjLTMSv0fx0Q5PZkU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-80-pFtoHClzPk6H_5VyjjDDVA-1; Fri, 23 Sep 2022 14:57:38 -0400 X-MC-Unique: pFtoHClzPk6H_5VyjjDDVA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 32CAE811E81; Fri, 23 Sep 2022 18:57:38 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 738BB49BB60; Fri, 23 Sep 2022 18:57:37 +0000 (UTC) From: Florian Weimer To: Zack Weinberg via Libc-alpha Cc: Zack Weinberg Subject: Re: RFC PATCH: Don't use /proc/self/maps to calculate size of initial thread stack References: <79dae81f-8e33-4499-a47a-93cc0903be6a@www.fastmail.com> <87fsgvvbwq.fsf@oldenburg.str.redhat.com> <9d232b1b-f123-4189-bf09-dd29aab6486a@www.fastmail.com> <54c6018f-3b1d-84e9-04e5-55c0eca66a4c@linaro.org> <3fb8e41b-8717-4663-9a09-8259211d5d69@www.fastmail.com> Date: Fri, 23 Sep 2022 20:57:35 +0200 In-Reply-To: <3fb8e41b-8717-4663-9a09-8259211d5d69@www.fastmail.com> (Zack Weinberg via Libc-alpha's message of "Fri, 23 Sep 2022 10:59:29 -0400") Message-ID: <87y1u9apgg.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,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 List-Id: * Zack Weinberg via Libc-alpha: > On Wed, Sep 21, 2022, at 4:58 PM, Adhemerval Zanella Netto via Libc-alpha wrote: >> I wonder if we could use inplace mremap (which should be a nop) to inform >> a more approximate value for the stack (the code only handles grown down >> architecture): > > mremap is unusual enough that I think we'd have the same problem with > seccomp filters that Florian pointed out regarding process_vm_readv. glibc uses mremap for realloc in some cases. And the system call does not directly permit mapping memory of a separate process. (process_vm_readv is one of the system calls that looks like it would be deliberately blocked, not just accidentally.) But I'd worry about consistent mremap semantics for this particular use case here. Thanks, Florian