[Bug 2125448] Re: Burst parameter of tc police only allows 4GB while the kernel can support much more

[Ubuntu Foundations Team Bug Bot]

The attachment "lp2125448_questing.debdiff" seems to be a debdiff.  The
ubuntu-sponsors team has been subscribed to the bug report so that they
can review and hopefully sponsor the debdiff.  If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe
the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issue please contact him.]

** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2125448

Title:
  Burst parameter of tc police only allows 4GB while the kernel can
  support much more

Status in iproute2 package in Ubuntu:
  In Progress
Status in iproute2 source package in Jammy:
  New
Status in iproute2 source package in Noble:
  New
Status in iproute2 source package in Plucky:
  New
Status in iproute2 source package in Questing:
  In Progress

Bug description:
  [Impact]
  The tc police burst option limits the size of the burst up to 4 GiB, i.e., UINT_MAX for a 32 bit unsigned int. However, the underlying implementation of burst is computed as "time at the specified rate", and for higher rates, a burst size exceeding 4 GiB is feasible without modification to the kernel.
  Conversely, there can be bursts smaller that 4 GiB that overflow the burst time calculation and that was not detected.

  [Test Plan]
  All the following commands must be run as root. We are assuming the tested interface is eth0.

  Add fq_codel queuing discipline

  # tc qdisc add dev eth0 root fq_codel

  Check the assigned discipline number

  # tc -s qdisc show dev eth0
  qdisc fq_codel nnnn: root refcnt 13 limit ...

  Note the 4 digits nnnn number. It should be substituted for the nnnn
  number in the rest of the following commands.

  1) Tests before the patch is applied

  Try to set a filter with a burst of exactly 4Gb at 10Gbit rate and see
  that it fails:

  # tc filter add dev eth0 protocol ip prio 1 parent nnnn: handle 1 fw police rate 10Gbit peakrate 10Gbit burst 4294967296 mtu 64Kb conform-exceed reclassify
  Error: argument "4294967296" is wrong: buffer

  Try to set a filter with a burst that is greater than the maximum
  time:

  # tc filter add dev eth0 protocol ip prio 1 parent nnnn: handle 1 fw
  police rate 1Mbit peakrate 10Gbit burst 34375000 mtu 64Kb conform-
  exceed reclassify

  Check if it was set correctly:

  # tc -raw filter get dev eth0 protocol ip prio 1 parent nnnn: handle 1 fw
  filter parent nnnn: protocol ip pref 1 fw chain 0 handle 0x1  police 0x1 rate 1Mbit burst 15261b mtu 64Kb [001d1bf8] peakrate 10Gbit action reclassify overhead 0b

  We can see a result with the overflowed buffer (burst is 15261b)

  2) Tests after the patch is applied:

  Try to set a filter with a burst of exactly 4Gb at 10Gbit rate:

  # tc filter add dev eth0 protocol ip prio 1 parent nnnn: handle 1 fw
  police rate 10Gbit peakrate 10Gbit burst 4294967296 mtu 64Kb conform-
  exceed reclassify

  We can check that it was set correctly (burst is 4Gb):

  # tc -raw filter get dev eth0 protocol ip prio 1 parent nnnn: handle 1 fw
  filter parent nnnn: protocol ip pref 1 fw chain 0 handle 0x1  police 0x1 rate 10Gbit burst 4Gb mtu 64Kb [03333334] peakrate 10Gbit action reclassify overhead 0b

  Remove the filter:

  # tc filter del dev eth0 protocol ip prio 1 parent nnnn:

  Try to set a filter with a burst that is greater than the maximum
  time:

  # tc filter add dev eth0 protocol ip prio 1 parent nnnn: handle 1 fw police rate 1Mbit peakrate 10Gbit burst 34375000 mtu 64Kb conform-exceed reclassify
  POLICE: burst out of range

  We see that it is out of range

  [Where problems could occur]
  Externally the only difference with the installed patch is that some commands that will previously overflow without errors will now fail. That might break some scripts but it can be argued that they were already broken before.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/2125448/+subscriptions