<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/net/can/raw.c, branch linux-5.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-12-18T07:27:00Z</updated>
<entry>
<title>net: add missing SOF_TIMESTAMPING_OPT_ID support</title>
<updated>2018-12-18T07:27:00Z</updated>
<author>
<name>Willem de Bruijn</name>
<email>willemb@google.com</email>
</author>
<published>2018-12-17T17:24:00Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8f932f762e7928d250e21006b00ff9b7718b0a64'/>
<id>urn:sha1:8f932f762e7928d250e21006b00ff9b7718b0a64</id>
<content type='text'>
SOF_TIMESTAMPING_OPT_ID is supported on TCP, UDP and RAW sockets.
But it was missing on RAW with IPPROTO_IP, PF_PACKET and CAN.

Add skb_setup_tx_timestamp that configures both tx_flags and tskey
for these paths that do not need corking or use bytestream keys.

Fixes: 09c2d251b707 ("net-timestamp: add key to disambiguate concurrent datagrams")
Signed-off-by: Willem de Bruijn &lt;willemb@google.com&gt;
Acked-by: Soheil Hassas Yeganeh &lt;soheil@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>can: raw: check for CAN FD capable netdev in raw_sendmsg()</title>
<updated>2018-11-09T16:19:34Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2018-10-24T08:27:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a43608fa77213ad5ac5f75994254b9f65d57cfa0'/>
<id>urn:sha1:a43608fa77213ad5ac5f75994254b9f65d57cfa0</id>
<content type='text'>
When the socket is CAN FD enabled it can handle CAN FD frame
transmissions.  Add an additional check in raw_sendmsg() as a CAN2.0 CAN
driver (non CAN FD) should never see a CAN FD frame. Due to the commonly
used can_dropped_invalid_skb() function the CAN 2.0 driver would drop
that CAN FD frame anyway - but with this patch the user gets a proper
-EINVAL return code.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>Revert changes to convert to -&gt;poll_mask() and aio IOCB_CMD_POLL</title>
<updated>2018-06-28T17:40:47Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-06-28T16:43:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a11e1d432b51f63ba698d044441284a661f01144'/>
<id>urn:sha1:a11e1d432b51f63ba698d044441284a661f01144</id>
<content type='text'>
The poll() changes were not well thought out, and completely
unexplained.  They also caused a huge performance regression, because
"-&gt;poll()" was no longer a trivial file operation that just called down
to the underlying file operations, but instead did at least two indirect
calls.

Indirect calls are sadly slow now with the Spectre mitigation, but the
performance problem could at least be largely mitigated by changing the
"-&gt;get_poll_head()" operation to just have a per-file-descriptor pointer
to the poll head instead.  That gets rid of one of the new indirections.

But that doesn't fix the new complexity that is completely unwarranted
for the regular case.  The (undocumented) reason for the poll() changes
was some alleged AIO poll race fixing, but we don't make the common case
slower and more complex for some uncommon special case, so this all
really needs way more explanations and most likely a fundamental
redesign.

[ This revert is a revert of about 30 different commits, not reverted
  individually because that would just be unnecessarily messy  - Linus ]

Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>net: convert datagram_poll users tp -&gt;poll_mask</title>
<updated>2018-05-26T07:16:44Z</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2018-04-09T13:27:37Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=db5051ead64a987e863f71a770351a75be542b15'/>
<id>urn:sha1:db5051ead64a987e863f71a770351a75be542b15</id>
<content type='text'>
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: make getname() functions return length rather than use int* parameter</title>
<updated>2018-02-12T19:15:04Z</updated>
<author>
<name>Denys Vlasenko</name>
<email>dvlasenk@redhat.com</email>
</author>
<published>2018-02-12T19:00:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9b2c45d479d0fb8647c9e83359df69162b5fbe5f'/>
<id>urn:sha1:9b2c45d479d0fb8647c9e83359df69162b5fbe5f</id>
<content type='text'>
Changes since v1:
Added changes in these files:
    drivers/infiniband/hw/usnic/usnic_transport.c
    drivers/staging/lustre/lnet/lnet/lib-socket.c
    drivers/target/iscsi/iscsi_target_login.c
    drivers/vhost/net.c
    fs/dlm/lowcomms.c
    fs/ocfs2/cluster/tcp.c
    security/tomoyo/network.c

