https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
Mark Linimon changed:
What|Removed |Added
Status|Open|Closed
Keywords|needs-pat
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #15 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=6561a7141b5603235d18538f6c66322ed7fc67d3
commit 6561a7141b5603235d18538f6c66322ed7fc67d3
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #14 from commit-h...@freebsd.org ---
A commit in branch stable/14 references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=5c4da68ad785e955976e7b73c281213abb85c23a
commit 5c4da68ad785e955976e7b73c281213abb85c23a
Author
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #13 from commit-h...@freebsd.org ---
A commit in branch main references this bug:
URL:
https://cgit.FreeBSD.org/src/commit/?id=84b4342c0d7ac8a3187309a978d41e6765154cc1
commit 84b4342c0d7ac8a3187309a978d41e6765154cc1
Author:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #12 from Konstantin Belousov ---
(In reply to David Chisnall from comment #11)
It is not required, it is quality of implementation.
POSIX does not require that read(2) works on shmfd at all.
--
You are receiving this mail beca
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #11 from David Chisnall ---
(In reply to Konstantin Belousov from comment #10)
> when they operate on regular files or symbolic links
So not necessary for the fallback case for file descriptors that are not
regular files?
--
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #10 from Konstantin Belousov ---
(In reply to David Chisnall from comment #9)
>From IEEE Standard for Information Technology—
Portable Operating System Interface (POSIX®)
Base Specifications, Issue 7
2.9.7 Thread Interactions w
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #9 from David Chisnall ---
(In reply to Rick Macklem from comment #7)
What are the range locking guarantees? I don't see anything in the man page
(ours or Linux's) that mentions anything about locking ranges or any guarantees
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #8 from Rick Macklem ---
The most recent Linux man page for copy_file_range(2)
appears to be here:
https://man7.org/linux/man-pages/man2/copy_file_range.2.html
In it:
EINVAL The flags argument is not 0.
EINVAL fd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #7 from Rick Macklem ---
Now that I have taken a quick look, doing
the shared memory fallback will be quite a
bit of work, given the range locking stuff.
Something like:
- Define a new f_op (f_copy_file_range()).
- Factor most o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #6 from Rick Macklem ---
It looks like there would need to be a
layering violation, since the code that
goes in kern_copy_file_range() will need
to be specific to shm_ops, since the
range lock code needs to use shm_mtx.
(Or a ne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #5 from Rick Macklem ---
I looked and doing the fallback will
require some messing about.
shm_read() and shm_write() do
range locking however copy_file_ramge()
needs to do range locking on both
fds before copying.
I think varia
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #4 from Rick Macklem ---
Long ago when I first worked on 6th edition
(late 1970s) there was the "everything was
a file" philosophy. However, things like
shared emeory did not exist. The fact that
the code does not use vnodes su
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
Dmitry Chagin changed:
What|Removed |Added
CC||dcha...@freebsd.org
--- Comment #3
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
Graham Perrin changed:
What|Removed |Added
Status|New |Open
Component|kern
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #2 from David Chisnall ---
(In reply to Rick Macklem from comment #1)
> The title uses "file" which I think of as "regular file",
On *NIX, everything is a file. I found it very surprising that it didn't work
with shared memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
--- Comment #1 from Rick Macklem ---
Yes, I think the man page needs to be patched so
that it clearly states "file descriptors for
regular file" and add the case of no-regular files
to EINVAL.
The title uses "file" which I think of as "reg
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273962
Bug ID: 273962
Summary: copy_file_range does not work on shared memory objects
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
18 matches
Mail list logo
