[PATCH] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; see AMD64 Architecture Programmerâs Manual Volume 3: General-Purpose and System Instructions https://www.amd.com/system/files/TechDocs/24594.pdf#page=329 and elsewhere in that document --- winsup/cygwin/fhandler_proc.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 8c331f5f4..78a69703d 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1255,6 +1255,7 @@ format_proc_cpuinfo (void *, char *&destbuf) ftcprint (features1, 0, "clzero"); /* clzero instruction */ ftcprint (features1, 1, "irperf"); /* instr retired count */ ftcprint (features1, 2, "xsaveerptr"); /* save/rest FP err ptrs */ + ftcprint (features1, 4, "rdpru");/* user level rd proc reg */ /* ftcprint (features1, 6, "mba"); */ /* memory BW alloc */ ftcprint (features1, 9, "wbnoinvd"); /* wbnoinvd instruction */ /* ftcprint (features1, 12, "ibpb" ); */ /* ind br pred barrier */ -- 2.21.0
[PATCH] Cygwin: pty: Remove close() call just before reopening slave.
- After commit da4ee7d60b9ff0bcdc081609a4467adb428d58e6, the issue
reported in https://www.cygwin.com/ml/cygwin/2020-01/msg00209.html
occurs. This patch fixes the issue.
---
winsup/cygwin/fhandler_tty.cc | 1 -
1 file changed, 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 73aeff37f..35a48338f 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -1326,7 +1326,6 @@ fhandler_pty_slave::push_to_pcon_screenbuffer (const char
*ptr, size_t len)
{
termios_printf ("GetConsoleMode failed, %E");
/* Re-open handles */
- this->close ();
this->open (0, 0);
/* Fix pseudo console window size */
this->ioctl (TIOCSWINSZ, &get_ttyp ()->winsize);
--
2.21.0
Re: [PATCH] Cygwin: pty: Remove close() call just before reopening slave.
On Jan 23 20:34, Takashi Yano wrote:
> - After commit da4ee7d60b9ff0bcdc081609a4467adb428d58e6, the issue
> reported in https://www.cygwin.com/ml/cygwin/2020-01/msg00209.html
> occurs. This patch fixes the issue.
> ---
> winsup/cygwin/fhandler_tty.cc | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index 73aeff37f..35a48338f 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -1326,7 +1326,6 @@ fhandler_pty_slave::push_to_pcon_screenbuffer (const
> char *ptr, size_t len)
> {
>termios_printf ("GetConsoleMode failed, %E");
>/* Re-open handles */
> - this->close ();
>this->open (0, 0);
>/* Fix pseudo console window size */
>this->ioctl (TIOCSWINSZ, &get_ttyp ()->winsize);
> --
> 2.21.0
Pushed.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
signature.asc
Description: PGP signature
Re: [PATCH] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
On Jan 23 02:06, Brian Inglis wrote: > rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; > see AMD64 Architecture Programmerâs Manual Volume 3: ^ This came over already broken. No idea if that's a problem of your MUA or of the mailing list software. I fixed it to an ordinary quote char locally. > General-Purpose and System Instructions > https://www.amd.com/system/files/TechDocs/24594.pdf#page=329 > and elsewhere in that document > > --- > winsup/cygwin/fhandler_proc.cc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc > index 8c331f5f4..78a69703d 100644 > --- a/winsup/cygwin/fhandler_proc.cc > +++ b/winsup/cygwin/fhandler_proc.cc > @@ -1255,6 +1255,7 @@ format_proc_cpuinfo (void *, char *&destbuf) > ftcprint (features1, 0, "clzero"); /* clzero instruction */ > ftcprint (features1, 1, "irperf"); /* instr retired count */ > ftcprint (features1, 2, "xsaveerptr"); /* save/rest FP err ptrs */ > + ftcprint (features1, 4, "rdpru");/* user level rd proc reg */ > /* ftcprint (features1, 6, "mba"); */ /* memory BW alloc */ > ftcprint (features1, 9, "wbnoinvd"); /* wbnoinvd instruction */ > /* ftcprint (features1, 12, "ibpb" ); */ /* ind br pred barrier */ > -- > 2.21.0 Pushed. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: pty: Add missing console API hooks.
On Jan 23 13:33, Takashi Yano wrote: > - Following console APIs are additionally hooked for cygwin programs > which directly call them. > * FillConsoleOutputAttribute() > * FillConsoleOutputCharacterA() > * FillConsoleOutputCharacterW() > * ScrollConsoleScreenBufferA() > * ScrollConsoleScreenBufferW() Which Cygwin programs are doing that? They wouldn't work correctly in ptys anyway, isn't it? Does it really make sense to make them happy rather than requesting to change them? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Jan 23 13:30, Takashi Yano wrote: > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > cygwin programs which call both printf() and WriteConsole() are > frequently distorted. This patch reverts waiting function to dumb > Sleep(). I understand the need for this change, but isn't there any other way to detect if the pseudo console being ready? E. g., something in the HPCON_INTERNAL struct or so? Corinna -- Corinna Vinschen Cygwin Maintainer signature.asc Description: PGP signature
Re: [PATCH] Cygwin: pty: Add missing console API hooks.
On Thu, 23 Jan 2020 13:48:13 +0100
Corinna Vinschen wrote:
> On Jan 23 13:33, Takashi Yano wrote:
> > - Following console APIs are additionally hooked for cygwin programs
> > which directly call them.
> > * FillConsoleOutputAttribute()
> > * FillConsoleOutputCharacterA()
> > * FillConsoleOutputCharacterW()
> > * ScrollConsoleScreenBufferA()
> > * ScrollConsoleScreenBufferW()
>
> Which Cygwin programs are doing that? They wouldn't work correctly in
> ptys anyway, isn't it? Does it really make sense to make them happy
> rather than requesting to change them?
Just a possibility. There is no specific example.
With this patch, the code below can work even if it is compiled as
cygwin binary.
#include
#include
int main() {
COORD dest = {0, 0};
printf("\033[H\033[J\n");
DWORD n;
FillConsoleOutputCharacter (GetStdHandle(STD_OUTPUT_HANDLE),
'A', 80, dest, &n);
FillConsoleOutputAttribute (GetStdHandle(STD_OUTPUT_HANDLE),
FOREGROUND_RED, 80, dest, &n);
return 0;
}
--
Takashi Yano
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
> On Jan 23 13:30, Takashi Yano wrote: > > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > > cygwin programs which call both printf() and WriteConsole() are > > frequently distorted. This patch reverts waiting function to dumb > > Sleep(). Hi, I have a question related to this patch. (When I have a question on a specific patch like this, which mailing list should I come? If I should not make a reply to the original cygwin-patch mailing list, let me apologize in advance. If so, I'll move to cygwin mailing list.) When I try to use the recent commit 6d79e0a58 (tag: newlib-3.3.0), any Cygwin program fails to start leaving the following message: 0 [main] () shared_info::initialize: size of shared memory region changed from 50104 to 49080 where and are the program name and PID. I also tried with the current master branch 8f502bd33, and the result was the same. I tested each commit one by one, and found that this problem is caused after this patch: 6cc299f0e - (2 days ago) Cygwin: pty: Revise code waiting for forwarding by master_fwd_thread. - Takashi Yano In fact, if I drop this commit from the master branch, the problem disappears. But, as there are no related reports here, I suspect this is the problem specific to my environment. In particular, I suspect that this is caused by the compatibility of different versions of `cygwin1.dll'. Currently, when I try to use the new `cygwin1.dll', I just replace `C:\cygwin64\bin\cygwin1.dll' with the version I built from recent a commit (`new-cygwin1.dll') following the instruction for snapshots which is found at https://cygwin.com/faq.html#faq.setup.snapshots Here my question is, if this is caused by the way I try the new version, what is the correct way to try the latest version built from a commit in the git repository (do I need to rebuild all the toolchain)? Or, is this problem caused by other conditions? I would appreciate it if you could provide me some hints. Here is some trials in command prompt: C:\cygwin64\bin>bash 0 [main] bash (18936) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>dash 0 [main] dash (7900) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>stty 0 [main] stty (2920) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>cat 0 [main] cat (21340) shared_info::initialize: size of shared memory region changed from 50104 to 49080 C:\cygwin64\bin>mintty mintty fails without any messages. Thank you, Koichi
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
2020年1月23日(木) 21:39 Koichi Murase : > > On Jan 23 13:30, Takashi Yano wrote: > > > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > > > cygwin programs which call both printf() and WriteConsole() are > > > frequently distorted. This patch reverts waiting function to dumb > > > Sleep(). I'm sorry, I made a reply to a wrong mail (with a similar subject). I should have made this reply to the original version of the patch. Sorry for the confusion. Koichi
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Thu, 23 Jan 2020 21:39:50 +0800 Koichi Murase wrote: > 0 [main] () shared_info::initialize: size of shared > memory region changed from 50104 to 49080 Is there any process alived using diffrent version of cygwin1.dll? -- Takashi Yano
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Thu, 23 Jan 2020 13:51:54 +0100
Corinna Vinschen wrote:
> On Jan 23 13:30, Takashi Yano wrote:
> > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of
> > cygwin programs which call both printf() and WriteConsole() are
> > frequently distorted. This patch reverts waiting function to dumb
> > Sleep().
>
> I understand the need for this change, but isn't there any other
> way to detect if the pseudo console being ready? E. g., something
> in the HPCON_INTERNAL struct or so?
As for HPCON_INTERNAL,
typedef struct _HPCON_INTERNAL
{
HANDLE hWritePipe;
HANDLE hConDrvReference;
HANDLE hConHostProcess;
} HPCON_INTERNAL;
hWritePipe:
This is for sending window size change message to pseudo console
(conhost.exe process).
hConDrvRererence:
I am not sure what this is for.
hConHostProcess:
Process handle of conhost.exe process.
None of them seems able to be used for that purpose.
I do not come up with other implementation so far.
Let me consider a while.
--
Takashi Yano
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
2020年1月23日(木) 22:00 Takashi Yano : > Is there any process alived using diffrent version of cygwin1.dll? Ah, you were right! Actually there were no *real* processes remained (Otherwise I could not have overwritten cygwin1.dll, I think), but I remembered that there is a remaining *fake entry* in the result of `ps' as follows (for which `kill' produces error `No such process' and also I cannot find any corresponding process in Windows Task Manager). $ ps uaxf PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1416 11416 11160 ? 197610 Jan 20 /home/murase/opt/screen/4.7.0m/bin/screen-4.7.0 After a reboot of Windows, the problem has resolved! Thank you! Koichi
Re: [PATCH v2] Cygwin: pty: Revise code waiting for forwarding again.
On Thu, 23 Jan 2020 13:51:54 +0100 Corinna Vinschen wrote: > On Jan 23 13:30, Takashi Yano wrote: > > - After commit 6cc299f0e20e4b76f7dbab5ea8c296ffa4859b62, outputs of > > cygwin programs which call both printf() and WriteConsole() are > > frequently distorted. This patch reverts waiting function to dumb > > Sleep(). > I understand the need for this change, but isn't there any other > way to detect if the pseudo console being ready? E. g., something > in the HPCON_INTERNAL struct or so? In any case, this patch has a problem that windows native program takes a very long time to start/stop after the window size is changed. Please do not apply this patch. If you want to try this patch, please use following patch along with v2 patch. diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc index 2b7c667a6..06ac0c5e0 100644 --- a/winsup/cygwin/fhandler_tty.cc +++ b/winsup/cygwin/fhandler_tty.cc @@ -2413,6 +2413,7 @@ fhandler_pty_master::ioctl (unsigned int cmd, void *arg) COORD size; size.X = ((struct winsize *) arg)->ws_col; size.Y = ((struct winsize *) arg)->ws_row; + get_ttyp ()->last_push_time = GetTickCount (); ResizePseudoConsole (get_pseudo_console (), size); } if (get_ttyp ()->winsize.ws_row != ((struct winsize *) arg)->ws_row -- Takashi Yano
[PATCH 3/3] Cygwin: FIFO: tweak fcntl and dup when O_PATH is set
fhandler_fifo::fcntl and fhandler_fifo::dup now call the corresponding
fhandler_base methods if the FIFO was opened with the O_PATH flag.
---
winsup/cygwin/fhandler_fifo.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 8cbab353c..a338f12cc 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -997,7 +997,7 @@ fhandler_fifo::close ()
int
fhandler_fifo::fcntl (int cmd, intptr_t arg)
{
- if (cmd != F_SETFL || nohandle ())
+ if (cmd != F_SETFL || nohandle () || (get_flags () & O_PATH))
return fhandler_base::fcntl (cmd, arg);
const bool was_nonblocking = is_nonblocking ();
@@ -1014,6 +1014,9 @@ fhandler_fifo::dup (fhandler_base *child, int flags)
int ret = -1;
fhandler_fifo *fhf = NULL;
+ if (get_flags () & O_PATH)
+return fhandler_base::dup (child, flags);
+
if (fhandler_base::dup (child, flags))
goto out;
--
2.21.0
[PATCH 1/3] Cygwin: device_access_denied: return false if O_PATH is set
If O_PATH is set in the flags argument of
fhandler_base::device_access_denied, return false. No
read/write/execute access should be required in this case.
Previously, the call to device_access_denied in open(2) would lead to
an attempt to open the file with read access even if the O_PATH flag
was set.
---
winsup/cygwin/fhandler.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index b0c9c50c3..aeee8fe4d 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -335,6 +335,9 @@ fhandler_base::device_access_denied (int flags)
{
int mode = 0;
+ if (flags & O_PATH)
+return false;
+
if (flags & O_RDWR)
mode |= R_OK | W_OK;
if (flags & (O_WRONLY | O_APPEND))
--
2.21.0
[PATCH 2/3] Cygwin: re-implement fhandler_fifo::open with O_PATH
If the O_PATH flag is set, fhandler_fifo::open now simply calls
fhandler_base::open_fs.
The previous attempt to handle O_PATH in commit aa55d22c, "Cygwin:
honor the O_PATH flag when opening a FIFO", fixed a hang but otherwise
didn't do anything useful.
---
winsup/cygwin/fhandler_fifo.cc | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index fd8223000..8cbab353c 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -453,17 +453,13 @@ fhandler_fifo::open (int flags, mode_t)
} res;
if (flags & O_PATH)
-{
- query_open (query_read_attributes);
- nohandle (true);
-}
+return open_fs (flags);
/* Determine what we're doing with this fhandler: reading, writing, both */
switch (flags & O_ACCMODE)
{
case O_RDONLY:
- if (!query_open ())
- reader = true;
+ reader = true;
break;
case O_WRONLY:
writer = true;
@@ -585,8 +581,6 @@ fhandler_fifo::open (int flags, mode_t)
}
}
}
- if (query_open ())
-res = success;
out:
if (res == error_set_errno)
__seterrno ();
--
2.21.0
[PATCH 0/3] Fix the O_PATH support for FIFOs
Commit aa55d22c, "Cygwin: honor the O_PATH flag when opening a FIFO", fixed a hang but otherwise didn't accomplish the purpose of the O_PATH flag as stated in the Linux man page for open(2): Obtain a file descriptor that can be used for two purposes: to indicate a location in the filesystem tree and to perform operations that act purely at the file descriptor level. The file itself is not opened, and other file operations (e.g., read(2), write(2), fchmod(2), fchown(2), fgetxattr(2), ioctl(2), mmap(2)) fail with the error EBADF. [The man page goes on to describe operations that *can* be performed: close(2), fchdir(2), fstat(2),] Opening a file or directory with the O_PATH flag requires no permissions on the object itself (but does require execute permission on the directories in the path prefix). The first problem in the current implementation is that if open(2) is called on a FIFO, fhandler_base::device_access_denied is called and tries to open the FIFO with read access, which isn't supposed to be required. This is fixed by the first patch in this series. The second patch makes fhandler_fifo::open call fhandler_base::open_fs if O_PATH is set, so that we actually obtain a handle that can be used for the purposes stated above. The third page tweaks fhandler_fifo::fcntl and fhandler_fifo::dup so that they work with O_PATH. In a followup email I'll provide the program I used to test this implementation. Ken Brown (3): Cygwin: device_access_denied: return false if O_PATH is set Cygwin: re-implement fhandler_fifo::open with O_PATH Cygwin: FIFO: tweak fcntl and dup when O_PATH is set winsup/cygwin/fhandler.cc | 3 +++ winsup/cygwin/fhandler_fifo.cc | 15 ++- 2 files changed, 9 insertions(+), 9 deletions(-) -- 2.21.0
Re: [PATCH] fhandler_proc.cc:format_proc_cpuinfo add rdpru flag
On 2020-01-23 05:44, Corinna Vinschen wrote: > On Jan 23 02:06, Brian Inglis wrote: >> rdpru flag is cpuid xfn 8008 ebx bit 4 added in linux 5.5; >> see AMD64 Architecture Programmerâs Manual Volume 3: >^ > This came over already broken. No idea if that's a problem of > your MUA or of the mailing list software. I fixed it to an > ordinary quote char locally. Sorry, didn't notice that sneaky quote from the PDF title in UTF-8 "’". Message source shows it's composed and sent in UTF-8 with: Content-Transfer-Encoding: 8bit by: X-Mailer: git-send-email 2.21.0 but without encoding or charset headers, so added git [sendemail] *Encoding config settings to avoid future issues by adding header (tested): Content-Type: text/plain; charset=UTF-8 -- 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.
Re: [PATCH 0/3] Fix the O_PATH support for FIFOs
On 1/23/2020 11:31 AM, Ken Brown wrote:
> Commit aa55d22c, "Cygwin: honor the O_PATH flag when opening a FIFO",
> fixed a hang but otherwise didn't accomplish the purpose of the O_PATH
> flag as stated in the Linux man page for open(2):
>
> Obtain a file descriptor that can be used for two purposes: to
> indicate a location in the filesystem tree and to perform
> operations that act purely at the file descriptor level. The
> file itself is not opened, and other file operations (e.g.,
> read(2), write(2), fchmod(2), fchown(2), fgetxattr(2),
> ioctl(2), mmap(2)) fail with the error EBADF.
>
> [The man page goes on to describe operations that *can* be
> performed: close(2), fchdir(2), fstat(2),]
>
> Opening a file or directory with the O_PATH flag requires no
> permissions on the object itself (but does require execute
> permission on the directories in the path prefix).
>
> The first problem in the current implementation is that if open(2) is
> called on a FIFO, fhandler_base::device_access_denied is called and
> tries to open the FIFO with read access, which isn't supposed to be
> required. This is fixed by the first patch in this series.
>
> The second patch makes fhandler_fifo::open call fhandler_base::open_fs
> if O_PATH is set, so that we actually obtain a handle that can be used
> for the purposes stated above.
>
> The third page tweaks fhandler_fifo::fcntl and fhandler_fifo::dup so
> that they work with O_PATH.
>
> In a followup email I'll provide the program I used to test this
> implementation.
Test program attached.
$ gcc -o o_path_fifo_test o_path_fifo_test.c
$ ./o_path_fifo_test.exe
The following calls should fail with EBADF:
read: OK
write: OK
fchmod: OK
fchown: OK
ioctl: OK
fgetxattr: OK
mmap: OK
The following calls should succeed:
fstat: OK
fstatfs: OK
fcntl_dup: OK
fcntl_getfl: OK
fcntl_setfl: OK
fcntl_getfd: OK
fcntl_setfd: OK
close: OK
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define FIFO_PATH "/tmp/myfifo"
int
main ()
{
struct stat s;
int fd;
if (mkfifo (FIFO_PATH, S_IRUSR | S_IWUSR | S_IWGRP) < 0
&& errno != EEXIST)
{
perror ("mkfifo");
exit (1);
}
fd = open (FIFO_PATH, O_PATH);
if (fd < 0)
{
perror ("open");
exit (1);
}
printf ("The following calls should fail with EBADF:\n");
errno = 0;
if (read (fd, NULL, 0) < 0 && errno == EBADF)
printf ("read: OK\n");
else
perror ("read");
errno = 0;
if (write (fd, NULL, 0) < 0 && errno == EBADF)
printf ("write: OK\n");
else
perror ("write");
errno = 0;
if (fchmod (fd, 0) < 0 && errno == EBADF)
printf ("fchmod: OK\n");
else
perror ("fchmod");
errno = 0;
if (fchown (fd, -1, -1) < 0 && errno == EBADF)
printf ("fchown: OK\n");
else
perror ("fchown");
errno = 0;
if (ioctl (fd, FIONBIO, NULL) < 0 && errno == EBADF)
printf ("ioctl: OK\n");
else
perror ("ioctl");
errno = 0;
if (fgetxattr (fd, "", NULL, 0) < 0 && errno == EBADF)
printf ("fgetxattr: OK\n");
else
perror ("fgetxattr");
errno = 0;
if (mmap (NULL, 1, 0, MAP_SHARED, fd, 0) == MAP_FAILED && errno == EBADF)
printf ("mmap: OK\n");
else
perror ("mmap");
printf ("\nThe following calls should succeed:\n");
if (fstat (fd, &s) < 0)
perror ("fstat");
else
printf ("fstat: OK\n");
struct statfs st;
if (fstatfs (fd, &st) < 0)
perror ("fstatfs");
else
printf ("fstatfs: OK\n");
if (fcntl (fd, F_DUPFD, 0) < 0)
perror ("fcntl_dup");
else
printf ("fcntl_dup: OK\n");
int flags = fcntl (fd, F_GETFL);
if (flags < 0)
perror ("fcntl_getfl");
else
printf ("fcntl_getfl: OK\n");
if (flags >= 0)
{
if (fcntl (fd, F_SETFL, flags) < 0)
perror ("fcntl_setfl");
else
printf ("fcntl_setfl: OK\n");
}
flags = fcntl (fd, F_GETFD);
if (flags < 0)
perror ("fcntl_getfd");
else
printf ("fcntl_getfd: OK\n");
if (flags >= 0)
{
if (fcntl (fd, F_SETFD, flags) < 0)
perror ("fcntl_setfd");
else
printf ("fcntl_setfd: OK\n");
}
if (close (fd) < 0)
perror ("close");
else
printf ("close: OK\n");
}
