[#98621] Re: Function getlogin_r()'s protoype] — Bertram Scharpf <lists@...>
FYI,
3 messages
2020/06/02
[#98947] [Ruby master Feature#16986] Anonymous Struct literal — ko1@...
Issue #16986 has been reported by ko1 (Koichi Sasada).
66 messages
2020/06/26
[#98962] [Ruby master Bug#16988] Kernel.load loads file from current directory without '.' in path — misharinn@...
Issue #16988 has been reported by TheSmartnik (Nikita Misharin).
5 messages
2020/06/26
[#98969] [Ruby master Feature#16994] Sets: shorthand for frozen sets of symbols / strings — marcandre-ruby-core@...
Issue #16994 has been reported by marcandre (Marc-Andre Lafortune).
7 messages
2020/06/26
[#100117] [Ruby master Feature#16994] Sets: shorthand for frozen sets of symbols / strings
— matz@...
2020/09/25
Issue #16994 has been updated by matz (Yukihiro Matsumoto).
[ruby-core:98857] [Ruby master Feature#16965] io.c: Unsupported copy_file_range() not detected properly on certain kernels
From:
v.ondruch@...
Date:
2020-06-18 06:54:14 UTC
List:
ruby-core #98857
Issue #16965 has been updated by vo.x (Vit Ondruch).
I don't think EOPNOTSUP is documented error state, therefore I am against this. Not mentioning that it would need backport to older Rubies and what not. In the time this is going to be implemented in Ruby, updated RHEL kernel will be long released.
----------------------------------------
Feature #16965: io.c: Unsupported copy_file_range() not detected properly on certain kernels
https://bugs.ruby-lang.org/issues/16965#change-86220
* Author: stanhu (Stan Hu)
* Status: Open
* Priority: Normal
* Assignee: Glass_saga (Masaki Matsushita)
----------------------------------------
In recent RedHat kernels (for example: RHEL 7.8 using kernel 3.10.0-1127.8.2.el7.x86_64), `copy_file_range()` may return `EOPNOTSUP` when Ruby attempts to call this in `IO.copy_stream` on an NFS mount. A simple `FileUtils.copy_file` will fail with `Operation not supported - copy_file_range` on these kernels.
This was possibly changed during a recent security release: https://access.redhat.com/errata/RHSA-2020:1465
Ruby's io.c detects whether `copy_file_range()` is defined, not whether it is actually supported. The following test program illustrates the hole in the detection mechanism:
```
#include <syscall.h>
#include <stdio.h>
#if defined __linux__ && defined __NR_copy_file_range
# define USE_COPY_FILE_RANGE 1
#else
# define USE_COPY_FILE_RANGE 0
#endif
int main()
{
printf("copy_file_range? %d\n", USE_COPY_FILE_RANGE);
}
```
`USE_COPY_FILE_RANGE` gets set to 1 even in when the system call doesn't succeed.
I suggest a few improvements:
1. Use a compile-time test to verify that `copy_file_range()` can actually be executed.
2. Make it possible to disable `USE_COPY_FILE_RANGE` via a build option. Since the test in 1 could still pass if it is run on a Docker host that supports `copy_file_range()`, it would be helpful for us to manually disable it.
Reported by GitLab customers: https://gitlab.com/gitlab-org/gitlab/-/issues/218999
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>