Jon Kohler wrote:

quoted

On Nov 28, 2025, at 10:07 PM, Willem de Bruijn [off-list ref] wrote:

Jon Kohler wrote:

quoted

Fold kfree_skb and consume_skb for tun_put_user into tun_put_user and
rework kfree_skb to take a drop reason. Add drop reason to all drop
sites and ensure that all failing paths properly increment drop
counter.

Signed-off-by: Jon Kohler <redacted>
---
drivers/net/tun.c | 51 +++++++++++++++++++++++++++++++----------------
1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 68ad46ab04a4..e0f5e1fe4bd0 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c

@@ -2035,6 +2035,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
    struct sk_buff *skb,
    struct iov_iter *iter)

{
+ enum skb_drop_reason drop_reason = SKB_DROP_REASON_NOT_SPECIFIED;
struct tun_pi pi = { 0, skb->protocol };
ssize_t total;
int vlan_offset = 0;

@@ -2051,8 +2052,11 @@ static ssize_t tun_put_user(struct tun_struct *tun,

total = skb->len + vlan_hlen + vnet_hdr_sz;

if (!(tun->flags & IFF_NO_PI)) {
- if (iov_iter_count(iter) < sizeof(pi))
- return -EINVAL;
+ if (iov_iter_count(iter) < sizeof(pi)) {
+ ret = -EINVAL;
+ drop_reason = SKB_DROP_REASON_PKT_TOO_SMALL;

PI counts as SKB_DROP_REASON_DEV_HDR?

Are you saying I should change this use case to DEV_HDR?

This one seemed like a pretty straight forward “It’s too small” case,
no? Or am I misreading into what you’re saying here?

Happy to take a suggestion if I’ve got the drop reason wired
wrong (or if we need to cook up a brand new drop reason for any of
these)

I agree that it's a clear case of the buffer being too small. But I
consider PI not part of the packet itself, but bad device headers.
It's borderline nitpicking. With that context, pick which you see fits
best.