bug#63850: cp fails for files > 2 GB if copy offload is unsupported

[Paul Eggert]

On 6/8/23 04:28, Arsen Arsenović wrote:

Please reconsider dropping the configure-time version check.


I already dropped it, so this discussion is more about the general 
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 
results depend on the kernel version, users will have to rebuild and 
reconfigure these programs.


That's just a fact of life. This is not just a Gnulib issue. Many 
programs do lots of configure-time checks. Nobody that I know of has 
time to audit them all.


*Usually* rolling back the kernel will work, because *usually* it's a 
small rollback and programs built for a newer kernel won't exercise the 
small area where the kernels differ in a way that will cause 
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 
program and know that its configure-time tests are valid for the older 
kernel, you can skip the rebuild. Or if building speed is more important 
to you than reliable applications, you can also skip the rebuild.

bug#63850: cp fails for files > 2 GB if copy offload is unsupported

[Arsen Arsenović via GNU coreutils Bug Reports]

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 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
Description: PGP signature