[v3,net-next,00/12] Generic TX reallocation for DSA

Message

Vladimir Oltean Nov. 1, 2020, 7:16 p.m. UTC

Christian has reported buggy usage of skb_put() in tag_ksz.c, which is
only triggerable in real life using his not-yet-published patches for
IEEE 1588 timestamping on Micrel KSZ switches.

The concrete problem there is that the driver can end up calling
skb_put() and exceed the end of the skb data area, because even though
it had reallocated the frame once before, it hadn't reallocated it large
enough. Christian explained it in more detail here:

https://lore.kernel.org/netdev/[e-mail]/
https://lore.kernel.org/netdev/[e-mail]/

But actually there's a bigger problem, which is that some taggers which
get more rarely tested tend to do some shenanigans which are uncaught
for the longest time, and in the meanwhile, their code gets copy-pasted
into other taggers, creating a mess. For example, the tail tagging
driver for Marvell 88E6060 currently reallocates _every_single_frame_ on
TX. Is that an obvious indication that nobody is using it? Sure. Is it a
good model to follow when developing a new tail tagging driver? No.

DSA has all the information it needs in order to simplify the job of a
tagger on TX. It knows whether it's a normal or a tail tagger, and what
is the protocol overhead it incurs. So this series performs the
reallocation centrally.

Changes in v3:
- Use dev_kfree_skb_any due to potential hardirq context in xmit path.

Changes in v2:
- Dropped the tx_realloc counters for now, since the patch was pretty
  controversial and I lack the time at the moment to introduce new UAPI
  for that.
- Do padding for tail taggers irrespective of whether they need to
  reallocate the skb or not.

Christian Eggers (2):
  net: dsa: tag_ksz: don't allocate additional memory for
    padding/tagging
  net: dsa: trailer: don't allocate additional memory for
    padding/tagging

Vladimir Oltean (10):
  net: dsa: implement a central TX reallocation procedure
  net: dsa: tag_qca: let DSA core deal with TX reallocation
  net: dsa: tag_ocelot: let DSA core deal with TX reallocation
  net: dsa: tag_mtk: let DSA core deal with TX reallocation
  net: dsa: tag_lan9303: let DSA core deal with TX reallocation
  net: dsa: tag_edsa: let DSA core deal with TX reallocation
  net: dsa: tag_brcm: let DSA core deal with TX reallocation
  net: dsa: tag_dsa: let DSA core deal with TX reallocation
  net: dsa: tag_gswip: let DSA core deal with TX reallocation
  net: dsa: tag_ar9331: let DSA core deal with TX reallocation

 net/dsa/slave.c       | 45 ++++++++++++++++++++++++++
 net/dsa/tag_ar9331.c  |  3 --
 net/dsa/tag_brcm.c    |  3 --
 net/dsa/tag_dsa.c     |  5 ---
 net/dsa/tag_edsa.c    |  4 ---
 net/dsa/tag_gswip.c   |  5 ---
 net/dsa/tag_ksz.c     | 73 ++++++-------------------------------------
 net/dsa/tag_lan9303.c |  9 ------
 net/dsa/tag_mtk.c     |  3 --
 net/dsa/tag_ocelot.c  |  7 -----
 net/dsa/tag_qca.c     |  3 --
 net/dsa/tag_trailer.c | 31 ++----------------
 12 files changed, 56 insertions(+), 135 deletions(-)

Comments

Jakub Kicinski Nov. 3, 2020, 1:43 a.m. UTC | #1

On Sun,  1 Nov 2020 21:16:08 +0200 Vladimir Oltean wrote:
> Christian has reported buggy usage of skb_put() in tag_ksz.c, which is
> only triggerable in real life using his not-yet-published patches for
> IEEE 1588 timestamping on Micrel KSZ switches.
> 
> The concrete problem there is that the driver can end up calling
> skb_put() and exceed the end of the skb data area, because even though
> it had reallocated the frame once before, it hadn't reallocated it large
> enough. Christian explained it in more detail here:
> 
> https://lore.kernel.org/netdev/[e-mail]/
> https://lore.kernel.org/netdev/[e-mail]/
> 
> But actually there's a bigger problem, which is that some taggers which
> get more rarely tested tend to do some shenanigans which are uncaught
> for the longest time, and in the meanwhile, their code gets copy-pasted
> into other taggers, creating a mess. For example, the tail tagging
> driver for Marvell 88E6060 currently reallocates _every_single_frame_ on
> TX. Is that an obvious indication that nobody is using it? Sure. Is it a
> good model to follow when developing a new tail tagging driver? No.
> 
> DSA has all the information it needs in order to simplify the job of a
> tagger on TX. It knows whether it's a normal or a tail tagger, and what
> is the protocol overhead it incurs. So this series performs the
> reallocation centrally.

Applied, thank you!