| Message ID | 20220916234552.3388360-1-prohr@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | tun: support not enabling carrier in TUNSETIFF | expand |
On Fri, Sep 16, 2022 at 4:46 PM Patrick Rohr <prohr@google.com> wrote: > > This change adds support for not enabling carrier during TUNSETIFF > interface creation by specifying the IFF_NO_CARRIER flag. > > Our tests make heavy use of tun interfaces. In some scenarios, the test > process creates the interface but another process brings it up after the > interface is discovered via netlink notification. In that case, it is > not possible to create a tun/tap interface with carrier off without it > racing against the bring up. Immediately setting carrier off via > TUNSETCARRIER is still too late. > > Since ifr_flags is only a short, the value for IFF_DETACH_QUEUE is > reused for IFF_NO_CARRIER. IFF_DETACH_QUEUE has currently no meaning in > TUNSETIFF. > > Signed-off-by: Patrick Rohr <prohr@google.com> > Cc: Maciej Żenczykowski <maze@google.com> > Cc: Lorenzo Colitti <lorenzo@google.com> > Cc: Jason Wang <jasowang@redhat.com> > --- > drivers/net/tun.c | 15 ++++++++++++--- > include/uapi/linux/if_tun.h | 2 ++ > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 259b2b84b2b3..502f56095650 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -2709,6 +2709,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) > struct net_device *dev; > int err; > > + /* Do not save the IFF_NO_CARRIER flag as it uses the same value as > + * IFF_DETACH_QUEUE. > + */ > + bool no_carrier = ifr->ifr_flags & IFF_NO_CARRIER; > + ifr->ifr_flags &= ~IFF_NO_CARRIER; > + > if (tfile->detached) > return -EINVAL; > > @@ -2828,7 +2834,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) > rcu_assign_pointer(tfile->tun, tun); > } > > - netif_carrier_on(tun->dev); > + if (no_carrier) > + netif_carrier_off(tun->dev); > + else > + netif_carrier_on(tun->dev); > > /* Make sure persistent devices do not get stuck in > * xoff state. > @@ -3056,8 +3065,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd, > * This is needed because we never checked for invalid flags on > * TUNSETIFF. > */ > - return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES, > - (unsigned int __user*)argp); > + return put_user(IFF_TUN | IFF_TAP | IFF_NO_CARRIER | > + TUN_FEATURES, (unsigned int __user*)argp); > } else if (cmd == TUNSETQUEUE) { > return tun_set_queue(file, &ifr); > } else if (cmd == SIOCGSKNS) { > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h > index 2ec07de1d73b..12dde91957a5 100644 > --- a/include/uapi/linux/if_tun.h > +++ b/include/uapi/linux/if_tun.h > @@ -75,6 +75,8 @@ > #define IFF_MULTI_QUEUE 0x0100 > #define IFF_ATTACH_QUEUE 0x0200 > #define IFF_DETACH_QUEUE 0x0400 > +/* Used in TUNSETIFF to bring up tun/tap without carrier */ > +#define IFF_NO_CARRIER IFF_DETACH_QUEUE > /* read-only flag */ > #define IFF_PERSIST 0x0800 > #define IFF_NOFILTER 0x1000 > -- > 2.37.3.968.ga6b4b080e4-goog Reviewed-by: Maciej Żenczykowski <maze@google.com>
On Sat, Sep 17, 2022 at 7:46 AM Patrick Rohr <prohr@google.com> wrote: > > This change adds support for not enabling carrier during TUNSETIFF > interface creation by specifying the IFF_NO_CARRIER flag. > > Our tests make heavy use of tun interfaces. In some scenarios, the test > process creates the interface but another process brings it up after the > interface is discovered via netlink notification. In that case, it is > not possible to create a tun/tap interface with carrier off without it > racing against the bring up. Immediately setting carrier off via > TUNSETCARRIER is still too late. > > Since ifr_flags is only a short, the value for IFF_DETACH_QUEUE is > reused for IFF_NO_CARRIER. IFF_DETACH_QUEUE has currently no meaning in > TUNSETIFF. > > Signed-off-by: Patrick Rohr <prohr@google.com> > Cc: Maciej Żenczykowski <maze@google.com> > Cc: Lorenzo Colitti <lorenzo@google.com> > Cc: Jason Wang <jasowang@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> > --- > drivers/net/tun.c | 15 ++++++++++++--- > include/uapi/linux/if_tun.h | 2 ++ > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 259b2b84b2b3..502f56095650 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -2709,6 +2709,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) > struct net_device *dev; > int err; > > + /* Do not save the IFF_NO_CARRIER flag as it uses the same value as > + * IFF_DETACH_QUEUE. > + */ > + bool no_carrier = ifr->ifr_flags & IFF_NO_CARRIER; > + ifr->ifr_flags &= ~IFF_NO_CARRIER; > + > if (tfile->detached) > return -EINVAL; > > @@ -2828,7 +2834,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) > rcu_assign_pointer(tfile->tun, tun); > } > > - netif_carrier_on(tun->dev); > + if (no_carrier) > + netif_carrier_off(tun->dev); > + else > + netif_carrier_on(tun->dev); > > /* Make sure persistent devices do not get stuck in > * xoff state. > @@ -3056,8 +3065,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd, > * This is needed because we never checked for invalid flags on > * TUNSETIFF. > */ > - return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES, > - (unsigned int __user*)argp); > + return put_user(IFF_TUN | IFF_TAP | IFF_NO_CARRIER | > + TUN_FEATURES, (unsigned int __user*)argp); > } else if (cmd == TUNSETQUEUE) { > return tun_set_queue(file, &ifr); > } else if (cmd == SIOCGSKNS) { > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h > index 2ec07de1d73b..12dde91957a5 100644 > --- a/include/uapi/linux/if_tun.h > +++ b/include/uapi/linux/if_tun.h > @@ -75,6 +75,8 @@ > #define IFF_MULTI_QUEUE 0x0100 > #define IFF_ATTACH_QUEUE 0x0200 > #define IFF_DETACH_QUEUE 0x0400 > +/* Used in TUNSETIFF to bring up tun/tap without carrier */ > +#define IFF_NO_CARRIER IFF_DETACH_QUEUE > /* read-only flag */ > #define IFF_PERSIST 0x0800 > #define IFF_NOFILTER 0x1000 > -- > 2.37.3.968.ga6b4b080e4-goog >
On Fri, 16 Sep 2022 16:45:52 -0700 Patrick Rohr <prohr@google.com> wrote: > diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h > index 2ec07de1d73b..12dde91957a5 100644 > --- a/include/uapi/linux/if_tun.h > +++ b/include/uapi/linux/if_tun.h > @@ -75,6 +75,8 @@ > #define IFF_MULTI_QUEUE 0x0100 > #define IFF_ATTACH_QUEUE 0x0200 > #define IFF_DETACH_QUEUE 0x0400 > +/* Used in TUNSETIFF to bring up tun/tap without carrier */ > +#define IFF_NO_CARRIER IFF_DETACH_QUEUE Overloading a flag in existing user API is likely to break some application somewhere...
On Mon, Sep 19, 2022 at 10:18 AM Stephen Hemminger <stephen@networkplumber.org> wrote: > On Fri, 16 Sep 2022 16:45:52 -0700 > Patrick Rohr <prohr@google.com> wrote: > > #define IFF_DETACH_QUEUE 0x0400 > > +/* Used in TUNSETIFF to bring up tun/tap without carrier */ > > +#define IFF_NO_CARRIER IFF_DETACH_QUEUE > > Overloading a flag in existing user API is likely to break > some application somewhere... We could of course burn a bit (0x0040 and 0x0080 are both currently utterly unused)... but that just seemed wasteful... Do you think that would be better? I find it exceedingly unlikely that any application is specifying this flag to TUNSETIFF currently. This flag has barely any hits in the code base, indeed ignoring the Documentation, tests, and #define's we have: $ git grep IFF_DETACH_QUEUE drivers/net/tap.c:928: else if (flags & IFF_DETACH_QUEUE) drivers/net/tun.c:2954: } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) { drivers/net/tun.c:3115: ifr.ifr_flags |= IFF_DETACH_QUEUE; The first two implement ioctl(TUNSETQUEUE) -- that's the only spot where IFF_DETACH_QUEUE is currently supposed to be used. The third one is the most interesting, see drivers/net/tun.c:3111 case TUNGETIFF: tun_get_iff(tun, &ifr); if (tfile->detached) ifr.ifr_flags |= IFF_DETACH_QUEUE; if (!tfile->socket.sk->sk_filter) ifr.ifr_flags |= IFF_NOFILTER; This means TUNGETIFF can return this flag for a detached queue. However: (a) multiqueue tun/tap is pretty niche, and detached queues are even more niche. (b) the TUNGETIFF returned ifr_flags field already cannot be safely used as input to TUNSETIFF, because IFF_NOFILTER == IFF_NO_PI == 0x1000 (this overlap of IFF_NO_PI and IFF_NOFILTER is why we thought it'd be ok to overlap here as well) (c) if this actually turns out to be a problem it shouldn't be that hard to fix the 1 or 2 userspace programs to mask out the flag and not pass in garbage... Do we really want / need to maintain compatibility with extremely badly written userspace? It's really hard to even imagine how such code would come into existence... Arguably the TUNSETIFF api should have always returned an error for invalid flags... should we make that change now?
On Tue, Sep 20, 2022 at 8:01 AM Maciej Żenczykowski <maze@google.com> wrote: > > On Mon, Sep 19, 2022 at 10:18 AM Stephen Hemminger > <stephen@networkplumber.org> wrote: > > On Fri, 16 Sep 2022 16:45:52 -0700 > > Patrick Rohr <prohr@google.com> wrote: > > > #define IFF_DETACH_QUEUE 0x0400 > > > +/* Used in TUNSETIFF to bring up tun/tap without carrier */ > > > +#define IFF_NO_CARRIER IFF_DETACH_QUEUE > > > > Overloading a flag in existing user API is likely to break > > some application somewhere... > > We could of course burn a bit (0x0040 and 0x0080 are both currently > utterly unused)... but that just seemed wasteful... > Do you think that would be better? > > I find it exceedingly unlikely that any application is specifying this > flag to TUNSETIFF currently. > > This flag has barely any hits in the code base, indeed ignoring the > Documentation, tests, and #define's we have: > > $ git grep IFF_DETACH_QUEUE > drivers/net/tap.c:928: else if (flags & IFF_DETACH_QUEUE) > drivers/net/tun.c:2954: } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) { > drivers/net/tun.c:3115: ifr.ifr_flags |= IFF_DETACH_QUEUE; > > The first two implement ioctl(TUNSETQUEUE) -- that's the only spot > where IFF_DETACH_QUEUE is currently supposed to be used. > > The third one is the most interesting, see drivers/net/tun.c:3111 > > case TUNGETIFF: > tun_get_iff(tun, &ifr); > if (tfile->detached) > ifr.ifr_flags |= IFF_DETACH_QUEUE; > if (!tfile->socket.sk->sk_filter) > ifr.ifr_flags |= IFF_NOFILTER; > > This means TUNGETIFF can return this flag for a detached queue. However: > > (a) multiqueue tun/tap is pretty niche, and detached queues are even more niche. > > (b) the TUNGETIFF returned ifr_flags field already cannot be safely > used as input to TUNSETIFF, Yes, but it could be used by userspace to recover the multiqueue state via TUNSETQUEUE for a feature like checkpoint. > because IFF_NOFILTER == IFF_NO_PI == > 0x1000 > > (this overlap of IFF_NO_PI and IFF_NOFILTER is why we thought it'd be > ok to overlap here as well) > > (c) if this actually turns out to be a problem it shouldn't be that > hard to fix the 1 or 2 userspace programs to mask out the flag > and not pass in garbage... Do we really want / need to maintain > compatibility with extremely badly written userspace? Not sure, but instead of trying to answer this hard question, having a new flag seems to be easier. > It's really hard to even imagine how such code would come into existence... > > Arguably the TUNSETIFF api should have always returned an error for > invalid flags... should we make that change now? Probably too late to do that. Thanks >
Le 17/09/2022 à 01:45, Patrick Rohr a écrit : > This change adds support for not enabling carrier during TUNSETIFF > interface creation by specifying the IFF_NO_CARRIER flag. > > Our tests make heavy use of tun interfaces. In some scenarios, the test > process creates the interface but another process brings it up after the > interface is discovered via netlink notification. In that case, it is > not possible to create a tun/tap interface with carrier off without it > racing against the bring up. Immediately setting carrier off via > TUNSETCARRIER is still too late. > > Since ifr_flags is only a short, the value for IFF_DETACH_QUEUE is > reused for IFF_NO_CARRIER. IFF_DETACH_QUEUE has currently no meaning in > TUNSETIFF. > > Signed-off-by: Patrick Rohr <prohr@google.com> > Cc: Maciej Żenczykowski <maze@google.com> > Cc: Lorenzo Colitti <lorenzo@google.com> > Cc: Jason Wang <jasowang@redhat.com> > --- > drivers/net/tun.c | 15 ++++++++++++--- > include/uapi/linux/if_tun.h | 2 ++ > 2 files changed, 14 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 259b2b84b2b3..502f56095650 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -2709,6 +2709,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) > struct net_device *dev; > int err; > > + /* Do not save the IFF_NO_CARRIER flag as it uses the same value as > + * IFF_DETACH_QUEUE. > + */ > + bool no_carrier = ifr->ifr_flags & IFF_NO_CARRIER; nit: please, declare all variables at the beginning and use reverse x-mas tree.
On Tue, 20 Sep 2022 09:44:45 +0800 Jason Wang <jasowang@redhat.com> wrote: > On Tue, Sep 20, 2022 at 8:01 AM Maciej Żenczykowski <maze@google.com> wrote: > > > > On Mon, Sep 19, 2022 at 10:18 AM Stephen Hemminger > > <stephen@networkplumber.org> wrote: > > > On Fri, 16 Sep 2022 16:45:52 -0700 > > > Patrick Rohr <prohr@google.com> wrote: > > > > #define IFF_DETACH_QUEUE 0x0400 > > > > +/* Used in TUNSETIFF to bring up tun/tap without carrier */ > > > > +#define IFF_NO_CARRIER IFF_DETACH_QUEUE > > > > > > Overloading a flag in existing user API is likely to break > > > some application somewhere... > > > > We could of course burn a bit (0x0040 and 0x0080 are both currently > > utterly unused)... but that just seemed wasteful... > > Do you think that would be better? > > > > I find it exceedingly unlikely that any application is specifying this > > flag to TUNSETIFF currently. > > > > This flag has barely any hits in the code base, indeed ignoring the > > Documentation, tests, and #define's we have: > > > > $ git grep IFF_DETACH_QUEUE > > drivers/net/tap.c:928: else if (flags & IFF_DETACH_QUEUE) > > drivers/net/tun.c:2954: } else if (ifr->ifr_flags & IFF_DETACH_QUEUE) { > > drivers/net/tun.c:3115: ifr.ifr_flags |= IFF_DETACH_QUEUE; > > > > The first two implement ioctl(TUNSETQUEUE) -- that's the only spot > > where IFF_DETACH_QUEUE is currently supposed to be used. > > > > The third one is the most interesting, see drivers/net/tun.c:3111 > > > > case TUNGETIFF: > > tun_get_iff(tun, &ifr); > > if (tfile->detached) > > ifr.ifr_flags |= IFF_DETACH_QUEUE; > > if (!tfile->socket.sk->sk_filter) > > ifr.ifr_flags |= IFF_NOFILTER; > > > > This means TUNGETIFF can return this flag for a detached queue. However: > > > > (a) multiqueue tun/tap is pretty niche, and detached queues are even more niche. > > > > (b) the TUNGETIFF returned ifr_flags field already cannot be safely > > used as input to TUNSETIFF, > > Yes, but it could be used by userspace to recover the multiqueue state > via TUNSETQUEUE for a feature like checkpoint. > > > because IFF_NOFILTER == IFF_NO_PI == > > 0x1000 > > > > (this overlap of IFF_NO_PI and IFF_NOFILTER is why we thought it'd be > > ok to overlap here as well) > > > > (c) if this actually turns out to be a problem it shouldn't be that > > hard to fix the 1 or 2 userspace programs to mask out the flag > > and not pass in garbage... Do we really want / need to maintain > > compatibility with extremely badly written userspace? > > Not sure, but instead of trying to answer this hard question, having a > new flag seems to be easier. > > > It's really hard to even imagine how such code would come into existence... > > > > Arguably the TUNSETIFF api should have always returned an error for > > invalid flags... should we make that change now? > > Probably too late to do that. There have been several other cases where Linus has said ABI compatability includes not breaking buggy userspace applications. Look at the history around new syscalls that add a flag argument and forget to check that it is zero in the first version.
Greeting,
FYI, we noticed the following commit (built with gcc-11):
commit: a4d8f18ebc10db0fa858ab63c115c42032694bee ("[PATCH] tun: support not enabling carrier in TUNSETIFF")
url: https://github.com/intel-lab-lkp/linux/commits/Patrick-Rohr/tun-support-not-enabling-carrier-in-TUNSETIFF/20220917-074802
base: https://git.kernel.org/cgit/linux/kernel/git/mst/vhost.git linux-next
patch link: https://lore.kernel.org/netdev/20220916234552.3388360-1-prohr@google.com
in testcase: ltp
version: ltp-x86_64-14c1f76-1_20220829
with following parameters:
disk: 1HDD
fs: btrfs
test: syscalls-03
test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
test-url: http://linux-test-project.github.io/
on test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Link: https://lore.kernel.org/r/202209211425.14116dd2-oliver.sang@intel.com
<<<test_start>>>
tag=ioctl03 stime=1663640405
cmdline="ioctl03"
contacts=""
analysis=exit
<<<test_output>>>
tst_test.c:1526: TINFO: Timeout per run is 0h 02m 30s
ioctl03.c:76: TINFO: Available features are: 0x7533
ioctl03.c:80: TPASS: TUN 0x1
ioctl03.c:80: TPASS: TAP 0x2
ioctl03.c:80: TPASS: NO_PI 0x1000
ioctl03.c:80: TPASS: ONE_QUEUE 0x2000
ioctl03.c:80: TPASS: VNET_HDR 0x4000
ioctl03.c:80: TPASS: MULTI_QUEUE 0x100
ioctl03.c:80: TPASS: IFF_NAPI 0x10
ioctl03.c:80: TPASS: IFF_NAPI_FRAGS 0x20
ioctl03.c:85: TFAIL: (UNKNOWN 0x400)
Summary:
passed 8
failed 1
broken 0
skipped 0
warnings 0
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
sudo bin/lkp install job.yaml # job file is attached in this email
bin/lkp split-job --compatible job.yaml # generate the yaml file for lkp run
sudo bin/lkp run generated-yaml-file
# if come across any failure that blocks the test,
# please remove ~/.lkp and /lkp dir to run from a clean state.
Hi! > tag=ioctl03 stime=1663640405 > cmdline="ioctl03" > contacts="" > analysis=exit > <<<test_output>>> > tst_test.c:1526: TINFO: Timeout per run is 0h 02m 30s > ioctl03.c:76: TINFO: Available features are: 0x7533 > ioctl03.c:80: TPASS: TUN 0x1 > ioctl03.c:80: TPASS: TAP 0x2 > ioctl03.c:80: TPASS: NO_PI 0x1000 > ioctl03.c:80: TPASS: ONE_QUEUE 0x2000 > ioctl03.c:80: TPASS: VNET_HDR 0x4000 > ioctl03.c:80: TPASS: MULTI_QUEUE 0x100 > ioctl03.c:80: TPASS: IFF_NAPI 0x10 > ioctl03.c:80: TPASS: IFF_NAPI_FRAGS 0x20 > ioctl03.c:85: TFAIL: (UNKNOWN 0x400) Obviously the test fails since new flag has been advertised. The test will have to be updated once/if this commit hits mainline.
diff --git a/drivers/net/tun.c b/drivers/net/tun.c index 259b2b84b2b3..502f56095650 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -2709,6 +2709,12 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) struct net_device *dev; int err; + /* Do not save the IFF_NO_CARRIER flag as it uses the same value as + * IFF_DETACH_QUEUE. + */ + bool no_carrier = ifr->ifr_flags & IFF_NO_CARRIER; + ifr->ifr_flags &= ~IFF_NO_CARRIER; + if (tfile->detached) return -EINVAL; @@ -2828,7 +2834,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) rcu_assign_pointer(tfile->tun, tun); } - netif_carrier_on(tun->dev); + if (no_carrier) + netif_carrier_off(tun->dev); + else + netif_carrier_on(tun->dev); /* Make sure persistent devices do not get stuck in * xoff state. @@ -3056,8 +3065,8 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd, * This is needed because we never checked for invalid flags on * TUNSETIFF. */ - return put_user(IFF_TUN | IFF_TAP | TUN_FEATURES, - (unsigned int __user*)argp); + return put_user(IFF_TUN | IFF_TAP | IFF_NO_CARRIER | + TUN_FEATURES, (unsigned int __user*)argp); } else if (cmd == TUNSETQUEUE) { return tun_set_queue(file, &ifr); } else if (cmd == SIOCGSKNS) { diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h index 2ec07de1d73b..12dde91957a5 100644 --- a/include/uapi/linux/if_tun.h +++ b/include/uapi/linux/if_tun.h @@ -75,6 +75,8 @@ #define IFF_MULTI_QUEUE 0x0100 #define IFF_ATTACH_QUEUE 0x0200 #define IFF_DETACH_QUEUE 0x0400 +/* Used in TUNSETIFF to bring up tun/tap without carrier */ +#define IFF_NO_CARRIER IFF_DETACH_QUEUE /* read-only flag */ #define IFF_PERSIST 0x0800 #define IFF_NOFILTER 0x1000
This change adds support for not enabling carrier during TUNSETIFF interface creation by specifying the IFF_NO_CARRIER flag. Our tests make heavy use of tun interfaces. In some scenarios, the test process creates the interface but another process brings it up after the interface is discovered via netlink notification. In that case, it is not possible to create a tun/tap interface with carrier off without it racing against the bring up. Immediately setting carrier off via TUNSETCARRIER is still too late. Since ifr_flags is only a short, the value for IFF_DETACH_QUEUE is reused for IFF_NO_CARRIER. IFF_DETACH_QUEUE has currently no meaning in TUNSETIFF. Signed-off-by: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Cc: Jason Wang <jasowang@redhat.com> --- drivers/net/tun.c | 15 ++++++++++++--- include/uapi/linux/if_tun.h | 2 ++ 2 files changed, 14 insertions(+), 3 deletions(-)