* [PATCH v2 1/6] Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
@ 2020-10-04 16:49 ` Ken Brown
2020-10-04 16:49 ` [PATCH v2 2/6] Cygwin: fix handling of known reparse points that are not symlinks Ken Brown
` (6 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Ken Brown @ 2020-10-04 16:49 UTC (permalink / raw)
To: cygwin-patches
The following Windows system calls currently fail with
STATUS_IO_REPARSE_TAG_NOT_HANDLED when called on an AF_UNIX socket:
- NtOpenFile in get_file_sd
- NtOpenFile in set_file_sd
- NtCreateFile in fhandler_base::open
Fix this by adding the FILE_OPEN_REPARSE_POINT flag to those calls
when the file is a known reparse point.
---
winsup/cygwin/fhandler.cc | 11 +++++++++--
winsup/cygwin/security.cc | 8 ++++++--
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index 82b21aff4..5dbbd4068 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -620,13 +620,20 @@ fhandler_base::open (int flags, mode_t mode)
else
create_disposition = (flags & O_CREAT) ? FILE_OPEN_IF : FILE_OPEN;
- if (get_device () == FH_FS)
+ if (get_device () == FH_FS
+#ifdef __WITH_AF_UNIX
+ || get_device () == FH_UNIX
+#endif
+ )
{
- /* Add the reparse point flag to known repares points, otherwise we
+ /* Add the reparse point flag to known reparse points, otherwise we
open the target, not the reparse point. This would break lstat. */
if (pc.is_known_reparse_point ())
options |= FILE_OPEN_REPARSE_POINT;
+ }
+ if (get_device () == FH_FS)
+ {
/* O_TMPFILE files are created with delete-on-close semantics, as well
as with FILE_ATTRIBUTE_TEMPORARY. The latter speeds up file access,
because the OS tries to keep the file in memory as much as possible.
diff --git a/winsup/cygwin/security.cc b/winsup/cygwin/security.cc
index 468b05164..d48526619 100644
--- a/winsup/cygwin/security.cc
+++ b/winsup/cygwin/security.cc
@@ -65,7 +65,9 @@ get_file_sd (HANDLE fh, path_conv &pc, security_descriptor &sd,
fh ? pc.init_reopen_attr (attr, fh)
: pc.get_object_attr (attr, sec_none_nih),
&io, FILE_SHARE_VALID_FLAGS,
- FILE_OPEN_FOR_BACKUP_INTENT);
+ FILE_OPEN_FOR_BACKUP_INTENT
+ | pc.is_known_reparse_point ()
+ ? FILE_OPEN_REPARSE_POINT : 0);
if (!NT_SUCCESS (status))
{
sd.free ();
@@ -232,7 +234,9 @@ set_file_sd (HANDLE fh, path_conv &pc, security_descriptor &sd, bool is_chown)
: pc.get_object_attr (attr, sec_none_nih),
&io,
FILE_SHARE_VALID_FLAGS,
- FILE_OPEN_FOR_BACKUP_INTENT);
+ FILE_OPEN_FOR_BACKUP_INTENT
+ | pc.is_known_reparse_point ()
+ ? FILE_OPEN_REPARSE_POINT : 0);
if (!NT_SUCCESS (status))
{
fh = NULL;
--
2.28.0
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v2 2/6] Cygwin: fix handling of known reparse points that are not symlinks
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
2020-10-04 16:49 ` [PATCH v2 1/6] Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed Ken Brown
@ 2020-10-04 16:49 ` Ken Brown
2020-10-04 16:49 ` [PATCH v2 3/6] Cygwin: always recognize AF_UNIX sockets as reparse points Ken Brown
` (5 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Ken Brown @ 2020-10-04 16:49 UTC (permalink / raw)
To: cygwin-patches
Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path
handling", changed check_reparse_point_target so that it could return
a positive value on a known reparse point that is not a symlink. But
some of the code in check_reparse_point that handles this positive
return value was executed unconditionally, when it should have been
executed only for symlinks.
As a result, posixify could be called on a buffer containing garbage,
and check_reparse_point could erroneously return a positive value on a
non-symlink. This is now fixed so that posixify is only called if the
reparse point is a symlink, and check_reparse_point returns 0 if the
reparse point is not a symlink.
Also fix symlink_info::check to handle this last case, in which
check_reparse_point returns 0 on a known reparse point.
---
winsup/cygwin/path.cc | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 638f1adce..2e3208d2d 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2655,11 +2655,15 @@ symlink_info::check_reparse_point (HANDLE h, bool remote)
/* ret is > 0, so it's a known reparse point, path in symbuf. */
path_flags |= ret;
if (ret & PATH_SYMLINK)
- sys_wcstombs (srcbuf, SYMLINK_MAX + 7, symbuf.Buffer,
- symbuf.Length / sizeof (WCHAR));
- /* A symlink is never a directory. */
- fileattr &= ~FILE_ATTRIBUTE_DIRECTORY;
- return posixify (srcbuf);
+ {
+ sys_wcstombs (srcbuf, SYMLINK_MAX + 7, symbuf.Buffer,
+ symbuf.Length / sizeof (WCHAR));
+ /* A symlink is never a directory. */
+ fileattr &= ~FILE_ATTRIBUTE_DIRECTORY;
+ return posixify (srcbuf);
+ }
+ else
+ return 0;
}
int
@@ -3274,6 +3278,9 @@ restart:
&= ~FILE_ATTRIBUTE_DIRECTORY;
break;
}
+ else if (res == 0 && (path_flags & PATH_REP))
+ /* Known reparse point but not a symlink. */
+ goto file_not_symlink;
else
{
/* Volume moint point or unrecognized reparse point type.
--
2.28.0
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v2 3/6] Cygwin: always recognize AF_UNIX sockets as reparse points
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
2020-10-04 16:49 ` [PATCH v2 1/6] Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed Ken Brown
2020-10-04 16:49 ` [PATCH v2 2/6] Cygwin: fix handling of known reparse points that are not symlinks Ken Brown
@ 2020-10-04 16:49 ` Ken Brown
2020-10-04 16:49 ` [PATCH v2 4/6] Cygwin: AF_UNIX: socket: set the O_RDWR flag Ken Brown
` (4 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Ken Brown @ 2020-10-04 16:49 UTC (permalink / raw)
To: cygwin-patches
If __WITH_AF_UNIX is defined when Cygwin is built, then a named
AF_UNIX socket is represented by a reparse point with a
Cygwin-specific tag and GUID. Make such files recognizable as reparse
points (but not as sockets) even if __WITH_AF_UNIX is not defined.
That way utilities such as 'ls' and 'rm' still behave reasonably.
This requires two changes:
- Define the GUID __cygwin_socket_guid unconditionally.
- Make check_reparse_point_target return PATH_REP on a reparse point
of this type if __WITH_AF_UNIX is not defined.
---
winsup/cygwin/fhandler_socket_unix.cc | 17 +++++++++--------
winsup/cygwin/path.cc | 10 ++++++----
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index d7bb1090e..429aa8a90 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -8,9 +8,17 @@
Cygwin license. Please consult the file "CYGWIN_LICENSE" for
details. */
+#include "winsup.h"
+
+GUID __cygwin_socket_guid = {
+ .Data1 = 0xefc1714d,
+ .Data2 = 0x7b19,
+ .Data3 = 0x4407,
+ .Data4 = { 0xba, 0xb3, 0xc5, 0xb1, 0xf9, 0x2c, 0xb8, 0x8c }
+};
+
#ifdef __WITH_AF_UNIX
-#include "winsup.h"
#include <w32api/winioctl.h>
#include <asm/byteorder.h>
#include <unistd.h>
@@ -124,13 +132,6 @@ class af_unix_pkt_hdr_t
(void *)(((PBYTE)(_p)) + AF_UNIX_PKT_OFFSETOF_DATA (_p)); \
})
-GUID __cygwin_socket_guid = {
- .Data1 = 0xefc1714d,
- .Data2 = 0x7b19,
- .Data3 = 0x4407,
- .Data4 = { 0xba, 0xb3, 0xc5, 0xb1, 0xf9, 0x2c, 0xb8, 0x8c }
-};
-
/* Some error conditions on pipes have multiple status codes, unfortunately. */
#define STATUS_PIPE_NO_INSTANCE_AVAILABLE(status) \
({ NTSTATUS _s = (status); \
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 2e3208d2d..4f5f03a76 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2476,8 +2476,7 @@ check_reparse_point_string (PUNICODE_STRING subst)
/* Return values:
<0: Negative errno.
0: Not a reparse point recognized by us.
- >0: PATH_SYMLINK | PATH_REP for symlink or directory mount point,
- PATH_SOCKET | PATH_REP for AF_UNIX socket.
+ >0: Path flags for a recognized reparse point, always including PATH_REP.
*/
int
check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
@@ -2618,15 +2617,18 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
}
return -EIO;
}
-#ifdef __WITH_AF_UNIX
else if (rp->ReparseTag == IO_REPARSE_TAG_CYGUNIX)
{
PREPARSE_GUID_DATA_BUFFER rgp = (PREPARSE_GUID_DATA_BUFFER) rp;
if (memcmp (CYGWIN_SOCKET_GUID, &rgp->ReparseGuid, sizeof (GUID)) == 0)
+#ifdef __WITH_AF_UNIX
return PATH_SOCKET | PATH_REP;
+#else
+ /* Recognize this as a reparse point but not as a socket. */
+ return PATH_REP;
+#endif
}
-#endif /* __WITH_AF_UNIX */
return 0;
}
--
2.28.0
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v2 4/6] Cygwin: AF_UNIX: socket: set the O_RDWR flag
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
` (2 preceding siblings ...)
2020-10-04 16:49 ` [PATCH v2 3/6] Cygwin: always recognize AF_UNIX sockets as reparse points Ken Brown
@ 2020-10-04 16:49 ` Ken Brown
2020-10-04 16:49 ` [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS Ken Brown
` (3 subsequent siblings)
7 siblings, 0 replies; 17+ messages in thread
From: Ken Brown @ 2020-10-04 16:49 UTC (permalink / raw)
To: cygwin-patches
---
winsup/cygwin/fhandler_socket_unix.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index 429aa8a90..0ae7fe125 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -1366,6 +1366,7 @@ fhandler_socket_unix::socket (int af, int type, int protocol, int flags)
wmem (262144);
set_addr_family (AF_UNIX);
set_socket_type (type);
+ set_flags (O_RDWR | O_BINARY);
if (flags & SOCK_NONBLOCK)
set_nonblocking (true);
if (flags & SOCK_CLOEXEC)
--
2.28.0
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
` (3 preceding siblings ...)
2020-10-04 16:49 ` [PATCH v2 4/6] Cygwin: AF_UNIX: socket: set the O_RDWR flag Ken Brown
@ 2020-10-04 16:49 ` Ken Brown
2020-10-13 11:28 ` Corinna Vinschen
2020-10-04 16:49 ` [PATCH v2 6/6] Cygwin: AF_UNIX: open_pipe: call recv_peer_info Ken Brown
` (2 subsequent siblings)
7 siblings, 1 reply; 17+ messages in thread
From: Ken Brown @ 2020-10-04 16:49 UTC (permalink / raw)
To: cygwin-patches
A successful connection can be indicated by STATUS_SUCCESS or
STATUS_PIPE_CONNECTED. Previously we were checking only for the
latter.
---
winsup/cygwin/fhandler_socket_unix.cc | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index 0ae7fe125..1a9532fe5 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -1064,6 +1064,7 @@ fhandler_socket_unix::listen_pipe ()
IO_STATUS_BLOCK io;
HANDLE evt = NULL;
DWORD waitret = WAIT_OBJECT_0;
+ int ret = -1;
io.Status = STATUS_PENDING;
if (!is_nonblocking () && !(evt = create_event ()))
@@ -1085,9 +1086,11 @@ fhandler_socket_unix::listen_pipe ()
set_errno (EINTR);
else if (status == STATUS_PIPE_LISTENING)
set_errno (EAGAIN);
- else if (status != STATUS_PIPE_CONNECTED)
+ else if (status == STATUS_SUCCESS || status == STATUS_PIPE_CONNECTED)
+ ret = 0;
+ else
__seterrno_from_nt_status (status);
- return (status == STATUS_PIPE_CONNECTED) ? 0 : -1;
+ return ret;
}
ULONG
--
2.28.0
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
2020-10-04 16:49 ` [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS Ken Brown
@ 2020-10-13 11:28 ` Corinna Vinschen
2020-10-13 13:18 ` Ken Brown
0 siblings, 1 reply; 17+ messages in thread
From: Corinna Vinschen @ 2020-10-13 11:28 UTC (permalink / raw)
To: cygwin-patches
On Oct 4 12:49, Ken Brown via Cygwin-patches wrote:
> A successful connection can be indicated by STATUS_SUCCESS or
> STATUS_PIPE_CONNECTED.
THanks for catching but... huh? How does Windows generate two different
status codes for the same result from the same function?
Corinna
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
2020-10-13 11:28 ` Corinna Vinschen
@ 2020-10-13 13:18 ` Ken Brown
2020-10-13 15:31 ` Corinna Vinschen
0 siblings, 1 reply; 17+ messages in thread
From: Ken Brown @ 2020-10-13 13:18 UTC (permalink / raw)
To: cygwin-patches
On 10/13/2020 7:28 AM, Corinna Vinschen wrote:
> On Oct 4 12:49, Ken Brown via Cygwin-patches wrote:
>> A successful connection can be indicated by STATUS_SUCCESS or
>> STATUS_PIPE_CONNECTED.
>
> THanks for catching but... huh? How does Windows generate two different
> status codes for the same result from the same function?
I think (but I'd have to recheck) that if the pipe is already connected when
NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED. But
if you first get STATUS_PENDING and then set status = io.Status after
completion, then the result is STATUS_SUCCESS.
I might not have that exactly right. All I remember for sure is that I was
debugging a listen_pipe failure, and it turned out to be due to STATUS_SUCCESS
being treated as an error condition.
Ken
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
2020-10-13 13:18 ` Ken Brown
@ 2020-10-13 15:31 ` Corinna Vinschen
0 siblings, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2020-10-13 15:31 UTC (permalink / raw)
To: cygwin-patches
On Oct 13 13:18, Ken Brown via Cygwin-patches wrote:
> On 10/13/2020 7:28 AM, Corinna Vinschen wrote:
> > On Oct 4 12:49, Ken Brown via Cygwin-patches wrote:
> >> A successful connection can be indicated by STATUS_SUCCESS or
> >> STATUS_PIPE_CONNECTED.
> >
> > THanks for catching but... huh? How does Windows generate two different
> > status codes for the same result from the same function?
>
> I think (but I'd have to recheck) that if the pipe is already connected when
> NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED. But
> if you first get STATUS_PENDING and then set status = io.Status after
> completion, then the result is STATUS_SUCCESS.
Ah, ok. I guess I just missed this scenario for some reason.
Thanks,
Corinna
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH v2 6/6] Cygwin: AF_UNIX: open_pipe: call recv_peer_info
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
` (4 preceding siblings ...)
2020-10-04 16:49 ` [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS Ken Brown
@ 2020-10-04 16:49 ` Ken Brown
2020-10-08 21:36 ` [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
2020-10-13 11:02 ` Corinna Vinschen
7 siblings, 0 replies; 17+ messages in thread
From: Ken Brown @ 2020-10-04 16:49 UTC (permalink / raw)
To: cygwin-patches
If open_pipe is called with xchg_sock_info true, call recv_peer_info
in addition to send_sock_info.
---
winsup/cygwin/fhandler_socket_unix.cc | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index 1a9532fe5..9f7f86c47 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -941,7 +941,11 @@ fhandler_socket_unix::open_pipe (PUNICODE_STRING pipe_name, bool xchg_sock_info)
{
set_handle (ph);
if (xchg_sock_info)
- send_sock_info (false);
+ {
+ /* FIXME: Should we check for errors? */
+ send_sock_info (false);
+ recv_peer_info ();
+ }
}
return status;
}
--
2.28.0
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
` (5 preceding siblings ...)
2020-10-04 16:49 ` [PATCH v2 6/6] Cygwin: AF_UNIX: open_pipe: call recv_peer_info Ken Brown
@ 2020-10-08 21:36 ` Ken Brown
2020-10-13 11:49 ` Corinna Vinschen
2020-10-13 11:02 ` Corinna Vinschen
7 siblings, 1 reply; 17+ messages in thread
From: Ken Brown @ 2020-10-08 21:36 UTC (permalink / raw)
To: cygwin-patches
On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
> I'm about to push these. Corinna, please check them when you return.
> The only difference between v2 and v1 is that there are a few more
> fixes.
>
> I'm trying to help get the AF_UNIX development going again. I'm
> mostly working on the topic/af_unix branch. But when I find bugs that
> exist on master, I'll push those to master and then merge master to
> topic/af_unix.
FYI to Corinna and anyone else interested in AF_UNIX development. After pushing
a few patches to the topic/af_unix branch I did some cleanup (locally) and
merged master into the topic branch. I don't want to do a forced push and risk
messing up the branch, so I've created a new branch, topic/af_unix_new, and will
do all further work there until Corinna returns and decides how we should proceed.
Ken
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-08 21:36 ` [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
@ 2020-10-13 11:49 ` Corinna Vinschen
2020-10-14 16:39 ` Ken Brown
0 siblings, 1 reply; 17+ messages in thread
From: Corinna Vinschen @ 2020-10-13 11:49 UTC (permalink / raw)
To: cygwin-patches
On Oct 8 17:36, Ken Brown via Cygwin-patches wrote:
> On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
> > I'm about to push these. Corinna, please check them when you return.
> > The only difference between v2 and v1 is that there are a few more
> > fixes.
> >
> > I'm trying to help get the AF_UNIX development going again. I'm
> > mostly working on the topic/af_unix branch. But when I find bugs that
> > exist on master, I'll push those to master and then merge master to
> > topic/af_unix.
>
> FYI to Corinna and anyone else interested in AF_UNIX development. After
> pushing a few patches to the topic/af_unix branch I did some cleanup
> (locally) and merged master into the topic branch. I don't want to do a
> forced push and risk messing up the branch, so I've created a new branch,
> topic/af_unix_new, and will do all further work there until Corinna returns
> and decides how we should proceed.
No, that's ok, just force push.
Thanks,
Corinna
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-13 11:49 ` Corinna Vinschen
@ 2020-10-14 16:39 ` Ken Brown
2020-10-15 4:19 ` Mark Geisert
2020-10-15 8:16 ` Corinna Vinschen
0 siblings, 2 replies; 17+ messages in thread
From: Ken Brown @ 2020-10-14 16:39 UTC (permalink / raw)
To: cygwin-patches
On 10/13/2020 7:49 AM, Corinna Vinschen wrote:
> On Oct 8 17:36, Ken Brown via Cygwin-patches wrote:
>> On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
>>> I'm about to push these. Corinna, please check them when you return.
>>> The only difference between v2 and v1 is that there are a few more
>>> fixes.
>>>
>>> I'm trying to help get the AF_UNIX development going again. I'm
>>> mostly working on the topic/af_unix branch. But when I find bugs that
>>> exist on master, I'll push those to master and then merge master to
>>> topic/af_unix.
>>
>> FYI to Corinna and anyone else interested in AF_UNIX development. After
>> pushing a few patches to the topic/af_unix branch I did some cleanup
>> (locally) and merged master into the topic branch. I don't want to do a
>> forced push and risk messing up the branch, so I've created a new branch,
>> topic/af_unix_new, and will do all further work there until Corinna returns
>> and decides how we should proceed.
>
> No, that's ok, just force push.
OK, I've done that now. The branch contains a few sendmsg fixes, a first cut of
a recvmsg implementation, and a merge from master. I've done some testing of
recvmsg, but many things are not yet tested. I'll work on continued testing next.
Are you aware of any test suite that I could run? I've been using examples from
Kerrisk's book, because that's what I read to learn the basics of sockets. But
those are just examples and are not meant to be comprehensive.
Ken
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-14 16:39 ` Ken Brown
@ 2020-10-15 4:19 ` Mark Geisert
2020-10-15 5:48 ` Brian Inglis
2020-10-15 8:16 ` Corinna Vinschen
1 sibling, 1 reply; 17+ messages in thread
From: Mark Geisert @ 2020-10-15 4:19 UTC (permalink / raw)
To: cygwin-patches
Ken Brown via Cygwin-patches wrote:
> Are you aware of any test suite that I could run? I've been using examples from
> Kerrisk's book, because that's what I read to learn the basics of sockets. But
> those are just examples and are not meant to be comprehensive.
In ye olden days I used to use Stevens+Rago "Advanced Programming In The Unix
Environment, 2nd ed.". Chapter 17 covers UNIX domain sockets as advanced IPC.
It's more examples but maybe they hit different corners of the playing field. I
don't know of a test suite or even a standalone program that exercises AF_UNIX.
..mark
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-15 4:19 ` Mark Geisert
@ 2020-10-15 5:48 ` Brian Inglis
0 siblings, 0 replies; 17+ messages in thread
From: Brian Inglis @ 2020-10-15 5:48 UTC (permalink / raw)
To: cygwin-patches
On 2020-10-14 22:19, Mark Geisert wrote:
> Ken Brown via Cygwin-patches wrote:
>> Are you aware of any test suite that I could run? I've been using examples
>> from Kerrisk's book, because that's what I read to learn the basics of
>> sockets. But those are just examples and are not meant to be comprehensive.
>
> In ye olden days I used to use Stevens+Rago "Advanced Programming In The Unix
> Environment, 2nd ed.". Chapter 17 covers UNIX domain sockets as advanced IPC.
> It's more examples but maybe they hit different corners of the playing field. I
> don't know of a test suite or even a standalone program that exercises AF_UNIX.
The late author's Unix Network Programming has been updated by his co-authors to
Vol 1 3rd ed. and has some Unix domain AF_UNIX/AF_LOCAL content:
https://github.com/unpbook/unpv13e.git
Cygwin utilities nc, nttcp, socat, ttcp are available, some with Unix domain
AF_UNIX/AF_LOCAL support and tests;
replaces netperf.org web site, HP copyright somewhat non-free, includes Unix
domain AF_UNIX//AF_LOCAL tests, but I never tried it under Cygwin:
https://hewlettpackard.github.io/netperf/
https://github.com/HewlettPackard/netperf.git
also came across a mention of:
https://github.com/rigtorp/ipc-bench.git
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-14 16:39 ` Ken Brown
2020-10-15 4:19 ` Mark Geisert
@ 2020-10-15 8:16 ` Corinna Vinschen
1 sibling, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2020-10-15 8:16 UTC (permalink / raw)
To: cygwin-patches
On Oct 14 12:39, Ken Brown via Cygwin-patches wrote:
> On 10/13/2020 7:49 AM, Corinna Vinschen wrote:
> > On Oct 8 17:36, Ken Brown via Cygwin-patches wrote:
> > > On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
> > > > I'm about to push these. Corinna, please check them when you return.
> > > > The only difference between v2 and v1 is that there are a few more
> > > > fixes.
> > > >
> > > > I'm trying to help get the AF_UNIX development going again. I'm
> > > > mostly working on the topic/af_unix branch. But when I find bugs that
> > > > exist on master, I'll push those to master and then merge master to
> > > > topic/af_unix.
> > >
> > > FYI to Corinna and anyone else interested in AF_UNIX development. After
> > > pushing a few patches to the topic/af_unix branch I did some cleanup
> > > (locally) and merged master into the topic branch. I don't want to do a
> > > forced push and risk messing up the branch, so I've created a new branch,
> > > topic/af_unix_new, and will do all further work there until Corinna returns
> > > and decides how we should proceed.
> >
> > No, that's ok, just force push.
>
> OK, I've done that now. The branch contains a few sendmsg fixes, a first
> cut of a recvmsg implementation, and a merge from master. I've done some
> testing of recvmsg, but many things are not yet tested. I'll work on
> continued testing next.
This is sooo great!
> from Kerrisk's book, because that's what I read to learn the basics of
> sockets. But those are just examples and are not meant to be comprehensive.
What Mark and Brian said, Stevens' book is quite nice, and there's
code available. I downloaded the tar file with all code examples
way back when, but apparently the code is on github now, as Brian
pointed out.
Thanks,
Corinna
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH v2 0/6] Some AF_UNIX fixes
2020-10-04 16:49 [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
` (6 preceding siblings ...)
2020-10-08 21:36 ` [PATCH v2 0/6] Some AF_UNIX fixes Ken Brown
@ 2020-10-13 11:02 ` Corinna Vinschen
7 siblings, 0 replies; 17+ messages in thread
From: Corinna Vinschen @ 2020-10-13 11:02 UTC (permalink / raw)
To: cygwin-patches
On Oct 4 12:49, Ken Brown via Cygwin-patches wrote:
> I'm about to push these. Corinna, please check them when you return.
> The only difference between v2 and v1 is that there are a few more
> fixes.
>
> I'm trying to help get the AF_UNIX development going again. I'm
> mostly working on the topic/af_unix branch. But when I find bugs that
> exist on master, I'll push those to master and then merge master to
> topic/af_unix.
>
> So far what I have on that branch locally (to be pushed shortly) is an
> implementation of fhandler_socket_unix::read, which I've tested by
> running the srver/client programs from Section 57.2 of Kerrisk's book,
> "The Linux Programming Interface".
Oh boy, this is SOOOO great! Thanks for working on that!
Corinna
^ permalink raw reply [flat|nested] 17+ messages in thread