Before:
All these functions either return a negative error indicator,
or store length of sockaddr into "int *socklen" parameter
and return zero on success.

"int *socklen" parameter is awkward. For example, if caller does not
care, it still needs to provide on-stack storage for the value
it does not need.

None of the many FOO_getname() functions of various protocols
ever used old value of *socklen. They always just overwrite it.

This change drops this parameter, and makes all these functions, on success,
return length of sockaddr. It's always &gt;= 0 and can be differentiated
from an error.

Tests in callers are changed from "if (err)" to "if (err &lt; 0)", where needed.

rpc_sockname() lost "int buflen" parameter, since its only use was
to be passed to kernel_getsockname() as &amp;buflen and subsequently
not used in any way.

Userspace API is not changed.

    text    data     bss      dec     hex filename
30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
30108109 2633612  873672 33615393 200ee21 vmlinux.o

Signed-off-by: Denys Vlasenko &lt;dvlasenk@redhat.com&gt;
CC: David S. Miller &lt;davem@davemloft.net&gt;
CC: linux-kernel@vger.kernel.org
CC: netdev@vger.kernel.org
CC: linux-bluetooth@vger.kernel.org
CC: linux-decnet-user@lists.sourceforge.net
CC: linux-wireless@vger.kernel.org
CC: linux-rdma@vger.kernel.org
CC: linux-sctp@vger.kernel.org
CC: linux-nfs@vger.kernel.org
CC: linux-x25@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>can: raw: raw_bind(): bail out if can_family is not AF_CAN</title>
<updated>2018-01-05T10:12:08Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2017-07-30T21:51:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=adb552c31915415fdb374172085f174f459727ea'/>
<id>urn:sha1:adb552c31915415fdb374172085f174f459727ea</id>
<content type='text'>
Until now CAN raw's bind() doesn't check if the can_familiy in the
struct sockaddr_can is set to AF_CAN. This patch adds the missing check.

Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: initial support for network namespaces</title>
<updated>2017-04-04T15:35:58Z</updated>
<author>
<name>Mario Kicherer</name>
<email>dev@kicherer.org</email>
</author>
<published>2017-02-21T11:19:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8e8cda6d737d356054c9eeef642aec0e8ae7e6bc'/>
<id>urn:sha1:8e8cda6d737d356054c9eeef642aec0e8ae7e6bc</id>
<content type='text'>
This patch adds initial support for network namespaces. The changes only
enable support in the CAN raw, proc and af_can code. GW and BCM still
have their checks that ensure that they are used only from the main
namespace.

The patch boils down to moving the global structures, i.e. the global
filter list and their /proc stats, into a per-namespace structure and passing
around the corresponding "struct net" in a lot of different places.

Changes since v1:
 - rebased on current HEAD (2bfe01e)
 - fixed overlong line

Signed-off-by: Mario Kicherer &lt;dev@kicherer.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: Fix kernel panic at security_sock_rcv_skb</title>
<updated>2017-01-29T23:30:56Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2017-01-27T16:11:44Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f1712c73714088a7252d276a57126d56c7d37e64'/>
<id>urn:sha1:f1712c73714088a7252d276a57126d56c7d37e64</id>
<content type='text'>
Zhang Yanmin reported crashes [1] and provided a patch adding a
synchronize_rcu() call in can_rx_unregister()

The main problem seems that the sockets themselves are not RCU
protected.

If CAN uses RCU for delivery, then sockets should be freed only after
one RCU grace period.

Recent kernels could use sock_set_flag(sk, SOCK_RCU_FREE), but let's
ease stable backports with the following fix instead.

