[PATCH net-next v2] tap: report IFF_DETACH_QUEUE in TUNGETIFF

[Umang Pokhriyal <umangpokhriyall@gmail.com>]

tun sets IFF_DETACH_QUEUE in the flags returned by TUNGETIFF when the
queue is detached, since commit 3d407a80b62f ("tun: Report whether the
queue is attached or not"). tap does not, so userspace cannot tell a
detached macvtap or ipvtap queue from an attached one.

Cloud Hypervisor ran into this when checking queue state on macvtap.

Report the flag from q->enabled, as tun does. Unlike tun, tap accepts
TUNSETIFF on a bound fd, so ignore IFF_DETACH_QUEUE there to keep
writing the TUNGETIFF flags back working.

Assisted-by: LLM
Signed-off-by: Umang Pokhriyal <umangpokhriyall@gmail.com>
---

Notes:
    v2:
      - ignore IFF_DETACH_QUEUE in TUNSETIFF so the TUNGETIFF flags can be
        written back, and describe the change as parity with tun (Sashiko)
      - drop Willem's Reviewed-by because of the new TUNSETIFF hunk
    v1: https://lore.kernel.org/netdev/20260929142238.41742-1-umangpokhriyall@gmail.com/

 drivers/net/tap.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/tap.c b/drivers/net/tap.c
index ff67d99deb39e..832439b8a8988 100644
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -932,6 +932,9 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
 		if (get_user(u, &ifr->ifr_flags))
 			return -EFAULT;
 
+		/* TUNGETIFF may report IFF_DETACH_QUEUE, ignore it here */
+		u &= ~IFF_DETACH_QUEUE;
+
 		ret = 0;
 		if ((u & ~TAP_IFFEATURES) != (IFF_NO_PI | IFF_TAP))
 			ret = -EINVAL;
@@ -950,6 +953,8 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
 
 		ret = 0;
 		u = q->flags;
+		if (!q->enabled)
+			u |= IFF_DETACH_QUEUE;
 		if (copy_to_user(&ifr->ifr_name, tap->dev->name, IFNAMSIZ) ||
 		    put_user(u, &ifr->ifr_flags))
 			ret = -EFAULT;

base-commit: cfb7793d1bc0f7d90571611979654cf1b3886b29
-- 
2.53.0