netdev - Re: [PATCH] tuntap: fix error return code in tun_set

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Apr 2013 14:19:59 +0800
From:	Jason Wang <jasowang@...hat.com>
To:	Jerry Chu <hkchu@...gle.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 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 :)
> 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.

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