From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:24:49
Hello Jakub, hello David,
this is a pull request of 9 patches for net/master.
The 1st patch is by Vincent Mailhol and fixes a use after free in the
pch_can driver.
Dan Carpenter fixes a use after free in the ems_pcmcia sja1000 driver.
The remaining 7 patches target the m_can driver. Brian Silverman
contributes a patch to disable and ignore the ELO interrupt, which is
currently not handled in the driver and may lead to an interrupt
storm. Vincent Mailhol's patch fixes a memory leak in the error path
of the m_can_read_fifo() function. The remaining patches are
contributed by Matthias Schiffer, first a iomap_read_fifo() and
iomap_write_fifo() functions are fixed in the PCI glue driver, then
the clock rate for the Intel Ekhart Lake platform is fixed, the last 3
patches add support for the custom bit timings on the Elkhart Lake
platform.
regards,
Marc
---
The following changes since commit 4dbb0dad8e63fcd0b5a117c2861d2abe7ff5f186:
devlink: fix netns refcount leak in devlink_nl_cmd_reload() (2021-12-06 16:56:32 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-5.16-20211207
for you to fetch changes up to ea4c1787685dbf9842046f05b6390b6901ee6ba2:
can: m_can: pci: use custom bit timings for Elkhart Lake (2021-12-07 09:51:41 +0100)
----------------------------------------------------------------
linux-can-fixes-for-5.16-20211207
----------------------------------------------------------------
Brian Silverman (1):
can: m_can: Disable and ignore ELO interrupt
Dan Carpenter (1):
can: sja1000: fix use after free in ems_pcmcia_add_card()
Matthias Schiffer (5):
can: m_can: pci: fix iomap_read_fifo() and iomap_write_fifo()
can: m_can: pci: fix incorrect reference clock rate
Revert "can: m_can: remove support for custom bit timing"
can: m_can: make custom bittiming fields const
can: m_can: pci: use custom bit timings for Elkhart Lake
Vincent Mailhol (2):
can: pch_can: pch_can_rx_normal: fix use after free
can: m_can: m_can_read_fifo: fix memory leak in error branch
drivers/net/can/m_can/m_can.c | 42 +++++++++++++++---------
drivers/net/can/m_can/m_can.h | 3 ++
drivers/net/can/m_can/m_can_pci.c | 62 ++++++++++++++++++++++++++++++++----
drivers/net/can/pch_can.c | 2 +-
drivers/net/can/sja1000/ems_pcmcia.c | 7 +++-
5 files changed, 93 insertions(+), 23 deletions(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:24:51
From: Vincent Mailhol <redacted>
After calling netif_receive_skb(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is dereferenced
just after the call netif_receive_skb(skb).
Reordering the lines solves the issue.
Fixes: b21d18b51b31 ("can: Topcliff: Add PCH_CAN driver.")
Link: https://lore.kernel.org/all/20211123111654.621610-1-mailhol.vincent@wanadoo.fr
Cc: stable@vger.kernel.org
Signed-off-by: Vincent Mailhol <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/pch_can.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:24:54
From: Dan Carpenter <redacted>
If the last channel is not available then "dev" is freed. Fortunately,
we can just use "pdev->irq" instead.
Also we should check if at least one channel was set up.
Fixes: fd734c6f25ae ("can/sja1000: add driver for EMS PCMCIA card")
Link: https://lore.kernel.org/all/20211124145041.GB13656@kili
Cc: stable@vger.kernel.org
Signed-off-by: Dan Carpenter <redacted>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/ems_pcmcia.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:24:56
From: Brian Silverman <redacted>
With the design of this driver, this condition is often triggered.
However, the counter that this interrupt indicates an overflow is never
read either, so overflowing is harmless.
On my system, when a CAN bus starts flapping up and down, this locks up
the whole system with lots of interrupts and printks.
Specifically, this interrupt indicates the CEL field of ECR has
overflowed. All reads of ECR mask out CEL.
Fixes: e0d1f4816f2a ("can: m_can: add Bosch M_CAN controller support")
Link: https://lore.kernel.org/all/20211129222628.7490-1-brian.silverman@bluerivertech.com
Cc: stable@vger.kernel.org
Signed-off-by: Brian Silverman <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:25:08
From: Matthias Schiffer <redacted>
When testing the CAN controller on our Ekhart Lake hardware, we
determined that all communication was running with twice the configured
bitrate. Changing the reference clock rate from 100MHz to 200MHz fixed
this. Intel's support has confirmed to us that 200MHz is indeed the
correct clock rate.
Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake")
Link: https://lore.kernel.org/all/c9cf3995f45c363e432b3ae8eb1275e54f009fc8.1636967198.git.matthias.schiffer@ew.tq-group.com
Cc: stable@vger.kernel.org
Signed-off-by: Matthias Schiffer <redacted>
Acked-by: Jarkko Nikula <redacted>
Reviewed-by: Jarkko Nikula <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:25:09
From: Matthias Schiffer <redacted>
The timing limits specified by the Elkhart Lake CPU datasheets do not
match the defaults. Let's reintroduce the support for custom bit timings.
This reverts commit 0ddd83fbebbc5537f9d180d31f659db3564be708.
Link: https://lore.kernel.org/all/00c9e2596b1a548906921a574d4ef7a03c0dace0.1636967198.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Matthias Schiffer <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can.c | 24 ++++++++++++++++++------
drivers/net/can/m_can/m_can.h | 3 +++
2 files changed, 21 insertions(+), 6 deletions(-)
@@ -1494,20 +1494,32 @@ static int m_can_dev_setup(struct m_can_classdev *cdev)case30:/* CAN_CTRLMODE_FD_NON_ISO is fixed with M_CAN IP v3.0.x */can_set_static_ctrlmode(dev,CAN_CTRLMODE_FD_NON_ISO);-cdev->can.bittiming_const=&m_can_bittiming_const_30X;-cdev->can.data_bittiming_const=&m_can_data_bittiming_const_30X;+cdev->can.bittiming_const=cdev->bit_timing?+cdev->bit_timing:&m_can_bittiming_const_30X;++cdev->can.data_bittiming_const=cdev->data_timing?+cdev->data_timing:+&m_can_data_bittiming_const_30X;break;case31:/* CAN_CTRLMODE_FD_NON_ISO is fixed with M_CAN IP v3.1.x */can_set_static_ctrlmode(dev,CAN_CTRLMODE_FD_NON_ISO);-cdev->can.bittiming_const=&m_can_bittiming_const_31X;-cdev->can.data_bittiming_const=&m_can_data_bittiming_const_31X;+cdev->can.bittiming_const=cdev->bit_timing?+cdev->bit_timing:&m_can_bittiming_const_31X;++cdev->can.data_bittiming_const=cdev->data_timing?+cdev->data_timing:+&m_can_data_bittiming_const_31X;break;case32:case33:/* Support both MCAN version v3.2.x and v3.3.0 */-cdev->can.bittiming_const=&m_can_bittiming_const_31X;-cdev->can.data_bittiming_const=&m_can_data_bittiming_const_31X;+cdev->can.bittiming_const=cdev->bit_timing?+cdev->bit_timing:&m_can_bittiming_const_31X;++cdev->can.data_bittiming_const=cdev->data_timing?+cdev->data_timing:+&m_can_data_bittiming_const_31X;cdev->can.ctrlmode_supported|=(m_can_niso_supported(cdev)?
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:25:10
From: Vincent Mailhol <redacted>
In m_can_read_fifo(), if the second call to m_can_fifo_read() fails,
the function jump to the out_fail label and returns without calling
m_can_receive_skb(). This means that the skb previously allocated by
alloc_can_skb() is not freed. In other terms, this is a memory leak.
This patch adds a goto label to destroy the skb if an error occurs.
Issue was found with GCC -fanalyzer, please follow the link below for
details.
Fixes: e39381770ec9 ("can: m_can: Disable IRQs on FIFO bus errors")
Link: https://lore.kernel.org/all/20211107050755.70655-1-mailhol.vincent@wanadoo.fr
Cc: stable@vger.kernel.org
Cc: Matt Kline <redacted>
Signed-off-by: Vincent Mailhol <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:25:13
From: Matthias Schiffer <redacted>
The same fix that was previously done in m_can_platform in commit
99d173fbe894 ("can: m_can: fix iomap_read_fifo() and iomap_write_fifo()")
is required in m_can_pci as well to make iomap_read_fifo() and
iomap_write_fifo() work for val_count > 1.
Fixes: 812270e5445b ("can: m_can: Batch FIFO writes during CAN transmit")
Fixes: 1aa6772f64b4 ("can: m_can: Batch FIFO reads during CAN receive")
Link: https://lore.kernel.org/all/20211118144011.10921-1-matthias.schiffer@ew.tq-group.com
Cc: stable@vger.kernel.org
Cc: Matt Kline <redacted>
Signed-off-by: Matthias Schiffer <redacted>
Tested-by: Jarkko Nikula <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can_pci.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:25:13
From: Matthias Schiffer <redacted>
The assigned timing structs will be defined a const anyway, so we can
avoid a few casts by declaring the struct fields as const as well.
Link: https://lore.kernel.org/all/4508fa4e639164b2584c49a065d90c78a91fa568.1636967198.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Matthias Schiffer <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Marc Kleine-Budde <mkl@pengutronix.de> Date: 2021-12-07 10:25:14
From: Matthias Schiffer <redacted>
The relevant datasheet [1] specifies nonstandard limits for the bit timing
parameters. While it is unclear what the exact effect of violating these
limits is, it seems like a good idea to adhere to the documentation.
[1] Intel Atom® x6000E Series, and Intel® Pentium® and Celeron® N and J
Series Processors for IoT Applications Datasheet,
Volume 2 (Book 3 of 3), July 2021, Revision 001
Fixes: cab7ffc0324f ("can: m_can: add PCI glue driver for Intel Elkhart Lake")
Link: https://lore.kernel.org/all/9eba5d7c05a48ead4024ffa6e5926f191d8c6b38.1636967198.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Matthias Schiffer <redacted>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/m_can/m_can_pci.c | 48 ++++++++++++++++++++++++++++---
1 file changed, 44 insertions(+), 4 deletions(-)
Hello:
This series was applied to netdev/net.git (master)
by Marc Kleine-Budde [off-list ref]:
On Tue, 7 Dec 2021 11:24:12 +0100 you wrote:
From: Vincent Mailhol <redacted>
After calling netif_receive_skb(skb), dereferencing skb is unsafe.
Especially, the can_frame cf which aliases skb memory is dereferenced
just after the call netif_receive_skb(skb).
Reordering the lines solves the issue.
[...]