[BUG] net/sched: rejected TAPRIO preemption change leaves max-sdu active

[shaos]

Hello,

On software TAPRIO, request TC0 max-sdu=100 with fp=PREEMPTIBLE. Parsing stores the per-TC values before rejecting unsupported preemption with -EOPNOTSUPP. A later valid schedule that omits max-sdu inherits the rejected value.

HEAD commit:    c03c1a14507dfaf8b856c2608f9ac216021fc222
git tree:       30fd2ef82912c26cf3a58ad0ba6afc375fa851ac
source version: Linux 7.3.0, local master
compiler:       gcc 11.4.0, GNU ld 2.38

console output:
https://gist.githubusercontent.com/shaos26/4f6b811c8d96b86c798f6eb3a3e9893c/raw/e16aedab2611e181429db1daa77ce7bdd82b6219/console-output.txt
kernel config:
https://gist.githubusercontent.com/shaos26/4f6b811c8d96b86c798f6eb3a3e9893c/raw/2f23bbfbfd70e81aa2eab3771a97f07c777d4c01/kernel-config.txt
reproducer:
https://gist.githubusercontent.com/shaos26/4f6b811c8d96b86c798f6eb3a3e9893c/raw/0b94f41b9da291993c9adc1802b31fb6f812b36e/poc.c

Build the tested kernel with the attached configuration, compile poc.c statically and run in a disposable QEMU/network namespace with CAP_NET_ADMIN. The probe submits the rejected software-preemption change, applies a valid schedule and tests short and long frames.

Impact and prerequisites:
The qdisc silently starts dropping 200-byte frames after an earlier request reported failure. This is a configuration atomicity issue for a CAP_NET_ADMIN caller; directly applying the same valid max-sdu has the same packet effect, so it is not an escalation.

Validation: Two fresh exact-HEAD boots showed fp=2 after the rejected change and then max_sdu=100/drop of the 200-byte frame after the valid follow-up. The patched atomicity control retained the old state.

Thanks,

shaos