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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 14A4D3938C2B for ; Thu, 11 Mar 2021 16:38:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 14A4D3938C2B Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-455-_0XimE6MMA6T547APsIvMg-1; Thu, 11 Mar 2021 11:38:34 -0500 X-MC-Unique: _0XimE6MMA6T547APsIvMg-1 Received: by mail-qk1-f200.google.com with SMTP id b78so15933295qkg.13 for ; Thu, 11 Mar 2021 08:38:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=HGEdtnXnaaYvd+XN5EOZaYxTawwWd9vWp9qrADYcqDI=; b=OZloDfv/Lscgm9KvWICSywJFkfpyGQRdiMFLXJIRHzvY0c+RovyvhmYT085vU3hLuc VqaPkqGUp89NeuMPPpwKZsxXYvlCQo4MozctLsooq55SS3m7N+fuhE0CzeNI2iYHV3t3 Zt2BNjNMPYnkqOnQ3/rYB4gsbMDeOlEru9PY9lCxy9TxS667BBYIW4Omq7+wbw+r83t5 xq+uqWzv7pHRb2/EotfPkc1YdUFjkbGEeTXAGqX0hFpj+7ENS1wcEwFSW/mm8gy4/KLc n3iiHWjuODHCG9dIGriQQtvFizZ3YBiLV22P7t0ITr9KgEHw6oDm4Rs0K/us0s72bYwr bEgQ== X-Gm-Message-State: AOAM531yG9EBS9051246at+9Xzcgr7frCsJVMz+btZWzvBHCceBZjwSH 6CmTxD8xxOoVMIguKtPVkUoiq+YI+jSOD/1iGBps6HO4AKj/4OKESZg9JAubklK28SgSszLhjrT IAJfBWX5zDuBz8ulECDu3c8ekFx5YMUlpP/EfTe4K3h8NeCALdL85R1xgmRWyazMUJOs8Ug== X-Received: by 2002:a37:6108:: with SMTP id v8mr8479327qkb.448.1615480713611; Thu, 11 Mar 2021 08:38:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJw84WUjWrByrG/fCjsByytE+t5fkUgNTJ6snIt3ZS1hdPTgP5ltLjudHOoLPr0jQxX6U5XRJQ== X-Received: by 2002:a37:6108:: with SMTP id v8mr8479299qkb.448.1615480713358; Thu, 11 Mar 2021 08:38:33 -0800 (PST) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id p90sm2075214qtd.66.2021.03.11.08.38.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Mar 2021 08:38:32 -0800 (PST) Subject: Re: [PATCH v2] Mount /tmp as tmpfs in test-container and run utime tests in it To: Adhemerval Zanella , DJ Delorie , Florian Weimer , Arjun Shankar , Mike Frysinger Cc: libc-alpha@sourceware.org References: <4f587292-0c94-3fad-ba85-fd6499cbca86@linaro.org> From: Carlos O'Donell Organization: Red Hat Message-ID: Date: Thu, 11 Mar 2021 11:38:31 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <4f587292-0c94-3fad-ba85-fd6499cbca86@linaro.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.6 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_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 11 Mar 2021 16:38:39 -0000 On 3/10/21 1:53 PM, Adhemerval Zanella via Libc-alpha wrote: > On 10/03/2021 15:31, DJ Delorie wrote: >> Adhemerval Zanella via Libc-alpha writes: >>> Sorry, I still think we should not gloss over buggy filesystems. >> >> The right solution to this is to mount one of every filesystem and test >> them all, not leave it up to the randomness of /tmp and have to try to >> deduce if it's a known bug or a new bug. >> >> Oh wait, that's kernel testing. >> > > This is similar to libidn2 requirement [1], where it has started to dump > FAILs if the system did not provide an updated library version. Carlos > back then [2] added that it should continue to dump a 'FAIL' to indicate > 'you have bugs in your system libidn'. We are smearing the definition of "testing" across two boundaries: * integrated system testing (test glibc with the host and host libraries) * unit testing (smallest logical piece to test depends on our definitions) If we want a glibc "integrated system test" that verifies the current glibc against the host /tmp, then we can have that. I think that Arjun is arguing he would like to see the y2038 tests behave more like unit tests and operate independently of the host. I think that DJ has noted we could have 2 tests, one which covers the whole system testing (or integration test) and a unit test. In the case of libidn2, where glibc was calling out via dlopen to the host libidn2, there was a good case to use the whole system testing approach and FAIL the test if libidn2 was buggy. In order to make a unit test out of that we'd need to bundle a known-good libidn2 or stub it out. In the case of this kernel bug we can relatively easily clone a unit test that uses tmpfs, and also run a whole system test, and provide comments explaining why we have two tests. > So maybe it would be better to do something similar as Joseph did to > proper handle it [5] and mark the tests unsupported if the '/tmp' > is XFS or any buggy one. What if we did this? (1) Add unit tests that use a container and tmpfs to test functionality. (2) Refactor and use the same test but with the host /tmp and: - Look for XFS version that is buggy and mark it XFAIL. - Otherwise FAIL because it's a new kernel bug. -- Cheers, Carlos.