[Xenomai-core] [bug] accept() in non-blocking mode fails with EPERM instead of EAGAIN
Hi,
I believe I found a bug in the Xenomai Posix skin while trying to use
boost::asio: The accept() call in asychronous mode
fails with ENOPEM instead of EAGAIN. Other than that, the call 'works'
in the sense that calling it again after a connection is established
returns a new file descriptor.
I'm running xenomai rev 50ee47db78117e8711d4d2f5310dff262a425eb7 with
kernel 2.6.31 i686.
Xenomai is built with no option (other than --enable-shared
--disable-static) to configure.
I'm joining a simple C file to reproduce the problem.
Its output when built 'natively', and running nc localhost 12345 after
some time is:
-1 11
accept: Resource temporarily unavailable
-1 11
accept: Resource temporarily unavailable
...
OK 4
Its output when built using the posix skin and run as root is:
-1 1
accept: Operation not permitted
-1 1
accept: Operation not permitted
...
OK 4
The consequence of this bug is that all applications doing asynchronous
accept() calls will fail to work, as they will incorrectly believe the
operation failed.
Regards,
Matthieu
#include sys/types.h /* See NOTES */
#include sys/socket.h
#include sys/ioctl.h
#include netinet/in.h
#include netinet/tcp.h
#include string.h
#include stdio.h
#include errno.h
#include unistd.h
#include sys/mman.h
int main()
{
int s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
int t = 1;
int res;
struct sockaddr_in sa;
mlockall(MCL_PRESENT | MCL_FUTURE);
if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, t, sizeof(int)))
perror(setsockopt);
memset(sa, 0, sizeof (sa));
sa.sin_family = AF_INET;
sa.sin_port = htons(12345);
sa.sin_addr.s_addr = INADDR_ANY;
if (bind(s, (struct sockaddr *)sa, sizeof(sa)))
perror(bind);
if (listen(s, 128))
perror(listen);
t = 1;
if (ioctl(s, FIONBIO, t))
perror(ioctl);
do {
res = accept(s, 0, 0);
printf(%d %d\n, (int)res, (int)errno);
perror(accept);
usleep(50);
} while(res==-1);
printf(OK %d\n, (int)res);
return 0;
}
config-2.6.31-xenomai.gz
Description: GNU Zip compressed data
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RFC: 2.5 todo list.
Hi guys, full of energy after this tremendous first XUM, I would like to start a discussion about what people would like to see in the 2.5 branch. Here is a first list, please feel free to criticize it: - signals in primary domain (something that we almost forgot) - xnsynch_acquire using atomic_cmpxchg unconditionally (no #ifdefs) - statistics of all mapped named heaps in /proc/xenomai/heap - unwapped access to user-space posix skin methods - fast semaphores in user-space - syscall-less select ? Actually, there are already a lot of things. So, what do you think? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RFC: primary mode signals design.
Hi, During my flights and connections, I had a thought about this primary mode signals issue. Since the needs in term of primary mode signals greatly depends on what the skins want to do with it (native wants hooks, posix wants posix conformant signals), I think as much work as possible should be done in the nucleus and skins implementation, not in the I-pipe (as usual). So, I propose to: 1- add an I-pipe SIGNAL_PENDING event 2- add a bit somewhere in the task_struct or thread_info stuctures indicating that signals are pending 3- add a service to mark the bit, like: int ipipe_mark_signal_pending(struct task_struct *task); 4- in entry.S, when going back to user-space, test and clear the bit is set, and if it was set, trigger the event 5- implement services allowing to run a callback with some cookie when returning to user-space, we may also need to be able to push on stack some arguments that should be passed to the callback, (we need this service internally anyway to push the pt_regs structure on stack, so that the calling context can be restored after execution of the callback, and we need a little help from user-space for this restoration, probably in bind.h). 6- The nucleus would then propose to register per-skin callbacks, subscribe to the SIGNAL_PENDING event, and dispatch a pending signal to all the skins which are currently expecting it. The skins would do the callbacks housekeeping at their level. The critical point is clearly point 5, and it is still a bit fuzzy. At least, I think I know how I would do it on ARM, but I do not know how to package the services in such a way that it would tolerate differences between platform. It is unclear, for instance whether some or all platforms may need an additional syscall to restore the original context due to the need of running in privileged mode to restore some registers value. Ok, now that I think about it, an additional syscall would be the most portable way, but also a bit slow. What do you think? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
