From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 6502939AD70F for ; Thu, 6 Jun 2024 20:26:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6502939AD70F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6502939AD70F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717705580; cv=none; b=ejHpP089G/aHjTVvPM8+4y6ITEkjPkwT9wfBgyJSIwqBc/ObKYKFBDPJJ2eG4Yb/YT6oq0IVj1ysWPMdItB7RC0h4h8LZw9jna0NAV3EmKCoVvSAHh3LKoF6UmTxFWg6dJX7KstCA2fYtOUpHwu/OIr8cpeBjnM6IxaG6TptDGg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717705580; c=relaxed/simple; bh=9E6LzK33QvTwYUJIo1M7GqCLGK6tA8Qw2X3UUZQpNBY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ZJpSsXhD39917iJ6BZ6b02gwHRPXQEFYvv7exlYoqO9Irm/vp/adxCXLXb1fz/fzX81OBquS1lHlg+ftBRfGTChT4Ru1OU9yNbYdLH8h8iAjtuZdYTYQGRCxHOhj/YqVWd2WY7e2oBu5ZTUdAati6F6RagX3JKGnptccq1DI9uQ= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1f6ad2e2f5bso13700635ad.2 for ; Thu, 06 Jun 2024 13:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1717705576; x=1718310376; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=1N8OEKJGimlBJpZa7MkTJmCfGvzAn1CIUnyMcbUS+Jc=; b=meov4B6SkJsEN9q/Yofwa548HxEj3w3ONIo8yvOKgkxFh5bPNWMKaEX2O/Hu3GxkTD zRwpEEkCZp2GmLmfL1bpR9vr6C2ULwFyPStfJks/dk1Bp1fhs6I+zj7uiV58VLT89yTI gnf0yGw33u5iPeWUkMBCrDNKm9EHd9pmZKgJaauTl+N86mDqgCXhYlxpbfSe1m7ZeZfK GxbMOX54Gx5tWr2csXXR3MYl2UBVBEFzGD1tCJHeV4rtCAxbGfF6741DDoyKKGZ+9zyH v22ftkcJulanuFj4BUNXk+jyjyl3y7/WRe2P3kNs4SOpeu/OhXsUGWkgPzCR9EOH6x6/ 9y0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717705576; x=1718310376; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1N8OEKJGimlBJpZa7MkTJmCfGvzAn1CIUnyMcbUS+Jc=; b=mTGo5fE0heyCp2Qtwc4uTNiva3sL7GZRtJLOM2hDeP+Vv+2TIWHds26Z8wQ2ezzA0v +keSzoghI520PaERJoZThOQatp/2Oyj++6sgRyyNGGCyxPkyDHBt4cLruiNf18YE/Ll1 M4e2wdIT52Pmw0CwU+HHpgiLzldNyRFtEZmKQSLV4gTXpsoc+348GnpoAb7CRcPOohin VN5dwr74ayZEpzyouKNXiFGqP+EVeZgWNDzQD6v7oSn0fO+g8/f9ufiRR+G/iDI9LvhU qqa8ls8gUodwE4nBAZ0Q+nMhxEor0IqwWZHNlAhyz+6cKgSCDHsZmvLE8dUeVHdhUpCF qY+g== X-Gm-Message-State: AOJu0YxdC4G082ekFM0AwXCEPla2WXGjOdL5zEoeeZB1ebFXLJdPUlKQ KqdZWwdcNEvqKpJ2rcff3+GUiBuFcYs5Va1Z3FLOqUEa7roSZFCkxbGzlNJqDao= X-Google-Smtp-Source: AGHT+IGlZ28Rt1/02Xji3QfJnKEKiftmnEsHcTKDioWwsHPgBgBjqhjJxSHz6DxxZa4apbyWruQ0gw== X-Received: by 2002:a17:902:d2c1:b0:1f6:6f58:f04 with SMTP id d9443c01a7336-1f6d0377889mr8453395ad.43.1717705576255; Thu, 06 Jun 2024 13:26:16 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:3995:ed31:6785:efd1:968? ([2804:1b3:a7c0:3995:ed31:6785:efd1:968]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1f6bd75f321sm19701705ad.2.2024.06.06.13.26.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 06 Jun 2024 13:26:15 -0700 (PDT) Message-ID: <177225da-682e-4f57-9cde-5ff8f366266a@linaro.org> Date: Thu, 6 Jun 2024 17:26:12 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] linux: Implement mremap in C To: enh , Florian Weimer Cc: Adhemerval Zanella via Libc-alpha , Stafford Horne References: <20211122185437.1934590-1-adhemerval.zanella@linaro.org> <20211122185437.1934590-4-adhemerval.zanella@linaro.org> <87y17iqf07.fsf@oldenburg3.str.redhat.com> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 06/06/24 16:38, enh wrote: > On Thu, Jun 6, 2024 at 12:01 PM enh wrote: >> >> On Thu, Jun 6, 2024 at 11:15 AM Florian Weimer wrote: >>> >>> * 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? I don't really recall to be honest. And I don't have a strong opinion, the main issue is I would like to eventually get rid of the assembly hooks for the syscall auto-generation so we only have have it to support for generate it through C. Besides the code simplification it has the side effect of playing better the LTO (which we still do not fully support, but maybe in the future). I had a prototype for this, which also is slight faster since it generates the files in a bulk. >>> >>> 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. >> >> yeah, bionic and musl have this same bug, for the same reason of >> having been written before MREMAP_DONTUNMAP was added, and not having >> been updated since. > > is it possible to use MREMAP_DONTUNMAP with a destination address > without also setting MREMAP_FIXED? the kernel selftests don't seem to > _test_ that case if so... > > the glibc header comment also claims that MREMAP_FIXED is necessary. The tools/testing/selftests/mm/mremap_dontunmap.c selftest does not have an explicit test for MREMAP_DONTUNMAP with non-null variadic argument, but it seems that all tests that require issue mremap with MREMAP_FIXED. So, is this really an issue?