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 C4F90398BA97 for ; Thu, 6 Jun 2024 15:15:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4F90398BA97 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C4F90398BA97 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717686931; cv=none; b=Mf1ucdQnxJXU2bwFamLiSUiswamygIFxQqBoIEv0HYt3mEucbg2mY1Jn7wpsu9O1LCQA8Uj+I1CLrj0DZZeeTLpHwrO0SOuplaaYasFD732Q/AIG1mvpPk8m6a9N5uAU8mm1l3Hiw0onfr3l/yYqVIKqESMi7Jy5OYLR96sTUhE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717686931; c=relaxed/simple; bh=vzKgne68ykUToxb7aRpBuUc0WJIxSYTachMG/svh3BU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=cipJm4Rnw9tK9RNlhxVQb2XDTjhA+ZqCbZNoE3k955iWCHaZjBJTAEkWRkjrCDqcEH+NqCJCuLss4PyKYvLzXux8s+g5YrM2l0emKjQkE+c3704aW7jGUaRTqyU0lGgyJTrJhaWI3M9qmI2gHMygUOwhXZseW2WVqxj8/ya/qGc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1717686929; 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=yMuoWnGMdUpeYJkp6MWTRgJKbi8XPGD7hC973S+30V8=; b=XIZh/PfF3gFwURgJKCv13Zmm/vYc4nMmPyVZq/OsPsQy6u8sfT/+w94rPGyYNFnBeo9tvU IiPTIQ5xT9iI6/8bhuGpbTNHmoqQaerxZnbNSPeCafZjcFlprH+qkCQRztHvXzLIz0uH1i eLN8TyKWK3daxS6fnxl1eqIKRGvYqIo= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-428-CLZ-2wKkPkKo6wEvXUILKA-1; Thu, 06 Jun 2024 11:15:26 -0400 X-MC-Unique: CLZ-2wKkPkKo6wEvXUILKA-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 06F6B1944D33; Thu, 6 Jun 2024 15:15:25 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.194.196]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 84BBA3001E85; Thu, 6 Jun 2024 15:15:23 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella via Libc-alpha Cc: Stafford Horne , Adhemerval Zanella Subject: Re: [PATCH 3/6] linux: Implement mremap in C In-Reply-To: <20211122185437.1934590-4-adhemerval.zanella@linaro.org> (Adhemerval Zanella via Libc-alpha's message of "Mon, 22 Nov 2021 15:54:34 -0300") References: <20211122185437.1934590-1-adhemerval.zanella@linaro.org> <20211122185437.1934590-4-adhemerval.zanella@linaro.org> Date: Thu, 06 Jun 2024 17:15:20 +0200 Message-ID: <87y17iqf07.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Adhemerval Zanella via Libc-alpha: > Variadic function calls in syscalls.list does not work for all ABIs > (for instance where the argument are passed on the stack instead of > registers) and might have underlying issues depending of the variadic > type (for instance if a 64-bit argument is used). > > Checked on x86_64-linux-gnu. Where exactly does this break? If the syscall generator cannot handle pointer arguments, we should fix that. As far as I can tell, we currently assume that the kernel can handle sign-extended pointers. I don't see any special code for processing a/p/s pointers, for example. That impacts far more than just mremap. These pointers are generally not marked as U, for which we have special processing. Conditional varargs processing for system calls is very bad. It causes an ongoing maintenance headache, and weird application issues. For example, Linux 5.7 added MREMAP_DONTUNMAP, and it can use the address argument just like MREMAP_FIXED. But the current mremap implementation always passes NULL as a system call argument. Then there's the issue where varargs functions have more stringent ABI requirements than non-varargs functions, as we recently saw with prctl. I think we should just revert this change, to be honest. Thanks, Florian