From unknown Sun Aug 17 09:09:49 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#63850 <63850@debbugs.gnu.org> To: bug#63850 <63850@debbugs.gnu.org> Subject: Status: cp fails for files > 2 GB if copy offload is unsupported Reply-To: bug#63850 <63850@debbugs.gnu.org> Date: Sun, 17 Aug 2025 16:09:49 +0000 retitle 63850 cp fails for files > 2 GB if copy offload is unsupported reassign 63850 coreutils submitter 63850 Sam James severity 63850 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 11:49:02 2023 Received: (at submit) by debbugs.gnu.org; 2 Jun 2023 15:49:02 +0000 Received: from localhost ([127.0.0.1]:40701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q571R-0004lm-S8 for submit@debbugs.gnu.org; Fri, 02 Jun 2023 11:49:02 -0400 Received: from lists.gnu.org ([209.51.188.17]:37312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q571O-0004lc-Ad for submit@debbugs.gnu.org; Fri, 02 Jun 2023 11:49:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q571O-0001Ln-1O for bug-coreutils@gnu.org; Fri, 02 Jun 2023 11:48:58 -0400 Received: from mail.gentoo.org ([2001:470:ea4a:1:5054:ff:fec7:86e4] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1q571L-0000nm-S6 for bug-coreutils@gnu.org; Fri, 02 Jun 2023 11:48:57 -0400 User-agent: mu4e 1.10.3; emacs 29.0.91 From: Sam James To: Subject: cp fails for files > 2 GB if copy offload is unsupported Date: Fri, 02 Jun 2023 16:44:57 +0100 Message-ID: <87h6rpn9uw.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2001:470:ea4a:1:5054:ff:fec7:86e4; envelope-from=sam@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain Hello, Forwarding a downstream report of a behaviour change between coreutils-9.1 and coreutils-9.3 from https://bugs.gentoo.org/907474. The reporter bisected it to 093a8b4bfaba60005f14493ce7ef11ed665a0176 ("copy: fix --reflink=auto to fallback in more cases", see bug#62404) and gave strace output showing: ``` fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 2147479552 copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = -1 EINVAL (Invalid argument) ``` """ When I try to copy a large file (> 2 GB) like so: cp --debug file_a file_b output looks like this: 'file_a' -> 'file_b' cp: error copying 'file_a' to 'file_b': Invalid argument copy offload: unsupported, reflink: unsupported, sparse detection: no Afterwards file_b has a size of 2147479552 bytes (= 2G - 4K). On another system (with newer kernel version) it looks like this: cp --debug file_a file_b 'file_a' -> 'file_b' copy offload: yes, reflink: unsupported, sparse detection: no """ Let me know if you need further information, although there's some more on the downstream Gentoo bug I linked. Apparently this is only happening w/ the 4.19.x kernels. Thanks! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZHoPV18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZB0qgEA/H0LOTOUjW2DXJgWReMsvRxwST6ngueTzrSr Icc6ZJIBAOMJbDGzgvSfjEiqLzAsOhZ3ODh2R74TsP/HVkAINNEE =7lWo -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 12:32:00 2023 Received: (at 63850) by debbugs.gnu.org; 2 Jun 2023 16:32:00 +0000 Received: from localhost ([127.0.0.1]:40770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q57h2-0005xN-3A for submit@debbugs.gnu.org; Fri, 02 Jun 2023 12:32:00 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:48602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q57gz-0005xA-Sw for 63850@debbugs.gnu.org; Fri, 02 Jun 2023 12:31:58 -0400 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-3f6a6b9c079so21467585e9.1 for <63850@debbugs.gnu.org>; Fri, 02 Jun 2023 09:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685723512; x=1688315512; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=CJAEd2I3aNTmXVq4vwbDRQLWULBsA2c1hLKDL/c6zmA=; b=b5ehys3q8TGCXcb0hmXCIae+6ngu/5BiHqdl8LuxGIOZAyxvn3ELral2NvxeooArQf 0mI8CFuPorNhtorLEsMsX5OwnQMAkOGvPPOeHZrm1md8QGBkeKFIzbRBbWeteTaEEr+o 90uQpIJ6fxyaagVwELv0zIlcfBYXNsSItC+vVfxN/RCf7u1WiIcQwH+WYRkElSn3uHGD 8SlGgfEEWo5ETuDYgRoPY+LQz36k/9TgdgXBh3eV5x62dhVuYa6IVksXjLi6rkmuVonH EGbyGrkMXFytJ/RMgee/ST4TVgzIS5S5CmTHjsbzMSUFC5vrHrdA0GL0isxxuKKX5e4X ccWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685723512; x=1688315512; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CJAEd2I3aNTmXVq4vwbDRQLWULBsA2c1hLKDL/c6zmA=; b=Tr4nOkuuH6ALx+6WezEmlhZa429j1SsozD68JkX6d+1akAeeeIpBvcgydXlaFMNZb5 RwCbp0a7nWbifHexpe7ndLfDcBH7RshJhJKgELfr7T7pCQGuv0VVINS/QkRvRsC7E32f 9Qm/OL2aZSW0KARlHA/yv7yXspi+9yif+eqmjEKwlchQJVIeXjvj4K42EzEjmCL7T2k7 r6WEviIu7XNXshTFPOWigqlBNVZibVyOiU3I5CoSJ5EdUWUE05KOTmc3olegjVggUXDS CxKR50tE5WhJldBUZ7r73hl0aNkvbq8s9krQWi25pJ3xFBJZR90n6lbG7vwp56JFmPzo nVJQ== X-Gm-Message-State: AC+VfDytDZkjhW+e3mOiFJE+auweqOy/poJMDp7IZSpLLNOyr/oi2rIT eXYjqbYxKEsi6tKu0pKTNhAFYAkzrDo= X-Google-Smtp-Source: ACHHUZ4O6nRgHWXXtUSw/p0xtaE/Tx7Yv1cFEPqAOxyh5/Mo3NEnJWQOyEs+9g47nHxm7nUxOqQDFA== X-Received: by 2002:a1c:7913:0:b0:3f6:900:4b6a with SMTP id l19-20020a1c7913000000b003f609004b6amr2174201wme.1.1685723511538; Fri, 02 Jun 2023 09:31:51 -0700 (PDT) Received: from [192.168.1.19] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id x11-20020a5d650b000000b00307972e46fasm2088346wru.107.2023.06.02.09.31.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Jun 2023 09:31:51 -0700 (PDT) Message-ID: <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> Date: Fri, 2 Jun 2023 17:31:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Content-Language: en-US To: Sam James , 63850@debbugs.gnu.org References: <87h6rpn9uw.fsf@gentoo.org> From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: <87h6rpn9uw.fsf@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 63850 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 02/06/2023 16:44, Sam James wrote: > Hello, > > Forwarding a downstream report of a behaviour change between > coreutils-9.1 and coreutils-9.3 from https://bugs.gentoo.org/907474. > > The reporter bisected it to 093a8b4bfaba60005f14493ce7ef11ed665a0176 > ("copy: fix --reflink=auto to fallback in more cases", see bug#62404) > and gave strace output showing: > ``` > fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0 > copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = 2147479552 > copy_file_range(3, NULL, 4, NULL, 9223372035781033984, 0) = -1 EINVAL > (Invalid argument) > ``` > > """ > When I try to copy a large file (> 2 GB) like so: > > cp --debug file_a file_b > > output looks like this: > > 'file_a' -> 'file_b' > cp: error copying 'file_a' to 'file_b': Invalid argument > copy offload: unsupported, reflink: unsupported, sparse detection: no > > Afterwards file_b has a size of 2147479552 bytes (= 2G - 4K). > > On another system (with newer kernel version) it looks like this: > > cp --debug file_a file_b > 'file_a' -> 'file_b' > copy offload: yes, reflink: unsupported, sparse detection: no > """ > > Let me know if you need further information, although there's > some more on the downstream Gentoo bug I linked. > > Apparently this is only happening w/ the 4.19.x kernels. I'm not sure it was working correctly before 9.3 either. Before 9.3 we would have switched from copy_file_range() to read()/write() upon receiving the EINVAL, which might have worked, but also I'm not sure the file offsets would be correct in that case. Could you show the output with: diff --git a/src/copy.c b/src/copy.c index 0dd059d2e..35c54b905 100644 --- a/src/copy.c +++ b/src/copy.c @@ -363,7 +363,16 @@ sparse_copy (int src_fd, int dest_fd, char **abuf, size_t buf_size, edge case where the file is made immutable after creating, in which case the (more accurate) error is still shown. */ if (*total_n_read == 0 && is_CLONENOTSUP (errno)) - break; + { + if (*total_n_read != 0) + { + off_t clone_read_offset = lseek (src_fd, 0, SEEK_CUR); + off_t clone_write_offset = lseek (dest_fd, 0, SEEK_CUR); + printf ("switching to standard copy at :%"PRIdMAX" read=%"PRIdMAX" write=%"PRIdMAX"\n", + *total_n_read, clone_read_offset, clone_write_offset); + } + break; + } /* ENOENT was seen sometimes across CIFS shares, resulting in no data being copied, but subsequent standard copies succeed. */ From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 01:25:48 2023 Received: (at 63850) by debbugs.gnu.org; 3 Jun 2023 05:25:48 +0000 Received: from localhost ([127.0.0.1]:41386 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Jls-0000xo-0E for submit@debbugs.gnu.org; Sat, 03 Jun 2023 01:25:48 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:52525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Jlo-0000xa-Kz for 63850@debbugs.gnu.org; Sat, 03 Jun 2023 01:25:47 -0400 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-3f6042d610fso27825895e9.1 for <63850@debbugs.gnu.org>; Fri, 02 Jun 2023 22:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685769939; x=1688361939; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=vOclVm0IUeHYGVYK0Hi3C2fdU3IAP4+haOG6ry6kjr0=; b=iUo2AjS8OzkdMpJc3xNwapSS7AGfZNSkQgSAYXQsuzsGZZIUA0AT9M89rOVtduxsGa yR3fgJNZ1BGLiYVCUpRbcTB9/IcPg6Ow2Q8csJKyMmdZLFZ7KzWWNFFKPdodHFW3smgo PstB2rNAwVfpNxzV4qCvg2wYLxWwQsLo3aDc0ARdIvWFdT57lVN+7szbQRAX4rmG4/WJ GiVuw5XLkcOnEbQcLf7HsZkzX9DcTnh4Mo7Tgv7Ov4BCUwTOPJx8pRm1pH2yO5+rq9tW f8w6jBCzJtIUIdnu19kFEpMqBzpNArKrOSnUg7lAROSCn8ePlaFJRz2ZV6V6FKBnMAVs UF2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685769939; x=1688361939; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vOclVm0IUeHYGVYK0Hi3C2fdU3IAP4+haOG6ry6kjr0=; b=ij3JbV11uX2VUn3RcNnlU3o+WIpvCFl9NkUEiYPdWEhzLvEEmiw7+LAEyn4kqD9x0n xhVj0Uz25TvYjO8HwYrJLIh6x0mZY1HBb2x6preUTekHIgGQNmRYO7FZAb3+IEE+lk0R G6VbwuslDJYhxgb/b7DUF41bL4UsTToYoKbxFq8O+4ueQMZ7KXh+VRU3Pt4ogJs1SJKW F8qXKYgmJ0mZvkPcsqZJ89Amxx2fAgDsvvl3HSZ3i1J7dzwf/OYlMW8xY6Ysk0rtntGL GGRlO6gJWU982zt49kSBFIoAxcz2CP8RpbG85QNnoFmk2EM/MqOGRaalHTy3kBbN8Z3t w4vA== X-Gm-Message-State: AC+VfDyBUbuDrtgt+pVlDbBtxICQkBSzje3d5lNdyOceEZRIbh5SW8zw pOoVMtmmgCgXvyc4ZzugnS72Y56V01I= X-Google-Smtp-Source: ACHHUZ7Bk96oXmllo/cquyYp8YZPBtbOTQAf0+78ufvcE3crzpLa6DTV/oJRvbSLtdchJSPOyzgKaw== X-Received: by 2002:a05:600c:2255:b0:3f1:6fb3:ffcc with SMTP id a21-20020a05600c225500b003f16fb3ffccmr3615829wmm.22.1685769938514; Fri, 02 Jun 2023 22:25:38 -0700 (PDT) Received: from [192.168.1.19] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id w16-20020adfd4d0000000b0030aefa3a957sm3415708wrk.28.2023.06.02.22.25.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Jun 2023 22:25:38 -0700 (PDT) Message-ID: <102422aa-f01d-5931-b1e3-a3de637601f1@draigBrady.com> Date: Sat, 3 Jun 2023 06:25:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Content-Language: en-US To: Mike Gilbert , 63850@debbugs.gnu.org References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 63850 Cc: sam@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 03/06/2023 02:02, Mike Gilbert wrote: > On Fri, Jun 02, 2023 at 05:31:50PM +0100, Pádraig Brady wrote: >> I'm not sure it was working correctly before 9.3 either. >> Before 9.3 we would have switched from copy_file_range() to read()/write() >> upon receiving the EINVAL, which might have worked, but also I'm not sure >> the file offsets would be correct in that case. Could you show the output with: >> >> diff --git a/src/copy.c b/src/copy.c >> index 0dd059d2e..35c54b905 100644 >> --- a/src/copy.c >> +++ b/src/copy.c >> @@ -363,7 +363,16 @@ sparse_copy (int src_fd, int dest_fd, char **abuf, size_t buf_size, >> edge case where the file is made immutable after creating, >> in which case the (more accurate) error is still shown. */ >> if (*total_n_read == 0 && is_CLONENOTSUP (errno)) >> - break; >> + { >> + if (*total_n_read != 0) >> + { >> + off_t clone_read_offset = lseek (src_fd, 0, SEEK_CUR); >> + off_t clone_write_offset = lseek (dest_fd, 0, SEEK_CUR); >> + printf ("switching to standard copy at :%"PRIdMAX" read=%"PRIdMAX" write=%"PRIdMAX"\n", >> + *total_n_read, clone_read_offset, clone_write_offset); >> + } >> + break; >> + } >> >> /* ENOENT was seen sometimes across CIFS shares, resulting in >> no data being copied, but subsequent standard copies succeed. */ > > I don't think this patch will do anything useful: *total_n_read cannot be 0 > and not 0 simultaneously, so the new block of code will never be > executed. Maybe you meant to insert this block somewhere else? Sorry was rushing. Yes I meant to remove the first total_n_read check as done in the following. In any case an external check would be as useful. I suppose we would have heard at this stage but it would be good to have verification with md5sum or similar on the source and destination files that the copy worked fine on such a file >2G. cheers, Pádraig. diff --git a/src/copy.c b/src/copy.c index 0dd059d2e..296707c39 100644 --- a/src/copy.c +++ b/src/copy.c @@ -362,8 +362,17 @@ sparse_copy (int src_fd, int dest_fd, char **abuf, size_t buf_size, also occur for immutable files, but that would only be in the edge case where the file is made immutable after creating, in which case the (more accurate) error is still shown. */ - if (*total_n_read == 0 && is_CLONENOTSUP (errno)) - break; + if (is_CLONENOTSUP (errno)) + { + if (*total_n_read != 0) + { + off_t clone_read_offset = lseek (src_fd, 0, SEEK_CUR); + off_t clone_write_offset = lseek (dest_fd, 0, SEEK_CUR); + printf ("switching to standard copy at :%"PRIdMAX" read=%"PRIdMAX" write=%"PRIdMAX"\n", + *total_n_read, clone_read_offset, clone_write_offset); + } + break; + } /* ENOENT was seen sometimes across CIFS shares, resulting in no data being copied, but subsequent standard copies succeed. */ From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 02:05:41 2023 Received: (at 63850) by debbugs.gnu.org; 3 Jun 2023 06:05:41 +0000 Received: from localhost ([127.0.0.1]:41416 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5KOT-0002GB-8t for submit@debbugs.gnu.org; Sat, 03 Jun 2023 02:05:41 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:36968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5KON-0002Fs-J4 for 63850@debbugs.gnu.org; Sat, 03 Jun 2023 02:05:39 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 4B4773C02213D; Fri, 2 Jun 2023 23:05:29 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NR8cvNbeAvcb; Fri, 2 Jun 2023 23:05:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 0703D3C09FA2A; Fri, 2 Jun 2023 23:05:29 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 0703D3C09FA2A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1685772329; bh=83WdXH+QRNEUxwMMVWs4Z3ca1unHl2j198zLv9oQ4nU=; h=Message-ID:Date:MIME-Version:To:From; b=SLbvdz3D3WiyKPmOit3wloDIB7gYzoAxSDIdLXgndxmsBqrbvHyTXskiOXV28WXsj V4ZXgKxJmM3NwX81YiJk3T93CR7n6X70/jZl0B+6KVEIEM/QIz8a4dV08+3Og4fTv0 3PDhLW5RIn/jq78KeqsvCcnMeKKZJ+C0vm2ESxzDKYmcEOcrWke3bGB2LfHt2HDpnX SXB/JxvG2z1tTQvp8OBHT9tZe7jFbZnQ0G9jZV4rKWB25GzoXMael5hkAq5V+TixVq N2q11VBndx64Xao1ev5hjcAYbparm8TC261r4ZaRjGPRXl1JiJnwUb1uk/bdRRkLCc u4Y3Om5+chuxw== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pvGHVmCXAvTA; Fri, 2 Jun 2023 23:05:28 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id D64953C02213D; Fri, 2 Jun 2023 23:05:28 -0700 (PDT) Message-ID: <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> Date: Fri, 2 Jun 2023 23:05:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: =?UTF-8?Q?P=c3=a1draig_Brady?= , Sam James , 63850@debbugs.gnu.org References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported In-Reply-To: <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 63850 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 2023-06-02 09:31, P=C3=A1draig Brady wrote: > I'm not sure it was working correctly before 9.3 either. > Before 9.3 we would have switched from copy_file_range() to read()/writ= e() Actually, cp shouldn't have been using copy_file_range at all, as the=20 code is supposed to never use copy_file_range unless the Linux kernel=20 version is 5.3 or later. See m4/copy-file-range.m4 and=20 lib/copy-file-range.c. Since the bug is being reported against kernel 4.19, someone needs to=20 investigate why the Gentoo build is using the copy_file_range syscall on=20 that kernel. Either the Gentoo build isn't properly compiling the=20 replacement function in coreutils/lib/copy-file-range.c, or the=20 replacement function is incorrectly deciding that the kernel is new=20 enough, or something like that. We shouldn't need to fiddle with src/copy.c on this. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 03:14:09 2023 Received: (at 63850) by debbugs.gnu.org; 3 Jun 2023 07:14:09 +0000 Received: from localhost ([127.0.0.1]:41445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5LSi-00041Z-QW for submit@debbugs.gnu.org; Sat, 03 Jun 2023 03:14:09 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183]:57564 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Ff1-0005ep-JH for 63850@debbugs.gnu.org; Fri, 02 Jun 2023 21:02:28 -0400 Date: Fri, 2 Jun 2023 21:02:17 -0400 From: Mike Gilbert To: =?iso-8859-1?Q?P=E1draig?= Brady , 63850@debbugs.gnu.org Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Message-ID: References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63850 X-Mailman-Approved-At: Sat, 03 Jun 2023 03:14:08 -0400 Cc: sam@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Fri, Jun 02, 2023 at 05:31:50PM +0100, Pádraig Brady wrote: > I'm not sure it was working correctly before 9.3 either. > Before 9.3 we would have switched from copy_file_range() to read()/write() > upon receiving the EINVAL, which might have worked, but also I'm not sure > the file offsets would be correct in that case. Could you show the output with: > > diff --git a/src/copy.c b/src/copy.c > index 0dd059d2e..35c54b905 100644 > --- a/src/copy.c > +++ b/src/copy.c > @@ -363,7 +363,16 @@ sparse_copy (int src_fd, int dest_fd, char **abuf, size_t buf_size, > edge case where the file is made immutable after creating, > in which case the (more accurate) error is still shown. */ > if (*total_n_read == 0 && is_CLONENOTSUP (errno)) > - break; > + { > + if (*total_n_read != 0) > + { > + off_t clone_read_offset = lseek (src_fd, 0, SEEK_CUR); > + off_t clone_write_offset = lseek (dest_fd, 0, SEEK_CUR); > + printf ("switching to standard copy at :%"PRIdMAX" read=%"PRIdMAX" write=%"PRIdMAX"\n", > + *total_n_read, clone_read_offset, clone_write_offset); > + } > + break; > + } > > /* ENOENT was seen sometimes across CIFS shares, resulting in > no data being copied, but subsequent standard copies succeed. */ I don't think this patch will do anything useful: *total_n_read cannot be 0 and not 0 simultaneously, so the new block of code will never be executed. Maybe you meant to insert this block somewhere else? From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 12:43:48 2023 Received: (at 63850) by debbugs.gnu.org; 3 Jun 2023 16:43:48 +0000 Received: from localhost ([127.0.0.1]:44210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5ULz-0004wR-Md for submit@debbugs.gnu.org; Sat, 03 Jun 2023 12:43:47 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183]:43882 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Rij-0003GY-Oy for 63850@debbugs.gnu.org; Sat, 03 Jun 2023 09:55:06 -0400 Date: Sat, 3 Jun 2023 09:54:55 -0400 From: Mike Gilbert To: Paul Eggert , sam@gentoo.org, P@draigbrady.com, 63850@debbugs.gnu.org Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Message-ID: References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63850 X-Mailman-Approved-At: Sat, 03 Jun 2023 12:43:46 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On Fri, Jun 02, 2023 at 11:05:24PM -0700, Paul Eggert wrote: > On 2023-06-02 09:31, Pádraig Brady wrote: > > I'm not sure it was working correctly before 9.3 either. > > Before 9.3 we would have switched from copy_file_range() to read()/write() > > Actually, cp shouldn't have been using copy_file_range at all, as the > code is supposed to never use copy_file_range unless the Linux kernel > version is 5.3 or later. See m4/copy-file-range.m4 and > lib/copy-file-range.c. > > Since the bug is being reported against kernel 4.19, someone needs to > investigate why the Gentoo build is using the copy_file_range syscall on > that kernel. Either the Gentoo build isn't properly compiling the > replacement function in coreutils/lib/copy-file-range.c, or the > replacement function is incorrectly deciding that the kernel is new > enough, or something like that. > > We shouldn't need to fiddle with src/copy.c on this. The macro in copy-file-range.m4 performs a build time version check against the installed linux headers (/usr/include/linux). In this case, headers from linux-6.1 are being used at build time. However, the code is being run on a linux-4.19 kernel. Generally speaking, syscall checks must be done at run time on Linux, not build time. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 13:17:57 2023 Received: (at 63850) by debbugs.gnu.org; 3 Jun 2023 17:17:57 +0000 Received: from localhost ([127.0.0.1]:44247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Ut3-0008N6-BJ for submit@debbugs.gnu.org; Sat, 03 Jun 2023 13:17:57 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:38774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Usx-0008Mm-Aq for 63850@debbugs.gnu.org; Sat, 03 Jun 2023 13:17:55 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4QYRQH3z7Pz9sYX; Sat, 3 Jun 2023 19:17:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1685812663; 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=yoTs8ckd/LRP0YVdr5VX6XU1K/UnjULKV0eTJTMwNRs=; b=U5jEEV9eSCnPGrj/G/YxADgIbGG7KZ/WV8U4Bfzx/Yud1NRv/90DuUJmZTc9kgFQ/g0cOZ nWR+5UbuEwVnE4hTtSKb+1N8Q6jYZFwsxgWw1NvyhkeCZDueEbCx43KQRu9tQV00o08QVH 2jJfOAlSdsVPQfj2Eu3aj77LN5onW8hHpzEPNPSD9URSdIoWAGy/7xSJcAxPnO2xmhvyfP cKr2zFqDFIkmtJvSMjgLjni14q0zcZcBI/ywqvSgJGXQo9xW6C55AZ+9BKrlt7ArtbT1IY C+jMcJdfQOwZ+gAaCLBxD6igz698VIlOkI/gjGrTrWuj7cQE6LWndT0QUkx6Sg== References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Mike Gilbert Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Date: Sat, 03 Jun 2023 19:12:41 +0200 In-reply-to: Message-ID: <86v8g45utn.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Rspamd-Queue-Id: 4QYRQH3z7Pz9sYX X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 63850 Cc: Paul Eggert , P@draigbrady.com, sam@gentoo.org, 63850@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike Gilbert writes: > The macro in copy-file-range.m4 performs a build time version check > against the installed linux headers (/usr/include/linux). > > In this case, headers from linux-6.1 are being used at build time. > However, the code is being run on a linux-4.19 kernel. > > Generally speaking, syscall checks must be done at run time on Linux, > not build time. Right, the replacement should always be emitted (perhaps with glibc stub detection, and omitted if one is found, though). linux-headers is a weird library, in that it makes no implication about the compatibility level of your resulting executable, so, no assumption about runtime versions or behavior can be made from static checks. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZHt1tF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosST9tUBAPDSxyygJZ2mwDuGys0c3PYY1/XAleYl0r7g +5BMZR3yAQD9HY2t1gWKijZn5bPtCW27wxAWiXNIJA2YaHPmdhkFCw== =Y3Sn -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 14:40:03 2023 Received: (at 63850) by debbugs.gnu.org; 3 Jun 2023 18:40:03 +0000 Received: from localhost ([127.0.0.1]:44288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5WAU-00022D-Rw for submit@debbugs.gnu.org; Sat, 03 Jun 2023 14:40:03 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:48407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5WAR-00021Y-5r for 63850@debbugs.gnu.org; Sat, 03 Jun 2023 14:40:00 -0400 Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-30aea656e36so2959907f8f.1 for <63850@debbugs.gnu.org>; Sat, 03 Jun 2023 11:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685817593; x=1688409593; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=yZajniMMSI33yGUrLird0tZOCbJjr9q0cACbmdhNwcM=; b=HYeVkEk7qEEdC0wx/GRmXVL77W/hO07L9HANvsyZ+IPVJEBDPV4zgKyWEcb0JvMhA+ +FnQcyaQd1kNV7yffY6FsjdcyE86/8KPx5psqnc/AqcpW8Df10sZuIGVHDbza1rvfebL MOoiS5IZaaxgtQq5/EVSJxODQ7V4RoIaUOTo/WE+1vulREO0ts2dmNp8TsPjtmjT08H1 taAjf2F2WyWiIlP9Dfby82108OpeB/y/n5b3Gf6GDZ2L+8fXyM80fzZ/MaAJO6vlBnB5 sTsOUvjEv6U92CijM+pr4Q2JpUPMJXECtVy5R8abhc76gBA2mqMm5gExdZSEYdIw/Ywa 5WRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685817593; x=1688409593; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yZajniMMSI33yGUrLird0tZOCbJjr9q0cACbmdhNwcM=; b=X/NcLxDEVqbmC0ULD5hkiizBiwGJ67h5TAu1Ae2cRJxDR2d9GCO9P2n1CQLl934PsX 7C0xosE5U+Q5OkZFxVS/Ya4ofJDYeoIsY/fSP/5B54k2dwPAaaE1qg8DYflyUxBpbWVj LVRifEZpAnb0XsKm+GNSRHTHwtoEVG6TtiVQIPNRO0VBxLaHfICDaNlD/UfURtIqhs4A xtQrk64+svJJsJtXLVLWh8nZIWQxexNQCsCJWEEva5ao7souTZn4RBh0Fy/W0cTDuOBr VsqRNQTJNX39QDg0uJOpa5fUtBd/5w7tiNY8+mDuQaJQMZkb3Z6OIdYVFwaIm4Iht9xV knDw== X-Gm-Message-State: AC+VfDw/2c9l2jo6PG8XEJZPfWsUio1m7U/AuaDifTLvEHnDMixKHOnq aw2eTLClHP+CvOx+7DRpP3E= X-Google-Smtp-Source: ACHHUZ4bQFSCYNtXoFESNl9oBo+hVfzpQHEufJUUfiQIO2r+B4eblmP2BM4a2m7Q7ZiEQLeWc9cScA== X-Received: by 2002:a05:6000:c7:b0:2f6:987f:a0f5 with SMTP id q7-20020a05600000c700b002f6987fa0f5mr2387896wrx.5.1685817592935; Sat, 03 Jun 2023 11:39:52 -0700 (PDT) Received: from [192.168.1.19] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id y7-20020a1c4b07000000b003f60455de07sm5754478wma.15.2023.06.03.11.39.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Jun 2023 11:39:52 -0700 (PDT) Message-ID: <27662330-ec06-e06c-9b4a-e6483bd77c4b@draigBrady.com> Date: Sat, 3 Jun 2023 19:39:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Content-Language: en-US To: Paul Eggert , Sam James , 63850@debbugs.gnu.org References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 63850 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 03/06/2023 07:05, Paul Eggert wrote: > On 2023-06-02 09:31, Pádraig Brady wrote: >> I'm not sure it was working correctly before 9.3 either. >> Before 9.3 we would have switched from copy_file_range() to read()/write() > > Actually, cp shouldn't have been using copy_file_range at all, as the > code is supposed to never use copy_file_range unless the Linux kernel > version is 5.3 or later. See m4/copy-file-range.m4 and > lib/copy-file-range.c. > > Since the bug is being reported against kernel 4.19, someone needs to > investigate why the Gentoo build is using the copy_file_range syscall on > that kernel. Either the Gentoo build isn't properly compiling the > replacement function in coreutils/lib/copy-file-range.c, or the > replacement function is incorrectly deciding that the kernel is new > enough, or something like that. > > We shouldn't need to fiddle with src/copy.c on this. Yes good call on the kernel version checks. Though I think we should be a bit more accommodating for edge cases in code as fundamental as coreutils copy routines. Personally I would have a preference for accommodating the partial failure as originally proposed in the patch at https://bugs.gnu.org/62404#11 Personally I would definitely reinstate the _runtime_ kernel version check, for this bug and all the other copy_file_range() issues on older kernels. The runtime to build time change was originally discussed at: https://lists.gnu.org/archive/html/bug-gnulib/2022-01/msg00118.html cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 00:48:43 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 04:48:43 +0000 Received: from localhost ([127.0.0.1]:50660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Ocd-0007NL-5L for submit@debbugs.gnu.org; Tue, 06 Jun 2023 00:48:43 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:53234) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6Ocb-0007N4-2P for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 00:48:42 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 3CF653C10C5E2; Mon, 5 Jun 2023 21:48:35 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 50j1c85gG4CX; Mon, 5 Jun 2023 21:48:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id B1A0B3C10C5E3; Mon, 5 Jun 2023 21:48:34 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu B1A0B3C10C5E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686026914; bh=vY4Il/JnaeiGXSEB5LegG/zVFNZEgiSahBmEdI453S4=; h=Message-ID:Date:MIME-Version:To:From; b=jJqhLEZCRbqz29th+mx0ES3UelmWEysjON65FXLoaaQNljtKAKFSloy8cfD9gEKoh V9YyDpLC1xCwF/AcP+SE5AuqzUoGKZeOIjLzKrumsf7jCpJT1qk6kEGNiS5yGfVDFj ZuRfB0YTGcZwJdW/ISMoTSSNmBhGkI1jvd1udad2fRPxKEJ21r8o4qiZafC03Hptg1 9tvEv/m3tLwxZrL/DdZ/QQG3Cg5bw8GXrn9qdHGNh+JRFmn8t+6Bhh2QHFAG0MX0pM g/CFZZz6oz4vav07jkntao2eAz3N2pxa5YRP9XpbpmulZB0fxFxBtxilAyFBlz4IFk 1ZyAuUeJBj+6w== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EXCWqJZdSqhH; Mon, 5 Jun 2023 21:48:34 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 87DBC3C10C5E2; Mon, 5 Jun 2023 21:48:34 -0700 (PDT) Message-ID: Date: Mon, 5 Jun 2023 21:48:34 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Mike Gilbert , sam@gentoo.org, P@draigbrady.com, 63850@debbugs.gnu.org References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 63850 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 2023-06-03 06:54, Mike Gilbert wrote: > In this case, headers from linux-6.1 are being used at build time. > However, the code is being run on a linux-4.19 kernel. Gnulib doesn't support that. If you build with headers from a particular version of the operating system, you can't necessarily run on older versions. The reasons for this sort of restriction should be obvious. If Gentoo builds are regularly targeting older kernels or libraries than the platform they are building on, then surely that's a problem in general, not just here. I'll cc this to bug-gnulib to give them a heads-up about the issue. For gnulib readers, the original bug report is here: https://bugs.gnu.org/63850 From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 01:07:56 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 05:07:56 +0000 Received: from localhost ([127.0.0.1]:50665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6OvE-0007y1-2S for submit@debbugs.gnu.org; Tue, 06 Jun 2023 01:07:56 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:40218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6OvA-0007xk-DB for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 01:07:54 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 685E43C10C5E3; Mon, 5 Jun 2023 22:07:46 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id q-Nij8oS4ylN; Mon, 5 Jun 2023 22:07:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id C79F83C219E80; Mon, 5 Jun 2023 22:07:45 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu C79F83C219E80 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686028065; bh=m1WOebYdOcGcaVwrZxKDTAFp2sYefXVEbDSbMQ1jcVM=; h=Message-ID:Date:MIME-Version:From:To; b=TDq76jb0QEagJ2Ey5gljmiew3cgDnpAFfXb5fyP0GWBlrgqImc+tvn6ZFoHYjU35F I4srODcmfJ1F3wFWP9OD8+3TI4ouTlz2Zw8VuvOYqq/BkgJ5wrO0BNhEeiAO80KCtI dVWwtmxU1C/rS3W424xEOFLNi0aD2j2Mf3xwFthaLVamhn4dD+RaIvE19aqjRzekJF 6uGamhGRTUVc9xWzEgNRQdUxwt/ShUH8NEI7jDWF0Tfn+kDSwDlNdZQUozRNdyCPVq CzTLb9ToLvnjZuoxJAp9v9Qk1b927p99lZwNmhp4eBS9Y8pMQ09/akLXSW1hahkq4E qm4I5yRYK5gfA== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GkbDob9RPE0d; Mon, 5 Jun 2023 22:07:45 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 9901E3C10C5E3; Mon, 5 Jun 2023 22:07:45 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------ZA3Z8Lqc8DDg9i2Oo8DMNQg0" Message-ID: Date: Mon, 5 Jun 2023 22:07:45 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US From: Paul Eggert To: Mike Gilbert , sam@gentoo.org, P@draigbrady.com, 63850@debbugs.gnu.org References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> Organization: UCLA Computer Science Department Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported In-Reply-To: X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 63850 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) This is a multi-part message in MIME format. --------------ZA3Z8Lqc8DDg9i2Oo8DMNQg0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit If we really need to cater to the practice of building for an older system than the build host (which to my mind is asking for trouble), then instead of having Gnulib try to work around the bugs in copy_file_range in Linux kernels before 5.3, it should simply not use copy_file_range in these older kernels. In other words, something like the attached patch should be more reliable than the other band-aids proposed. --------------ZA3Z8Lqc8DDg9i2Oo8DMNQg0 Content-Type: text/x-patch; charset=UTF-8; name="0001-copy-file-range-support-building-for-older-kernels.patch" Content-Disposition: attachment; filename*0="0001-copy-file-range-support-building-for-older-kernels.patc"; filename*1="h" Content-Transfer-Encoding: base64 RnJvbSA4N2I5NWMxN2RjODYxMWY5NDgzYjk2NmQwNTJlZWZjOTMwZjQzOTI3IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBNb24sIDUgSnVuIDIwMjMgMjI6MDQ6MzcgLTA3MDAKU3ViamVjdDogW1BBVENI XSBjb3B5LWZpbGUtcmFuZ2U6IHN1cHBvcnQgYnVpbGRpbmcgZm9yIG9sZGVyIGtlcm5lbHMK CiogbTQvY29weS1maWxlLXJhbmdlLm00IChnbF9GVU5DX0NPUFlfRklMRV9SQU5HRSk6ClJl bW92ZSBzdGF0aWMgY2hlY2ssIHRvIHN1cHBvcnQgdGhlIGR1YmlvdXMgcHJhY3RpY2Ugb2YK YnVpbGRpbmcgZm9yIHBsYXRmb3JtcyB0aGF0IHByZWRhdGUgdGhlIGJ1aWxkIHBsYXRmb3Jt LgpPbiB3b3JraW5nIGtlcm5lbHMgdGhpcyBhZGRzIGFuIGV4dHJhIHN5c2NhbGwgdGhlIGZp cnN0IHRpbWUKdGhhdCBjb3B5X2ZpbGVfcmFuZ2UgaXMgdXNlZC4gIFByb2JsZW0gcmVwb3J0 ZWQgZm9yIEdlbnRvbyBieQpTYW0gSmFtZXMgPGh0dHBzOi8vYnVncy5nbnUub3JnLzYzODUw Pi4KLS0tCiBDaGFuZ2VMb2cgICAgICAgICAgICAgfCAgOCArKysrKysrKwogbTQvY29weS1m aWxlLXJhbmdlLm00IHwgMTggKysrLS0tLS0tLS0tLS0tLS0tCiAyIGZpbGVzIGNoYW5nZWQs IDExIGluc2VydGlvbnMoKyksIDE1IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL0NoYW5n ZUxvZyBiL0NoYW5nZUxvZwppbmRleCBkOGYwNGY3MzdkLi5hOTE3ZWI2M2E2IDEwMDY0NAot LS0gYS9DaGFuZ2VMb2cKKysrIGIvQ2hhbmdlTG9nCkBAIC0xLDUgKzEsMTMgQEAKIDIwMjMt MDYtMDUgIFBhdWwgRWdnZXJ0ICA8ZWdnZXJ0QGNzLnVjbGEuZWR1PgogCisJY29weS1maWxl LXJhbmdlOiBzdXBwb3J0IGJ1aWxkaW5nIGZvciBvbGRlciBrZXJuZWxzCisJKiBtNC9jb3B5 LWZpbGUtcmFuZ2UubTQgKGdsX0ZVTkNfQ09QWV9GSUxFX1JBTkdFKToKKwlSZW1vdmUgc3Rh dGljIGNoZWNrLCB0byBzdXBwb3J0IHRoZSBkdWJpb3VzIHByYWN0aWNlIG9mCisJYnVpbGRp bmcgZm9yIHBsYXRmb3JtcyB0aGF0IHByZWRhdGUgdGhlIGJ1aWxkIHBsYXRmb3JtLgorCU9u IHdvcmtpbmcga2VybmVscyB0aGlzIGFkZHMgYW4gZXh0cmEgc3lzY2FsbCB0aGUgZmlyc3Qg dGltZQorCXRoYXQgY29weV9maWxlX3JhbmdlIGlzIHVzZWQuICBQcm9ibGVtIHJlcG9ydGVk IGZvciBHZW50b28gYnkKKwlTYW0gSmFtZXMgPGh0dHBzOi8vYnVncy5nbnUub3JnLzYzODUw Pi4KKwogCW1hbnl3YXJuaW5nczogbW9yZSBudWFuY2UgYWJvdXQgb3B0aW1pemF0aW9uCiAJ KiBkb2MvbWFueXdhcm5pbmdzLnRleGkgKG1hbnl3YXJuaW5ncyk6IFN1Z2dlc3QgY29tcGls aW5nIHdpdGggdGhlCiAJb3B0aW1pemF0aW9uIGZsYWdzIGNvbW1vbmx5IHVzZWQsIGFzIG9w cG9zZWQgdG8gLU8yIGFuZCAtTzAKZGlmZiAtLWdpdCBhL200L2NvcHktZmlsZS1yYW5nZS5t NCBiL200L2NvcHktZmlsZS1yYW5nZS5tNAppbmRleCBkNDFmMmM0ODMxLi5mYTZhYjM0MTA5 IDEwMDY0NAotLS0gYS9tNC9jb3B5LWZpbGUtcmFuZ2UubTQKKysrIGIvbTQvY29weS1maWxl LXJhbmdlLm00CkBAIC0zOSwyMSArMzksOSBAQCBBQ19ERUZVTihbZ2xfRlVOQ19DT1BZX0ZJ TEVfUkFOR0VdLAogCiAgICAgY2FzZSAkaG9zdF9vcyBpbgogICAgICAgbGludXgqKQotICAg ICAgICBBQ19DQUNIRV9DSEVDSyhbd2hldGhlciBjb3B5X2ZpbGVfcmFuZ2UgaXMga25vd24g dG8gd29ya10sCi0gICAgICAgICAgW2dsX2N2X2NvcHlfZmlsZV9yYW5nZV9rbm93bl90b193 b3JrXSwKLSAgICAgICAgICBbQUNfQ09NUElMRV9JRkVMU0UoCi0gICAgICAgICAgICAgW0FD X0xBTkdfUFJPR1JBTSgKLSAgICAgICAgICAgICAgICBbWyNpbmNsdWRlIDxsaW51eC92ZXJz aW9uLmg+Ci0gICAgICAgICAgICAgICAgXV0sCi0gICAgICAgICAgICAgICAgW1sjaWYgTElO VVhfVkVSU0lPTl9DT0RFIDwgS0VSTkVMX1ZFUlNJT04gKDUsIDMsIDApCi0gICAgICAgICAg ICAgICAgICAgI2Vycm9yICJjb3B5X2ZpbGVfcmFuZ2UgaXMgYnVnZ3kiCi0gICAgICAgICAg ICAgICAgICAjZW5kaWYKLSAgICAgICAgICAgICAgICBdXSldLAotICAgICAgICAgICAgIFtn bF9jdl9jb3B5X2ZpbGVfcmFuZ2Vfa25vd25fdG9fd29yaz15ZXNdLAotICAgICAgICAgICAg IFtnbF9jdl9jb3B5X2ZpbGVfcmFuZ2Vfa25vd25fdG9fd29yaz1ub10pXSkKLSAgICAgICAg aWYgdGVzdCAiJGdsX2N2X2NvcHlfZmlsZV9yYW5nZV9rbm93bl90b193b3JrIiA9IG5vOyB0 aGVuCi0gICAgICAgICAgUkVQTEFDRV9DT1BZX0ZJTEVfUkFOR0U9MQotICAgICAgICBmaTs7 CisgICAgICAgICMgU2VlIGNvcHktZmlsZS1yYW5nZS5jIGNvbW1lbnQgcmUgcHJlLTUuMyBM aW51eCBrZXJuZWwgYnVncy4KKyAgICAgICAgIyBXZSBzaG91bGQgYmUgYWJsZSB0byByZW1v dmUgdGhpcyBoYWNrIGluIDIwMjUuCisgICAgICAgIFJFUExBQ0VfQ09QWV9GSUxFX1JBTkdF PTE7OwogICAgIGVzYWMKICAgZmkKIF0pCi0tIAoyLjM5LjIKCg== --------------ZA3Z8Lqc8DDg9i2Oo8DMNQg0-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 01:14:19 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 05:14:19 +0000 Received: from localhost ([127.0.0.1]:50673 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6P1P-0008BI-3O for submit@debbugs.gnu.org; Tue, 06 Jun 2023 01:14:19 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183]:57440 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6P1M-0008Aw-JO for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 01:14:17 -0400 References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> User-agent: mu4e 1.10.3; emacs 29.0.91 From: Sam James To: Paul Eggert Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Date: Tue, 06 Jun 2023 06:09:16 +0100 In-reply-to: Message-ID: <87mt1dcgv7.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63850 Cc: Mike Gilbert , P@draigbrady.com, 63850@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Paul Eggert writes: > On 2023-06-03 06:54, Mike Gilbert wrote: >> In this case, headers from linux-6.1 are being used at build time. >> However, the code is being run on a linux-4.19 kernel. > > Gnulib doesn't support that. If you build with headers from a > particular version of the operating system, you can't necessarily run > on older versions. The reasons for this sort of restriction should be > obvious. > This is a principle that other core parts of userland have no issue with. For example, util-linux has various fallbacks based on the *runtime* kernel version. This doesn't square with reality, anyway: if I install linux-6.1 and its headers, then I downgrade, I need to then rebuild every piece of the userland I built against the new headers. Tracking that as a user is nontrivial. > If Gentoo builds are regularly targeting older kernels or libraries > than the platform they are building on, then surely that's a problem > in general, not just here. Now, continuing from what I said above, it's not feasible to *require* users to use a kernel from the package manager. Not only do users want to be able to run their own kernel (sometimes even just for a quick test), but this is completely incompatible with having multiple kernels installed in parallel, as you can't have multiple versions of the same linux-headers in /usr/include. Going further: are we really suggesting that someone who was using say, Linux 6.1 for a few days, then downgrades to Linux 5.15 to test something is in an unsupported configuration? This isn't a practical position to have. This assumption *barely* holds for binary distributions where you "upgrade the world" all at once, and as I said, it's questionable there. And it's completely incompatible with source-based distributions. > > I'll cc this to bug-gnulib to give them a heads-up about the > issue. For gnulib readers, the original bug report is here: > > https://bugs.gnu.org/63850 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZH7AnV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCZGAEApfxp7ij/9lx3BoSjqlWwo93z/e7KMGWQaA0Q KKgeBkcBAIVmXt7YCu7kflTfgVysprCtWrALGOnAsULEnt4TzEIM =eOEH -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 01:28:34 2023 Received: (at submit) by debbugs.gnu.org; 6 Jun 2023 05:28:34 +0000 Received: from localhost ([127.0.0.1]:50685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6PFC-00008U-5V for submit@debbugs.gnu.org; Tue, 06 Jun 2023 01:28:34 -0400 Received: from lists.gnu.org ([209.51.188.17]:54010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6PF9-00008H-OA for submit@debbugs.gnu.org; Tue, 06 Jun 2023 01:28:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6PF5-0008Pc-Mz for bug-coreutils@gnu.org; Tue, 06 Jun 2023 01:28:31 -0400 Received: from mail.gentoo.org ([2001:470:ea4a:1:5054:ff:fec7:86e4] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1q6PF2-0004JC-P0 for bug-coreutils@gnu.org; Tue, 06 Jun 2023 01:28:27 -0400 References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> User-agent: mu4e 1.10.3; emacs 29.0.91 From: Sam James To: Sam James Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Date: Tue, 06 Jun 2023 06:26:37 +0100 In-reply-to: <87mt1dcgv7.fsf@gentoo.org> Message-ID: <87fs75cg7r.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2001:470:ea4a:1:5054:ff:fec7:86e4; envelope-from=sam@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -39 X-Spam_score: -4.0 X-Spam_bar: ---- X-Spam_report: (-4.0 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TO_EQ_FM_DIRECT_MX=0.254, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@gnu.org, Paul Eggert , P@draigbrady.com, Mike Gilbert , 63850@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain Sam James writes: > [[PGP Signed Part:Undecided]] > > Paul Eggert writes: > >> On 2023-06-03 06:54, Mike Gilbert wrote: >>> In this case, headers from linux-6.1 are being used at build time. >>> However, the code is being run on a linux-4.19 kernel. >> >> Gnulib doesn't support that. If you build with headers from a >> particular version of the operating system, you can't necessarily run >> on older versions. The reasons for this sort of restriction should be >> obvious. >> > > This is a principle that other core parts of userland have no issue > with. For example, util-linux has various fallbacks based on the > *runtime* kernel version. > > This doesn't square with reality, anyway: if I install linux-6.1 > and its headers, then I downgrade, I need to then rebuild every > piece of the userland I built against the new headers. Tracking > that as a user is nontrivial. > >> If Gentoo builds are regularly targeting older kernels or libraries >> than the platform they are building on, then surely that's a problem >> in general, not just here. > > Now, continuing from what I said above, it's not feasible to *require* > users to use a kernel from the package manager. Not only do users want > to be able to run their own kernel (sometimes even just for a quick > test), but this is completely incompatible with having multiple kernels > installed in parallel, as you can't have multiple versions of the > same linux-headers in /usr/include. > > Going further: are we really suggesting that someone who was using > say, Linux 6.1 for a few days, then downgrades to Linux 5.15 to test > something is in an unsupported configuration? > > This isn't a practical position to have. This assumption *barely* > holds for binary distributions where you "upgrade the world" all > at once, and as I said, it's questionable there. And it's completely > incompatible with source-based distributions. Just to be clear: I totally agree this isn't feasible for general libraries (and their headers). It's just that linux-headers is a special case, because you can't easily juggle different versions of it, and it's expected that users may vary their kernel version. Also, glibc says the latest should always be fine: https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F. Of course, gnulib isn't glibc, but I'm pointing out that this is established practice. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZH7D6F8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDejAD/SP6n+f3y/y96EqM/ogjp8pFAYQcZujt/m77R O5baXXIA/j52OqMonJpoC9Y7P1I+TltMOBQeEqnvDL5AEE13aCIP =x9G3 -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 01:48:36 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 05:48:36 +0000 Received: from localhost ([127.0.0.1]:50692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6PYa-0000pi-7c for submit@debbugs.gnu.org; Tue, 06 Jun 2023 01:48:36 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:57744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6PYY-0000p4-2R for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 01:48:35 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 08A6A3C09FA21; Mon, 5 Jun 2023 22:48:28 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ab8_LnEOwUS9; Mon, 5 Jun 2023 22:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id B57F73C10C5E3; Mon, 5 Jun 2023 22:48:27 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu B57F73C10C5E3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686030507; bh=3U5dpk7PFjGPBg6yeaK8wf0TWSIyxAzghmS0m1zX398=; h=Message-ID:Date:MIME-Version:To:From; b=Q4CLuLf0xs+yKG9G0FKof+nFpIfFw898feGh2wk8bbXf+Rttcd00YvNVZabWAtHCf L6ffd1n2uUjcXMo+xMXqKCn0FyChj3dfzwXIOdb0mxHWiBxRDACiVBQIrDA3WphmUZ 8DRNjpXyqm4oHAi/aP1GCquYa70/55P5lLB5vXy3igI2//poy/4//4WWFZ8Vi19/9Y QLceaP5DgEeSYRDcvYS7UUPl2WZ7TKwdX+sM0J8EsqfJrCqBwHqJ10nbJP1GTAVESX 5EyilWxVjfAAqvf3vxTaVgZE6uoEU/Rn9uR0QzWxLkoSxbExFQBKAXM0ZfitxFIAQd a9CRjtLS3d9LQ== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WtHg58K7qmMr; Mon, 5 Jun 2023 22:48:27 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 849313C09FA21; Mon, 5 Jun 2023 22:48:27 -0700 (PDT) Message-ID: <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> Date: Mon, 5 Jun 2023 22:48:27 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Sam James References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported In-Reply-To: <87fs75cg7r.fsf@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 63850 Cc: 63850@debbugs.gnu.org, P@draigbrady.com, floppym@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 2023-06-05 22:26, Sam James wrote: > It's just that linux-headers is > a special case Indeed it is. And apparently glibc avoids the copy_file_range bugs by never, ever using copy_file_range internally - which explains why glibc hasn't run into this backward compatibility issue. Presumably once glibc starts assuming kernel 5.3 or later, it can start using copy_file_range internally. Anyway, thanks for explaining. I installed the patch I mentioned into Gnulib and have updated coreutils accordingly on Savannah master. Please give it a try. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 05:54:01 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 09:54:01 +0000 Received: from localhost ([127.0.0.1]:50997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6TO4-0007sA-M2 for submit@debbugs.gnu.org; Tue, 06 Jun 2023 05:54:00 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:55316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6TO2-0007rw-M1 for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 05:53:59 -0400 Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-30c5e5226bdso3964575f8f.2 for <63850@debbugs.gnu.org>; Tue, 06 Jun 2023 02:53:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686045232; x=1688637232; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=Xus1PtwIkTmkexrmqsIx/NDjB9xw+0CKyKGj58mKQWU=; b=dHNX7eDEZiBxiN2guZjpBd0l1YeeGFed7kIJC6ggg37nuI45H1mfNk+q+OFSWp+C43 nFni5TwxsBqDDYE0I54M2z5xWig3efxzzGnrG9mphY81WuNYOAxu6B0WALVgkdWEVXbh zyN8MZMSJLgWZTAds0SMVb/KbgQ4JTOooKCknqeu/7Ttz4Kcx6WRED4KuXCog2w60oAv BPPrc2kd36f+6+YX5cI18C+0WyXUvVWgfFpTyyQYfXF4apuvAgt3WkO5AGq/76dA7K51 W+sgLTbtFQpmIN/jZtRnQzlwEBQdHh3WhZE+GD6qeZQ4ch9PqvHikWkOJ2Ow1jL7pt0Q a5TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686045232; x=1688637232; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Xus1PtwIkTmkexrmqsIx/NDjB9xw+0CKyKGj58mKQWU=; b=koJLhUGGrVR23MHdLUhOzVUEfAvq5GSMo8weX3chqAnUzoQT516sR9ynNmedegH2BN v0LqucHgkAA1GlJS+lPmb+ykYIkiqPEUZ0IaD5AO4C7IFZvp1eP7LN3I6DuFqaQps9Fv sSfTMjHvbvxc9Mt6q9f7qSINWUmoWHMcH8bgdawR2wNzeqAjUIUL/ZbpWf8DaXG/iBzi hRgMgBRHiW2h8KE/+KtPokFSS7C5lUbd+kMNBb3Euf5e1pM3k07QsYgs+QI/8wtPJK1z H4QnFPJFDiggjtQzQuSBIwMDjUB/W6eXsigr7iOJ0tCf08lFbszlnCsz+47EkOW6wWHj LsRA== X-Gm-Message-State: AC+VfDxNpnK/nZ23atfeLcYQwlOLXPWrRLtCopNA4lwCUHWYFY7uKNXM xBZoT7Yu5Ygiq5OyE3af+4g= X-Google-Smtp-Source: ACHHUZ60ZLIEYvQJl5J7T4RnMRO/SV31fZWRbcG/twFZvqSw1Te5fhVCuBhLYppXsov8IgJ0Ye4S6g== X-Received: by 2002:a5d:4e84:0:b0:306:32c4:7e7b with SMTP id e4-20020a5d4e84000000b0030632c47e7bmr1317139wru.41.1686045232425; Tue, 06 Jun 2023 02:53:52 -0700 (PDT) Received: from [192.168.1.19] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id b11-20020a05600010cb00b0030ae973c2e7sm12195408wrx.83.2023.06.06.02.53.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jun 2023 02:53:51 -0700 (PDT) Message-ID: <2cab32d9-0235-f1a4-752c-2480c5862456@draigBrady.com> Date: Tue, 6 Jun 2023 10:53:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Content-Language: en-US To: Paul Eggert , Sam James References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 63850 Cc: 63850@debbugs.gnu.org, floppym@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 06/06/2023 06:48, Paul Eggert wrote: > On 2023-06-05 22:26, Sam James wrote: >> It's just that linux-headers is >> a special case > > Indeed it is. And apparently glibc avoids the copy_file_range bugs by > never, ever using copy_file_range internally - which explains why glibc > hasn't run into this backward compatibility issue. Presumably once glibc > starts assuming kernel 5.3 or later, it can start using copy_file_range > internally. Yes, glibc has the --enable-kernel configure option to allow setting the compatibility range independently from the build host (kernel headers). In my experience a distro needs to support quite a range of kernel versions mainly due to certain hardware platforms being tied to older kernels. > Anyway, thanks for explaining. I installed the patch I mentioned into > Gnulib and have updated coreutils accordingly on Savannah master. Please > give it a try. Thanks for making the change Paul. Pádraig From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 06:03:25 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 10:03:25 +0000 Received: from localhost ([127.0.0.1]:51013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6TXB-0002Bq-ES for submit@debbugs.gnu.org; Tue, 06 Jun 2023 06:03:25 -0400 Received: from woodpecker.gentoo.org ([140.211.166.183]:36216 helo=smtp.gentoo.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6TXA-0002Bd-0m for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 06:03:24 -0400 References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> User-agent: mu4e 1.10.3; emacs 29.0.91 From: Sam James To: Paul Eggert Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Date: Tue, 06 Jun 2023 11:02:32 +0100 In-reply-to: <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> Message-ID: <87zg5c52n2.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63850 Cc: 63850@debbugs.gnu.org, P@draigbrady.com, floppym@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --=-=-= Content-Type: text/plain Paul Eggert writes: > On 2023-06-05 22:26, Sam James wrote: >> It's just that linux-headers is >> a special case > > Indeed it is. And apparently glibc avoids the copy_file_range bugs by > never, ever using copy_file_range internally - which explains why > glibc hasn't run into this backward compatibility issue. Presumably > once glibc starts assuming kernel 5.3 or later, it can start using > copy_file_range internally. > > Anyway, thanks for explaining. I installed the patch I mentioned into > Gnulib and have updated coreutils accordingly on Savannah > master. Please give it a try. Thanks Paul. Do you know if there's any other cases of this in gnulib? (or whether, by chance, if you know off the top of your head if any other gnulib consumers definitely use copy_file_range?) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZH8EYV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZAfUQEA/aR2j6daVEyg+3uVZHSmm7RenqFCnF6o6Y8v J+Fj538BAK/2rz4Hd5gYx/w4kRpikLrS9ZBsTida2QEbQFCdOIgP =C8uv -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 06 06:27:23 2023 Received: (at 63850) by debbugs.gnu.org; 6 Jun 2023 10:27:23 +0000 Received: from localhost ([127.0.0.1]:51032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6TuN-0002xx-D8 for submit@debbugs.gnu.org; Tue, 06 Jun 2023 06:27:23 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:50665) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6TuK-0002xg-PW for 63850@debbugs.gnu.org; Tue, 06 Jun 2023 06:27:21 -0400 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-3f739ec88b2so20430565e9.1 for <63850@debbugs.gnu.org>; Tue, 06 Jun 2023 03:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686047235; x=1688639235; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=OiiQ5xNxfoGYJNcIz6Kcb6L9oX1Vbtyb9wrZErJ5AEo=; b=B5TOL3h3B/z8EQUWjBrFf48EVP+YYn+aO1BWBtBOkSTYR1kTQ48qMvDGlvv0GrS+t9 0urA2oGIs9+yudgMKGrQZOkqehVIPfZKvM05EcAfke5nLUM24F13D7cxuuHd4arcQpOf aSm4bFJI8X3waBj5zblC9O92kUuzjg/Nsh324gQLARbCYj3oq35iS7Oqf6vIVKCEtJPV KcJSRGzvfGtGfkr9bidiYcNlc+rPtku3LAZXJufUiAXuY0BOVUgp16qntqH1XxOlWizU HjjlgMx3kGtCpe6URptfZsZRdxBYerIvdfQ4mf7CYmSQ549XKqAcmQMbXgZ81D/eLqpQ snBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686047235; x=1688639235; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OiiQ5xNxfoGYJNcIz6Kcb6L9oX1Vbtyb9wrZErJ5AEo=; b=AsWGtUBso74gjIx3c8UlK21J3KpEsOnmIrpZ8r6FIbzVnIb7G6Zrenez1SlpCSNmM9 ZfxGvZnTpbRwLsVYneWucD1wWgQFKzVF3YE15ZBot6hXRFK8XLTmQjPnhYO7fiXD/kqV 695tdIiKE8vOZOjR1lDyk48kKdJgISTMS/XqYx9wPZyn77oG2i5oJq4aDJ/9QGfTkoPh kh8YEisj8oWWkU4et88ho22ILBtsklwVvnwW14OzLUVGuIWygL4zG4UJh/esUlQhgITQ xHHwU2buyd49vgVPedihz+uDvZ3j0MDh/K0axLrHsxfihY85MiXqajSltBI94Ds5nuu+ zsRQ== X-Gm-Message-State: AC+VfDwdRXyoUSVhQwTLcsR+JFX6a4qqRNwbwR2RLN8IyI+QHQN+3mud q35pg/IpTB5J9/UJJCnFW5cYEvx4404= X-Google-Smtp-Source: ACHHUZ5TMVup9ixmZwo2J1oxzlZttvbam6L/jnifS6k2A7t6UbVLkIH3ite3euTBEWRvIRh8F2NHSA== X-Received: by 2002:a7b:cd8f:0:b0:3f6:148f:5867 with SMTP id y15-20020a7bcd8f000000b003f6148f5867mr1661373wmj.4.1686047234519; Tue, 06 Jun 2023 03:27:14 -0700 (PDT) Received: from [192.168.1.19] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id v10-20020a05600c470a00b003f1978bbcd6sm2240216wmo.3.2023.06.06.03.27.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jun 2023 03:27:13 -0700 (PDT) Message-ID: Date: Tue, 6 Jun 2023 11:27:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Content-Language: en-US To: Sam James , Paul Eggert References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> <87zg5c52n2.fsf@gentoo.org> From: =?UTF-8?Q?P=C3=A1draig_Brady?= In-Reply-To: <87zg5c52n2.fsf@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 63850 Cc: 63850@debbugs.gnu.org, floppym@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 06/06/2023 11:02, Sam James wrote: > > Paul Eggert writes: > >> On 2023-06-05 22:26, Sam James wrote: >>> It's just that linux-headers is >>> a special case >> >> Indeed it is. And apparently glibc avoids the copy_file_range bugs by >> never, ever using copy_file_range internally - which explains why >> glibc hasn't run into this backward compatibility issue. Presumably >> once glibc starts assuming kernel 5.3 or later, it can start using >> copy_file_range internally. >> >> Anyway, thanks for explaining. I installed the patch I mentioned into >> Gnulib and have updated coreutils accordingly on Savannah >> master. Please give it a try. > > Thanks Paul. Do you know if there's any other cases of this in gnulib? > > (or whether, by chance, if you know off the top of your head if any > other gnulib consumers definitely use copy_file_range?) Both google and cs.github.com suggest only coreutils uses copy-file-range from gnulib: https://www.google.com/search?q=filetype%3Aconf+%22copy-file-range%22 cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 15:13:41 2023 Received: (at 63850-done) by debbugs.gnu.org; 7 Jun 2023 19:13:41 +0000 Received: from localhost ([127.0.0.1]:54757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6ybF-0002cF-2J for submit@debbugs.gnu.org; Wed, 07 Jun 2023 15:13:41 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:37036) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6ybA-0002by-2d for 63850-done@debbugs.gnu.org; Wed, 07 Jun 2023 15:13:39 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id DB08F3C02213D; Wed, 7 Jun 2023 12:13:29 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id GHM6YBJZ4VmR; Wed, 7 Jun 2023 12:13:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 840BD3C09FA19; Wed, 7 Jun 2023 12:13:29 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 840BD3C09FA19 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686165209; bh=mGXetDvD8K0fi1Xbi8GyyfmX/T/oYwwc8kFz/+c3lWI=; h=Message-ID:Date:MIME-Version:To:From; b=ZlpiXHwGaFeCMl4kXqR1qGPZg7kBvUzPraYk914+obm7OqV3IoXH6VbGY5M9WmXAV ndHgkhEDPLFVKXMKoFdQ2xXF5TnhOgD7YNb9JDvWIM4I7y3L3r1U5VMsGscY3ALksF cYCU3gy0dQQwf/pRWQOfwYmzNrKasYbnKwOwZOHFAQ2Ej/SKRelbw4bZ8/GB/DZdQZ KeXYS0CUVj7qPAvBvzKyq3/vcmLqHfUhygaek629kVcyUsiGLE9KoAuzdIGdJOEanL sdBRfDcQO0Pb1Mb/OSl3eAePeZNCd6If/eICPrsAZROrfnN9aZIaoPAjiynaF3MdOr /WC9rc3eLr2LA== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ytP9pZHhZAH4; Wed, 7 Jun 2023 12:13:29 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 58D433C02213D; Wed, 7 Jun 2023 12:13:29 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2023 12:13:28 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 To: Sam James References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> <87zg5c52n2.fsf@gentoo.org> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported In-Reply-To: <87zg5c52n2.fsf@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 63850-done Cc: floppym@gentoo.org, P@draigbrady.com, 63850-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 2023-06-06 03:02, Sam James wrote: > Thanks Paul. Do you know if there's any other cases of this in gnulib? There's no other use of linux/version.h in Gnulib. However, this doesn't mean there are no other instances of the problem, as it's common to assume that you'll run on a host no older than the build host. Every use of Autoconf macros like AC_RUN_IFELSE assume this sort of thing, and I would not be surprised if there are other examples of this more-general problem when some builders (unwisely) build apps intended to run on platforms older than the build platform. (For what it's worth, I count 331 uses of AC_RUN_IFELSE in Gnulib; it'd be a pain to audit them all.) It's OK to build glibc for Linux kernels somewhat older than the build kernel, since glibc explicitly exports that. But it's not OK to build other packages that way, since they don't support it. You'll get away with it in many cases, but when it doesn't work then the problem is on the builder, not on the packages being built. > (or whether, by chance, if you know off the top of your head if any > other gnulib consumers definitely use copy_file_range?) Other coreutils programs like 'install' use copy_file_range. Emacs uses it. I just now installed the following patch into bleeding-edge Emacs to work around the problem, by updating to current Gnulib. This workaround should appear in Emacs 30, whenever that happens (not for a year or two I'd think, as Emacs 29 isn't out yet). https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a902156068ab071f93cc9bbd34cd320919b74064 PS. I'm boldly marking the coreutils bug as fixed. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 15:26:33 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 19:26:33 +0000 Received: from localhost ([127.0.0.1]:54785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6yng-0002ws-Vv for submit@debbugs.gnu.org; Wed, 07 Jun 2023 15:26:33 -0400 Received: from lists.gnu.org ([209.51.188.17]:57378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6yne-0002wg-QG for submit@debbugs.gnu.org; Wed, 07 Jun 2023 15:26:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6ync-0007EQ-6a for bug-coreutils@gnu.org; Wed, 07 Jun 2023 15:26:28 -0400 Received: from dev.gentoo.org ([2001:470:ea4a:1:5054:ff:fec7:86e4] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1q6ynZ-0000MQ-Tm for bug-coreutils@gnu.org; Wed, 07 Jun 2023 15:26:27 -0400 References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> <87zg5c52n2.fsf@gentoo.org> User-agent: mu4e 1.10.3; emacs 29.0.91 From: Sam James To: Paul Eggert Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Date: Wed, 07 Jun 2023 20:21:52 +0100 In-reply-to: Message-ID: <878rcvnkfh.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Received-SPF: pass client-ip=2001:470:ea4a:1:5054:ff:fec7:86e4; envelope-from=sam@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@gnu.org, floppym@gentoo.org, P@draigbrady.com, 63850-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain Paul Eggert writes: > On 2023-06-06 03:02, Sam James wrote: >> Thanks Paul. Do you know if there's any other cases of this in gnulib? > > There's no other use of linux/version.h in Gnulib. However, this > doesn't mean there are no other instances of the problem, as it's > common to assume that you'll run on a host no older than the build > host. Every use of Autoconf macros like AC_RUN_IFELSE assume this sort > of thing, and I would not be surprised if there are other examples of > this more-general problem when some builders (unwisely) build apps > intended to run on platforms older than the build platform. (For what > it's worth, I count 331 uses of AC_RUN_IFELSE in Gnulib; it'd be a > pain to audit them all.) > > It's OK to build glibc for Linux kernels somewhat older than the build > kernel, since glibc explicitly exports that. But it's not OK to build > other packages that way, since they don't support it. You'll get away > with it in many cases, but when it doesn't work then the problem is on > the builder, not on the packages being built. I don't see how this is compatible with what I explained, given you can't have parallel linux-headers installs. Nobody uses glibc in a vacuum, either, so it's not particularly meaningful to say you can use glibc but nothing else in that way. If you object to this, please bring it up on the glibc mailing list to discuss revising the guidance. But again, I genuinely don't see how anything other than the status quo could work. We can't enforce what kernels users are running, and we can't simultaneously make the users install the headers for the kernel they just built manually while also having things owned and controlled by the package manager. We're also very much not the only distribution doing this - Arch usually ships the latest linux-headers, and Alpine does as well. And we've done it for years with very, very few issues. > > >> (or whether, by chance, if you know off the top of your head if any >> other gnulib consumers definitely use copy_file_range?) > > Other coreutils programs like 'install' use copy_file_range. > > Emacs uses it. I just now installed the following patch into > bleeding-edge Emacs to work around the problem, by updating to current > Gnulib. This workaround should appear in Emacs 30, whenever that > happens (not for a year or two I'd think, as Emacs 29 isn't out yet). > > https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a902156068ab071f93cc9bbd34cd320919b74064 > Thanks! > PS. I'm boldly marking the coreutils bug as fixed. Works for me, thanks. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZIDZ018UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDq9AEAgdsfhk+t7ji1j6KJFmYE3dSFcV86PtALBTWh UhXo3GUA/0U9/v6qi+BcmbFrviMmfJUSKfXh/NH+jKs0siuhUS0D =qrCB -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 07 15:44:37 2023 Received: (at submit) by debbugs.gnu.org; 7 Jun 2023 19:44:37 +0000 Received: from localhost ([127.0.0.1]:54852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6z5B-0003Rd-AU for submit@debbugs.gnu.org; Wed, 07 Jun 2023 15:44:37 -0400 Received: from lists.gnu.org ([209.51.188.17]:59186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q6z59-0003R9-E1 for submit@debbugs.gnu.org; Wed, 07 Jun 2023 15:44:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6z58-0001Qh-Pw for bug-coreutils@gnu.org; Wed, 07 Jun 2023 15:44:34 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q6z56-0003p1-95 for bug-coreutils@gnu.org; Wed, 07 Jun 2023 15:44:34 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id AA6223C02213D; Wed, 7 Jun 2023 12:44:29 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m2NDAAQmw9Cm; Wed, 7 Jun 2023 12:44:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 474F23C09FA06; Wed, 7 Jun 2023 12:44:29 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 474F23C09FA06 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686167069; bh=sfHARsNlARzezdb1RmIiRf+A5g/vDtC9bNkOIFRHwic=; h=Message-ID:Date:MIME-Version:To:From; b=b4hYMLeMS243yzdndh3wce6ow3T6v9Q6UkmgqoDLjIpfAY9OF36NXdYsDhLp7EhG7 /2tRNT6UgZzaTWbnkLdcAYHfIIMzSqru5m8dU64C+WjZtLn9wOpcWpwUBq9vsNlvwq HLMHFNrqtZXpR/PeEWhJ37uK+Tr7G9zbhH53kt6Jz8Zd0QfHXIK+TgxehmBMunzSFD 6G/rfJW1+UdH9EKR05Gc24KW+3vgZpgQ3/MEqUUfrSimoo+6zWlW24poV3U8voaJ5K DDOWzCzjhEAkBKqWVUi9DW2szFULeYVTnhjsCGmeE/4oOpLyyjI2Z8YIBk2fGWXMiZ yvuvsc+UJqqxw== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HiojE7YjNScy; Wed, 7 Jun 2023 12:44:29 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 122B23C02213D; Wed, 7 Jun 2023 12:44:29 -0700 (PDT) Message-ID: Date: Wed, 7 Jun 2023 12:44:28 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Sam James References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> <87zg5c52n2.fsf@gentoo.org> <878rcvnkfh.fsf@gentoo.org> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported In-Reply-To: <878rcvnkfh.fsf@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.66; envelope-from=eggert@cs.ucla.edu; helo=mail.cs.ucla.edu X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.091, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: submit Cc: bug-coreutils@gnu.org, floppym@gentoo.org, P@draigbrady.com, 63850-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.5 (---) On 2023-06-07 12:21, Sam James wrote: > I don't see how this is compatible with what I explained, given you > can't have parallel linux-headers installs. > > Nobody uses glibc in a vacuum, either, so it's not particularly > meaningful to say you can use glibc but nothing else in that way. > > If you object to this, please bring it up on the glibc mailing list > to discuss revising the guidance. There must be some miscommunication here. I'm not objecting to how glibc is built, and I don't see why the glibc mailing list would be interested in this problem as it's not their problem. > We can't enforce > what kernels users are running, and we can't simultaneously make the > users install the headers for the kernel they just built manually while > also having things owned and controlled by the package manager. > > We're also very much not the only distribution doing this - Arch > usually ships the latest linux-headers, and Alpine does as well. > And we've done it for years with very, very few issues. That's not surprising, as this sort of problem arises only when building for a newer platform yields a package that will run incorrectly on an older platform. Problems like these are relatively rare if the only such mismatch is the Linux kernel version, because current glibc explicitly supports building for Linux kernel>=3.2, even when glibc is built on newer kernels, these days nobody doing this sort of thing cares about kernels older than 3.2, and most packages rely entirely on glibc to access the kernel. There are exceptional packages, though, and you may run into problems with those exceptions. If users build for newer platforms and it usually works on older platforms, that's great! But you might want to document that it might not work. Because it might not. From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 07:45:04 2023 Received: (at 63850) by debbugs.gnu.org; 8 Jun 2023 11:45:05 +0000 Received: from localhost ([127.0.0.1]:55771 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7E4e-00054H-HV for submit@debbugs.gnu.org; Thu, 08 Jun 2023 07:45:04 -0400 Received: from mout-p-202.mailbox.org ([80.241.56.172]:49026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7E4a-00053S-Lb for 63850@debbugs.gnu.org; Thu, 08 Jun 2023 07:45:02 -0400 Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4QcMnw4FFdz9sdB; Thu, 8 Jun 2023 13:44:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1686224692; 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=BpVpGr4O31KSiLjpZasaUtYIV8VkQF3zQIpX+3B60Es=; b=ImTl3weJG2idwKcHnx0BWLDDPCAIBsqNMAKcDwzRRizYXU3JQf8Abo2SaKsO+DLqsJt/uE aFlPBKEesfCn4j7+4/h//xD1mfH0+3frL0CfT/PvAWBafBtgBWtg7O5AFzJFGiwETMCPd4 nCJQ6jChB9m4TdJJGhBGIM8V+G8X2zmMOkjQodSkEk3X8Vw7DjRhLYZzvLI4rpDC59bix3 EZ+az7fvxt5RIuf+pYGs8Umh7Yb8FhXnd7FgSYVMszDhsFGsyTiGXppbA2+/PP2je3B4pe 1KquG1OvjZTbLcQRx4+ZIbk0iQlO3RScrseeI2y/f0pcbp63Bq6CVkh+wuRxJQ== References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> <87zg5c52n2.fsf@gentoo.org> <878rcvnkfh.fsf@gentoo.org> From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Paul Eggert Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported Date: Thu, 08 Jun 2023 13:28:55 +0200 In-reply-to: Message-ID: <86ilby18lr.fsf@aarsen.me> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 63850 Cc: 63850@debbugs.gnu.org, P@draigbrady.com, Sam James , floppym@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Eggert writes: > That's not surprising, as this sort of problem arises only when building = for a > newer platform yields a package that will run incorrectly on an older > platform. Problems like these are relatively rare if the only such mismat= ch is > the Linux kernel version, because current glibc explicitly supports build= ing > for Linux kernel>=3D3.2, even when glibc is built on newer kernels, these= days > nobody doing this sort of thing cares about kernels older than 3.2, and m= ost > packages rely entirely on glibc to access the kernel. There are exception= al > packages, though, and you may run into problems with those exceptions. > > If users build for newer platforms and it usually works on older platform= s, > that's great! But you might want to document that it might not work. Beca= use it > might not. In this instance, we have a configure-time test that makes a false assumption (namely, that linux-headers version matches the linux version), preventing a very valid runtime test from being emitted. The cost for enabling this check is removing a dozen or so lines of code in copy-file-range.m4 (and the subsequent addition of a few instructions and a single syscall that is executed once). It is entirely reasonable to expect that a user will roll back a kernel update, as there are many reasons one might have to do so. This is not quite comparable to downgrading libraries (which will, reasonably, break as a result), because the kernel<->userspace boundary is of very different nature to the library<->* boundary (namely, the former is far more 'loose', in the sense that failure to implement something manifests as a runtime failure rather than a build-time, or even rtld-time failure). It is no coincidence that glibc explicitly supports kernels older than the linux-headers it's being built with. I'd understand not wanting to support this use-case in the cases where doing so is difficult, but here, it's more difficult to not support this use-case than to support it. Please reconsider dropping the configure-time version check. Thanks in advance, have a lovely day. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOYEARYKAI4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZIG/MF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTo1YBAIfCPsSEDlTH0AK86U00WqIswd9+Ibkr29SX IPqIjJDtAPwPPxRSVFTDjUuCy/wIDgs2D3LB3XypcGMkbkM7ZW/eBw== =HIte -----END PGP SIGNATURE----- --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 08 13:44:39 2023 Received: (at 63850) by debbugs.gnu.org; 8 Jun 2023 17:44:39 +0000 Received: from localhost ([127.0.0.1]:57502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7Jgd-0000k8-Fj for submit@debbugs.gnu.org; Thu, 08 Jun 2023 13:44:39 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:39564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q7JgZ-0000jp-Sh for 63850@debbugs.gnu.org; Thu, 08 Jun 2023 13:44:37 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 71CAB3C020F7C; Thu, 8 Jun 2023 10:44:29 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id oygFbDGm6p1k; Thu, 8 Jun 2023 10:44:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 28AE23C02213D; Thu, 8 Jun 2023 10:44:29 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 28AE23C02213D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1686246269; bh=mrPPqBecPSS3d70Eg5kN6pdCS/+/CXWQD0Tee1o5jj8=; h=Message-ID:Date:MIME-Version:To:From; b=AiNR0w/nv41VvE7zvwHthc2cDHjsr/z7m9+k9G5uDPk5So8rVTmo6g06Z2pUNk3w/ 1vEzRfMJoiz/tbkhKA1jT8FxlLZC6VPGkUc5EBYD3jrFELcXAAkeCKst2jvqyQSkpT jJQSv0CYjbhZU1yWCb1KLcriskJ3sR80bOnWwFKlJ/JvH8t2hy+i4/1PC/ysgsF97L KJG3JdXK70YDowVDAe9LvW0VELWWElefZe7icEev1Uu9mFWx9WugAgHMdweKlKufhb 7TUbi+77DiEq+S4iKI1dXonqDLmuQDUGvjkElZzPUy+IJOtLxcDcI/QRo5guZlbC5+ Bf48yGxjXFpbw== X-Virus-Scanned: amavisd-new at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yb57_hv1mt-F; Thu, 8 Jun 2023 10:44:29 -0700 (PDT) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 102C43C020F7C; Thu, 8 Jun 2023 10:44:29 -0700 (PDT) Message-ID: <1a74583f-b4f7-9289-5e0f-b9be2fdf3780@cs.ucla.edu> Date: Thu, 8 Jun 2023 10:44:25 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is unsupported To: =?UTF-8?Q?Arsen_Arsenovi=c4=87?= References: <87h6rpn9uw.fsf@gentoo.org> <4d879076-5c94-f2ca-a00a-a7367c396d4e@draigBrady.com> <6498b526-d537-d79a-2881-31b014691df1@cs.ucla.edu> <87mt1dcgv7.fsf@gentoo.org> <87fs75cg7r.fsf@gentoo.org> <646de69d-a23e-8f59-167f-6e7476abc484@cs.ucla.edu> <87zg5c52n2.fsf@gentoo.org> <878rcvnkfh.fsf@gentoo.org> <86ilby18lr.fsf@aarsen.me> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <86ilby18lr.fsf@aarsen.me> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 63850 Cc: 63850@debbugs.gnu.org, P@draigbrady.com, Sam James , floppym@gentoo.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 6/8/23 04:28, Arsen Arsenovi=C4=87 wrote: > Please reconsider dropping the configure-time version check. I already dropped it, so this discussion is more about the general=20 principle than this particular case. > It is entirely reasonable to expect that a user will roll back a kernel > update, as there are many reasons one might have to do so. Sure, but if they do so, and if programs use configure-time checks whose=20 results depend on the kernel version, users will have to rebuild and=20 reconfigure these programs. That's just a fact of life. This is not just a Gnulib issue. Many=20 programs do lots of configure-time checks. Nobody that I know of has=20 time to audit them all. *Usually* rolling back the kernel will work, because *usually* it's a=20 small rollback and programs built for a newer kernel won't exercise the=20 small area where the kernels differ in a way that will cause=20 user-visible symptoms. But in general it does not work, and cannot reasonably be expected to work. So: when in doubt, rebuild. Of course if you've carefully audited the=20 program and know that its configure-time tests are valid for the older=20 kernel, you can skip the rebuild. Or if building speed is more important=20 to you than reliable applications, you can also skip the rebuild. From unknown Sun Aug 17 09:09:49 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 07 Jul 2023 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator