<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/linux/can, branch v5.4.38</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.38</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.38'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-01-14T19:08:28Z</updated>
<entry>
<title>can: can_dropped_invalid_skb(): ensure an initialized headroom in outgoing CAN sk_buffs</title>
<updated>2020-01-14T19:08:28Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2019-12-07T18:34:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a0dbd93fb148764c5ccc099307bba0b68e7fda4d'/>
<id>urn:sha1:a0dbd93fb148764c5ccc099307bba0b68e7fda4d</id>
<content type='text'>
commit e7153bf70c3496bac00e7e4f395bb8d8394ac0ea upstream.

KMSAN sysbot detected a read access to an untinitialized value in the
headroom of an outgoing CAN related sk_buff. When using CAN sockets this
area is filled appropriately - but when using a packet socket this
initialization is missing.

The problematic read access occurs in the CAN receive path which can
only be triggered when the sk_buff is sent through a (virtual) CAN
interface. So we check in the sending path whether we need to perform
the missing initializations.

Fixes: d3b58c47d330d ("can: replace timestamp as unique skb attribute")
Reported-by: syzbot+b02ff0707a97e4e79ebb@syzkaller.appspotmail.com
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Tested-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Cc: linux-stable &lt;stable@vger.kernel.org&gt; # &gt;= v4.1
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: af_can: export can_sock_destruct()</title>
<updated>2019-11-13T09:42:33Z</updated>
<author>
<name>Oleksij Rempel</name>
<email>o.rempel@pengutronix.de</email>
</author>
<published>2019-11-07T10:55:42Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=975987e7015bb12a482df7f14fd524417d2c8e8f'/>
<id>urn:sha1:975987e7015bb12a482df7f14fd524417d2c8e8f</id>
<content type='text'>
In j1939 we need our own struct sock::sk_destruct callback. Export the
generic af_can can_sock_destruct() that allows us to chain-call it.

Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'linux-can-next-for-5.4-20190904' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next</title>
<updated>2019-09-05T10:17:50Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2019-09-05T10:17:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=44c40910b66f786d33ffd2682ef38750eebb567c'/>
<id>urn:sha1:44c40910b66f786d33ffd2682ef38750eebb567c</id>
<content type='text'>
Marc Kleine-Budde says:

====================
pull-request: can-next 2019-09-04 j1939

this is a pull request for net-next/master consisting of 21 patches.

the first 12 patches are by me and target the CAN core infrastructure.
They clean up the names of variables , structs and struct members,
convert can_rx_register() to use max() instead of open coding it and
remove unneeded code from the can_pernet_exit() callback.

The next three patches are also by me and they introduce and make use of
the CAN midlayer private structure. It is used to hold protocol specific
per device data structures.

The next patch is by Oleksij Rempel, switches the
&amp;net-&gt;can.rcvlists_lock from a spin_lock() to a spin_lock_bh(), so that
it can be used from NAPI (soft IRQ) context.

The next 4 patches are by Kurt Van Dijck, he first updates his email
address via mailmap and then extends sockaddr_can to include j1939
members.

The final patch is the collective effort of many entities (The j1939
authors: Oliver Hartkopp, Bastian Stender, Elenita Hinds, kbuild test
robot, Kurt Van Dijck, Maxime Jayat, Robin van der Gracht, Oleksij
Rempel, Marc Kleine-Budde). It adds support of SAE J1939 protocol to the
CAN networking stack.

SAE J1939 is the vehicle bus recommended practice used for communication
and diagnostics among vehicle components. Originating in the car and
heavy-duty truck industry in the United States, it is now widely used in
other parts of the world.

P.S.: This pull request doesn't invalidate my last pull request:
      "pull-request: can-next 2019-09-03".
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>can: add support of SAE J1939 protocol</title>
<updated>2019-09-04T12:22:33Z</updated>
<author>
<name>The j1939 authors</name>
<email>linux-can@vger.kernel.org</email>
</author>
<published>2018-10-08T09:48:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9d71dd0c70099914fcd063135da3c580865e924c'/>
<id>urn:sha1:9d71dd0c70099914fcd063135da3c580865e924c</id>
<content type='text'>
SAE J1939 is the vehicle bus recommended practice used for communication
and diagnostics among vehicle components. Originating in the car and
heavy-duty truck industry in the United States, it is now widely used in
other parts of the world.

J1939, ISO 11783 and NMEA 2000 all share the same high level protocol.
SAE J1939 can be considered the replacement for the older SAE J1708 and
SAE J1587 specifications.

Acked-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Bastian Stender &lt;bst@pengutronix.de&gt;
Signed-off-by: Elenita Hinds &lt;ecathinds@gmail.com&gt;
Signed-off-by: kbuild test robot &lt;lkp@intel.com&gt;
Signed-off-by: Kurt Van Dijck &lt;dev.kurt@vandijck-laurijssen.be&gt;
Signed-off-by: Maxime Jayat &lt;maxime.jayat@mobile-devices.fr&gt;
Signed-off-by: Robin van der Gracht &lt;robin@protonic.nl&gt;
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: introduce CAN_REQUIRED_SIZE macro</title>
<updated>2019-09-04T11:29:15Z</updated>
<author>
<name>Kurt Van Dijck</name>
<email>dev.kurt@vandijck-laurijssen.be</email>
</author>
<published>2018-10-08T09:48:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9868b5d44f3df9dd75247acd23dddff0a42f79be'/>
<id>urn:sha1:9868b5d44f3df9dd75247acd23dddff0a42f79be</id>
<content type='text'>
The size of this structure will be increased with J1939 support. To stay
binary compatible, the CAN_REQUIRED_SIZE macro is introduced for
existing CAN protocols.

Signed-off-by: Kurt Van Dijck &lt;dev.kurt@vandijck-laurijssen.be&gt;
Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
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: make use of preallocated can_ml_priv for per device struct can_dev_rcv_lists</title>
<updated>2019-09-04T11:29:15Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2018-10-08T07:02:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8df9ffb888c021fa68f9075d545f2ec5eca37200'/>
<id>urn:sha1:8df9ffb888c021fa68f9075d545f2ec5eca37200</id>
<content type='text'>
This patch removes the old method of allocating the per device protocol
specific memory via a netdevice_notifier. This had the drawback, that
the allocation can fail, leading to a lot of null pointer checks in the
code. This also makes the live cycle management of this memory quite
complicated.

This patch switches from the allocating the struct can_dev_rcv_lists in
a NETDEV_REGISTER call to using the dev-&gt;ml_priv, which is allocated by
the driver since the previous patch.

Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
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: introduce CAN midlayer private and allocate it automatically</title>
<updated>2019-09-04T11:29:14Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2018-10-08T07:02:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ffd956eef69b212a724b1cc4cdc61828f3ad9104'/>
<id>urn:sha1:ffd956eef69b212a724b1cc4cdc61828f3ad9104</id>
<content type='text'>
This patch introduces the CAN midlayer private structure ("struct
can_ml_priv") which should be used to hold protocol specific per device
data structures. For now it's only member is "struct can_dev_rcv_lists".

The CAN midlayer private is allocated via alloc_netdev()'s private and
assigned to "struct net_device::ml_priv" during device creation. This is
done transparently for CAN drivers using alloc_candev(). The slcan, vcan
and vxcan drivers which are not using alloc_candev() have been adopted
manually. The memory layout of the netdev_priv allocated via
alloc_candev() will looke like this:

  +-------------------------+
  | driver's priv           |
  +-------------------------+
  | struct can_ml_priv      |
  +-------------------------+
  | array of struct sk_buff |
  +-------------------------+

Signed-off-by: Oleksij Rempel &lt;o.rempel@pengutronix.de&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: dev: avoid long lines</title>
<updated>2019-09-03T08:28:13Z</updated>
<author>
<name>Marc Kleine-Budde</name>
<email>mkl@pengutronix.de</email>
</author>
<published>2019-08-27T11:53:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d7bda73070201514d0d254f451c11bcc9b5890f1'/>
<id>urn:sha1:d7bda73070201514d0d254f451c11bcc9b5890f1</id>
<content type='text'>
This patch fixes long lines in the generic CAN device infrastructure.

Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: rcar_can: Remove unused platform data support</title>
<updated>2019-08-20T11:41:25Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert+renesas@glider.be</email>
</author>
<published>2019-08-14T09:22:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=30cc0ed73e3390af7c5573b159826e8162f09fe7'/>
<id>urn:sha1:30cc0ed73e3390af7c5573b159826e8162f09fe7</id>
<content type='text'>
All R-Car platforms use DT for describing CAN controllers. R-Car CAN
platform data support was never used in any upstream kernel.

Move the Clock Select Register settings enum into the driver, and remove
platform data support and the corresponding header file.

Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Reviewed-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
<entry>
<title>can: Add SPDX license identifiers for CAN subsystem</title>
<updated>2019-07-24T08:31:55Z</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2019-07-23T13:17:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fba76a58452694b9b13c07e48839fa84c75f57af'/>
<id>urn:sha1:fba76a58452694b9b13c07e48839fa84c75f57af</id>
<content type='text'>
Add missing SPDX identifiers for the CAN network layer and correct the SPDX
license for two of its include files to make sure the BSD-3-Clause applies
for the entire subsystem.

Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
</content>
</entry>
</feed>
