lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 22 Apr 2013 23:59:57 -0700 From: Jerry Chu <hkchu@...gle.com> To: Jason Wang <jasowang@...hat.com> Cc: Wei Yongjun <weiyj.lk@...il.com>, David Miller <davem@...emloft.net>, mst@...hat.com, Eric Dumazet <edumazet@...gle.com>, nhorman@...driver.com, yongjun_wei@...ndmicro.com.cn, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Subject: Re: [PATCH] tuntap: fix error return code in tun_set_iff() On Mon, Apr 22, 2013 at 11:19 PM, Jason Wang <jasowang@...hat.com> wrote: > > On 04/23/2013 01:37 PM, Jerry Chu wrote: > > On Fri, Apr 12, 2013 at 6:17 AM, Wei Yongjun <weiyj.lk@...il.com> wrote: > >> From: Wei Yongjun <yongjun_wei@...ndmicro.com.cn> > >> > >> Fix to return a negative error code from the error handling > >> case instead of 0, as returned elsewhere in this function. > >> > >> Signed-off-by: Wei Yongjun <yongjun_wei@...ndmicro.com.cn> > >> --- > >> drivers/net/tun.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/tun.c b/drivers/net/tun.c > >> index b7c457a..729ed53 100644 > >> --- a/drivers/net/tun.c > >> +++ b/drivers/net/tun.c > >> @@ -1594,7 +1594,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) > >> > >> if (tun->flags & TUN_TAP_MQ && > >> (tun->numqueues + tun->numdisabled > 1)) > >> - return err; > >> + return -EBUSY; > > I don't understand - yes it was a brainless bug to return err without > > setting it! > > err was in fact set by tun_attach, so it was always zero here. The code > works by chance w/o this patch :) What if tun_attach() returns something > 0? > > But won't the fix pretty much disable multi-q because only the the creation of > > the 1st queue will succeed? I thought the intent of "tuntap: fix ambigious > > multiqueue API" was to "Only allow TUNSETIFF to create queues.". > > Yes this patch will break the creation of more than 1 queues. > > > > The code is very confusing. (Or am I the one who is confused? Sigh.) > > -EBUSY is wrong here, we need return 0 for succeed here. The logic is, > if we have more than 1 queues attached, no need to re-initialize the net > device again. Will send patch to correct this. A comment there will be useful! Thanks, Jerry > > Thanks. > > > > > Jerry > > > >> } > >> else { > >> char *name; > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe netdev" in > >> the body of a message to majordomo@...r.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe netdev" in > > the body of a message to majordomo@...r.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists