Re: [PATCH net v8 4/6] net/sched: netem: validate slot configuration

[Simon Horman]

On Fri, Apr 17, 2026 at 08:19:42PM -0700, Stephen Hemminger wrote:
> Reject slot configurations that have no defensible meaning:
> 
>   - negative min_delay or max_delay
>   - min_delay greater than max_delay
>   - negative dist_delay or dist_jitter
>   - negative max_packets or max_bytes
> 
> Negative or out-of-order delays underflow in get_slot_next(),
> producing garbage intervals. Negative limits trip the per-slot
> accounting (packets_left/bytes_left <= 0) on the first packet of
> every slot, defeating the rate-limiting half of the slot feature.
> 
> Note that dist_jitter has been silently coerced to its absolute
> value by get_slot() since the feature was introduced; rejecting
> negatives here converts that silent coercion into -EINVAL. The
> abs() can be removed in a follow-up.
> 
> Fixes: 836af83b54e3 ("netem: support delivering packets in delayed time slots")
> Signed-off-by: Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx>

Reviewed-by: Simon Horman <horms@xxxxxxxxxx>

I acknowledge that Sashiko has provided feedback on this patch.

1. "Does rejecting negative dist_jitter values with -EINVAL cause a
    regression in userspace ABI backward compatibility?  Since the kernel
    previously accepted these values and silently coerced them using abs(),
    existing userspace tools or scripts that happen to pass negative values
    might start failing to configure the qdisc."

This is intended and explicitly explained in the cover letter.

2. "Could directly dereferencing 64-bit fields from the netlink attribute
    payload cause undefined behavior on strict-alignment architectures?
    Netlink attribute payloads are typically only guaranteed to be 4-byte
    aligned because NLA_ALIGNTO is 4, but the __s64 fields within
    tc_netem_slot like min_delay require 8-byte natural alignment.
    Performing an 8-byte read from a potentially 4-byte aligned address
    might cause an alignment fault on certain architectures."

This patch does not change the presence of this problem; and I suspect
it is not a problem at all.