GNU bug report logs - #63850
cp fails for files > 2 GB if copy offload is unsupported

Previous Next

Full log

Message #73 received at 63850 <at> debbugs.gnu.org (full text, mbox):

From: Arsen Arsenović <arsen <at> aarsen.me>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 63850 <at> debbugs.gnu.org, P <at> draigbrady.com, Sam James <sam <at> gentoo.org>,
 floppym <at> gentoo.org
Subject: Re: bug#63850: cp fails for files > 2 GB if copy offload is
 unsupported
Date: Thu, 08 Jun 2023 13:28:55 +0200

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> cs.ucla.edu> 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 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.

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.
-- 
Arsen Arsenović

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.