[1]
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [&lt;ffffffff81495e25&gt;] selinux_socket_sock_rcv_skb+0x65/0x2a0

Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffff81485d8c&gt;] security_sock_rcv_skb+0x4c/0x60
 [&lt;ffffffff81d55771&gt;] sk_filter+0x41/0x210
 [&lt;ffffffff81d12913&gt;] sock_queue_rcv_skb+0x53/0x3a0
 [&lt;ffffffff81f0a2b3&gt;] raw_rcv+0x2a3/0x3c0
 [&lt;ffffffff81f06eab&gt;] can_rcv_filter+0x12b/0x370
 [&lt;ffffffff81f07af9&gt;] can_receive+0xd9/0x120
 [&lt;ffffffff81f07beb&gt;] can_rcv+0xab/0x100
 [&lt;ffffffff81d362ac&gt;] __netif_receive_skb_core+0xd8c/0x11f0
 [&lt;ffffffff81d36734&gt;] __netif_receive_skb+0x24/0xb0
 [&lt;ffffffff81d37f67&gt;] process_backlog+0x127/0x280
 [&lt;ffffffff81d36f7b&gt;] net_rx_action+0x33b/0x4f0
 [&lt;ffffffff810c88d4&gt;] __do_softirq+0x184/0x440
 [&lt;ffffffff81f9e86c&gt;] do_softirq_own_stack+0x1c/0x30
 &lt;EOI&gt;
 [&lt;ffffffff810c76fb&gt;] do_softirq.part.18+0x3b/0x40
 [&lt;ffffffff810c8bed&gt;] do_softirq+0x1d/0x20
 [&lt;ffffffff81d30085&gt;] netif_rx_ni+0xe5/0x110
 [&lt;ffffffff8199cc87&gt;] slcan_receive_buf+0x507/0x520
 [&lt;ffffffff8167ef7c&gt;] flush_to_ldisc+0x21c/0x230
 [&lt;ffffffff810e3baf&gt;] process_one_work+0x24f/0x670
 [&lt;ffffffff810e44ed&gt;] worker_thread+0x9d/0x6f0
 [&lt;ffffffff810e4450&gt;] ? rescuer_thread+0x480/0x480
 [&lt;ffffffff810ebafc&gt;] kthread+0x12c/0x150
 [&lt;ffffffff81f9ccef&gt;] ret_from_fork+0x3f/0x70

Reported-by: Zhang Yanmin &lt;yanmin.zhang@intel.com&gt;
Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>can: raw: raw_setsockopt: limit number of can_filter that can be set</title>
<updated>2016-12-07T09:45:57Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2016-12-05T10:44:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=332b05ca7a438f857c61a3c21a88489a21532364'/>
<id>urn:sha1:332b05ca7a438f857c61a3c21a88489a21532364</id>
<content type='text'>
This patch adds a check to limit the number of can_filters that can be
set via setsockopt on CAN_RAW sockets. Otherwise allocations &gt; MAX_ORDER
are not prevented resulting in a warning.

Reference: https://lkml.org/lkml/2016/12/2/230

Reported-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Tested-by: Andrey Konovalov &lt;andreyknvl@google.com&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>sock: enable timestamping using control messages</title>
<updated>2016-04-04T19:50:30Z</updated>
<author>
<name>Soheil Hassas Yeganeh</name>
<email>soheil@google.com</email>
</author>
<published>2016-04-03T03:08:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c14ac9451c34832554db33386a4393be8bba3a7b'/>
<id>urn:sha1:c14ac9451c34832554db33386a4393be8bba3a7b</id>
<content type='text'>
Currently, SOL_TIMESTAMPING can only be enabled using setsockopt.
This is very costly when users want to sample writes to gather
tx timestamps.

Add support for enabling SO_TIMESTAMPING via control messages by
using tsflags added in `struct sockcm_cookie` (added in the previous
patches in this series) to set the tx_flags of the last skb created in
a sendmsg. With this patch, the timestamp recording bits in tx_flags
of the skbuff is overridden if SO_TIMESTAMPING is passed in a cmsg.

Please note that this is only effective for overriding the recording
timestamps flags. Users should enable timestamp reporting (e.g.,
SOF_TIMESTAMPING_SOFTWARE | SOF_TIMESTAMPING_OPT_ID) using
socket options and then should ask for SOF_TIMESTAMPING_TX_*
using control messages per sendmsg to sample timestamps for each
write.

Signed-off-by: Soheil Hassas Yeganeh &lt;soheil@google.com&gt;
Acked-by: Willem de Bruijn &lt;willemb@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
