set/get_mempolicy manpages say that the memory allocation
policy is per process while reading the code and testing shows
that it's actually per thread. Here's a quick fix, which may
need to be improved to better explain that we're allocating
in the context of a thread within a process address space.
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Long ago, some page reworking moved this text to a somewhat
random location in the middle of the socket options list.
Move it to a sensible location, and at the same time,
rework the text to be a little clearer.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The manpage packet(7) currently states that:
"When you send packets it is enough to specify sll_family, sll_addr,
sll_halen, sll_ifindex."
This is incorrect: you also need to specify sll_protocol.
(The protocol specified when the socket is created is used for
filtering inbound packets, but not for constructing outbound
packets.)
I encountered this while researching a page for my website:
http://www.microhowto.info/howto/send_an_arbitrary_ethernet_frame_using_an_af_packet_socket_in_c.html
To empirically verify the behaviour I took my test code from the
above page then changed it to use different values for the third
argument to socket() and the sll_protocol field:
- socket created with ETH_P_ARP, packet sent with ETH_P_ARP:
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==0:
packet sent with EtherType of 0
- socket created with 0x88b5, sll_protocol==htons(ETH_P_ARP):
packet sent with EtherType of ETH_P_ARP
- socket created with ETH_P_ARP, sll_protocol==htons(0x88b5):
packet sent with EtherType of 0x88b5
This shows that leaving sll_protocol set to zero does not have
the desired effect and that it needs to be set to the desired
link-layer protocol.
There is code in the relevant kernel source file
(net/packet/af_packet.c) which appears to inspect the value of the
sll_protocol field and use it as the link-layer protocol number,
however I am not sufficiently familiar with this subsystem to be
fully confident of what is happening. The line in question is:
proto = saddr->sll_protocol;
In version 3.4 of the kernel this can be found in the functions
packet_snd and tpacket_snd. In version 2.6.26 it is in packet_sendmsg.
Below is a patch that adds sll_protocol to the list of required fields.
This may not be the whole truth, since it is not clear what role if any
sll_protocol, sll_halen or sll_addr would play when the socket type is
SOCK_RAW, however I'm confident it is more accurate than the page as it
stands at present.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
'cflags' is a bit mask of *zero* (not one) or more flags.
Reported-by: Laurence Gonsalves <laurence@xenomachina.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This kernel constant is not exposed to user space.
Reported-by: Christophe Lohr <Christophe.Lohr@telecom-bretagne.eu>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Remove erroneous second initialization of msg.msg_controllen
in the example code for SCM_RIGHTS.
See https://bugzilla.kernel.org/show_bug.cgi?id=15952
Reported-by: Christopher Head <chead@chead.ca>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Document the 'hidepid' and 'gid' mount options that were added in
Linux 3.3. See https://bugzilla.kernel.org/show_bug.cgi?id=90641
Based on text by Vasiliy Kulikov in
Documentation/filesystems/proc.txt.
Reported-by: Cameron Norman <camerontnorman@gmail.com>
Cowritten-by: Vasiliy Kulikov <segooon@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See https://bugzilla.kernel.org/show_bug.cgi?id=43300
Reported-by: David Wilcox <davidvsthegiant@gmail.com>
Reported-by: Filipe Brandenburger <filbranden@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>