Re: [PATCH net-next v13 1/5] tun/tap: add IFF_BACKPRESSURE flag

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Premature UAPI exposure of `IFF_BACKPRESSURE` flag breaks feature detection.
--

--- Patch [1]: [PATCH net-next v13 1/5] tun/tap: add IFF_BACKPRESSURE flag ---
commit 43e4cc9000a7c476758fd2aa10db82e86b3c41ca
Author: Simon Schippers <[email protected]>

tun/tap: add IFF_BACKPRESSURE flag

This commit adds the IFF_BACKPRESSURE flag to the tun/tap UAPI headers and
enables it in TUN_FEATURES. The flag is intended to gate qdisc backpressure
logic added in subsequent patches.

> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
[ ... ]
> @@ -98,7 +98,8 @@ static void tun_default_link_ksettings(struct net_device *dev,
>  #define TUN_FASYNC	IFF_ATTACH_QUEUE
>  
>  #define TUN_FEATURES (IFF_NO_PI | IFF_ONE_QUEUE | IFF_VNET_HDR | \
> -		      IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS)
> +		      IFF_MULTI_QUEUE | IFF_NAPI | IFF_NAPI_FRAGS | \
> +		      IFF_BACKPRESSURE)

[Severity: Medium]
Does adding this flag to TUN_FEATURES before the implementation is present
break userspace feature detection during a git bisect?

If userspace calls ioctl(TUNGETFEATURES) at this specific commit, it will
see IFF_BACKPRESSURE as supported and might set it via TUNSETIFF. However,
because the actual backpressure logic is delegated to later patches in the
series, the kernel will silently drop packets instead of exerting
backpressure.

Would it be safer to introduce the UAPI flag definitions early in the
series, but wait to add IFF_BACKPRESSURE to TUN_FEATURES until the final
patch when the implementation is fully in place?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1