Add the list of wireless IOCTLs.
We should later add a page ioctl_wireless.2 decribing the usage.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
netdevice.7 describes most of the IOCTLs of sockios.h
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Move the error register documentation into the main table rather
than listing them in sentences after the fact.
Add sparc error return details.
Add details for alpha/arc/m68k/microblaze/nios2/powerpc/superh/
tile/xtensa.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The name is overly long, and does not hint at the fact
that this argument is a pointer. Fix this by renaming:
s/timeout_ts/tmo_p/
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
From the context, it is apparent that in the code explaining
ppoll in terms of poll, timeout_ts must be a pointer.
Usage #1: ready = ppoll(&fds, nfds, timeout_ts, &sigmask);
Usage #2: (timeout_ts == NULL)
Thus member access in (timeout_ts.tv_sec * 1000 +
timeout_ts.tv_nsec / 1000000) is an error.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As noted by Archie Cobbs:
I was trying to use srandom_() and initstate_r() and fell into
the exact same trap this this fellow did:
http://stackoverflow.com/questions/18569523/segfault-at-srandom-r,
resulting in a segfault.
The man page is really unclear here. It leads one to believe
(falsely) that invoking setrandom_r() is sufficient to initialize
a struct random_data, but this is not the case. In fact
srandom_r() is not like srandom() at all in this respect.
Reported-by: Archie Cobbs <archie.cobbs@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
'tloc' is visually easier to spot, and also is used
in POSIX and in man pages on other systems.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Comments from Davidlohr:
So there are two things here regarding ordering. One is the
most obvious which is ordered due to the taking/dropping the
hb spinlock. Secondly, its the cases which Peter brought up
a while ago that involves atomic futex ops futex_atomic_*(),
which do not have clearly defined semantics, and you get
inconsistencies with certain archs (tile being the worst
iirc).
But anyway, the important thing users need to know about is
that the atomic futex operation must be totally ordered wrt
any other user tasks that are trying to access that address.
This is not necessarily the case for kernel ops. Peter
illustrates this nicely with lock stealing example; (see
https://lkml.org/lkml/2015/8/26/596).
Internally, I believe we decided that making it fully ordered
(as opposed to making use of implicit barriers for
ACQUIRE/RELEASE), so you'd end up having an MB ll/sc MB kind of
setup.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Reported-by: Davidlohr Bueso <dave@stgolabs.net>
sendfile(2) can return more error codes than are
documented in sendfile(2). This patch adds some details:
- EINVAL can be returned if count is negative; from function
rw_verify_area in fs/read_write.c, called from do_sendfile,
called from sys_sendfile.
- EOVERFLOW can be returned if count is too large; from
rw_verify_area, called from do_sendfile, called from
sys_sendfile, or directly from do_sendfile in one case
(pos + count > max size of either in_fd or out_fd).
- ESPIPE can be returned if offset is not a NULL pointer but
the input file does not support FMODE_PREAD;
from do_sendfile, called from sys_sendfile.
Signed-off-by: Laurent Georget <laurent.georget@supelec.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Heinrich Schuchardt