* [BUG iproute2] ip tuntap show
@ 2018-01-31 16:58 Eric Dumazet
2018-01-31 17:21 ` Serhey Popovych
0 siblings, 1 reply; 7+ messages in thread
From: Eric Dumazet @ 2018-01-31 16:58 UTC (permalink / raw)
To: Stephen Hemminger, David Ahern; +Cc: netdev, Maciej Żenczykowski
ip tuntap enumerates devices using /sys/class/net which is unusual.
Should we replace this enumeration using /proc/net/dev like "ip tunnel" ?
After "unshare -n" maybe mounting /sys should not be required for
proper iproute2 behavior.
At least ip command should adopt a common enumeration method.
What do you think ?
Thanks.
lpaa5:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
adp0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
uinput4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
dynencap4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
sixtofour0: 696886 6733 0 0 0 0 0 0 480743 4445 0 0 0 0 0 0
uinput6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
gretap0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ip6gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tunl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ip6tnl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
sixdecap0: 0 0 0 0 0 0 0 0 559849 2371 0 0 0 0 0 0
lo: 80924524 222675 0 0 0 0 0 0 80924524 222675 0 0 0 0 0 0
eth2: 8898473491 131730002 0 0 0 0 0 89 8606929352 128406009 0 0 0 0 0 0
dynencap6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
eth1: 9219322658 137558705 0 0 0 0 0 1592 9438658576 140822798 0 0 0 0 0 0
eth0: 18117796393 269288710 0 0 0 0 0 1682 18045588486 269228813 0 3 0 0 0 0
lpaa5:~# unshare -n
lpaa5:~# cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
lpaa5:~# ip tuntap
adp0: tap vnet_hdr UNKNOWN_FLAGS:940
lpaa5:~# mount -t sysfs sysfs /sys
lpaa5:~# ip tuntap
lpaa5:~# ls -l /sys/class/net
total 0
-rw-r--r-- 1 root root 4096 Jan 31 08:51 bonding_masters
lrwxrwxrwx 1 root root 0 Jan 31 08:51 lo -> ../../devices/virtual/net/lo
lpaa5:~#
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG iproute2] ip tuntap show
2018-01-31 16:58 [BUG iproute2] ip tuntap show Eric Dumazet
@ 2018-01-31 17:21 ` Serhey Popovych
2018-01-31 17:40 ` David Ahern
0 siblings, 1 reply; 7+ messages in thread
From: Serhey Popovych @ 2018-01-31 17:21 UTC (permalink / raw)
To: Eric Dumazet, Stephen Hemminger, David Ahern
Cc: netdev, Maciej Żenczykowski
[-- Attachment #1.1: Type: text/plain, Size: 4000 bytes --]
Eric Dumazet wrote:
> ip tuntap enumerates devices using /sys/class/net which is unusual.
>
> Should we replace this enumeration using /proc/net/dev like "ip tunnel" ?
>
> After "unshare -n" maybe mounting /sys should not be required for
> proper iproute2 behavior.
>
> At least ip command should adopt a common enumeration method.
>
> What do you think ?
It seems main reason for using /sys/class/net is to get additional
information for netdev like "owner", "group" and "tun_flags".
On the other hand at least iptunnel and ip6tunnel uses nearly identical
code to parse /proc/net/dev.
Having single routine that reads /proc/net/dev and calls implementation
specific callback function with given network device name is good idea.
I can try to prepare v1 for this, if no one objects this.
>
> Thanks.
>
> lpaa5:~# cat /proc/net/dev
> Inter-| Receive | Transmit
> face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
> adp0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> uinput4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> dynencap4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> sixtofour0: 696886 6733 0 0 0 0 0 0 480743 4445 0 0 0 0 0 0
> uinput6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> gretap0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ip6gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> tunl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> ip6tnl0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> gre0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> sit0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> sixdecap0: 0 0 0 0 0 0 0 0 559849 2371 0 0 0 0 0 0
> lo: 80924524 222675 0 0 0 0 0 0 80924524 222675 0 0 0 0 0 0
> eth2: 8898473491 131730002 0 0 0 0 0 89 8606929352 128406009 0 0 0 0 0 0
> dynencap6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> eth1: 9219322658 137558705 0 0 0 0 0 1592 9438658576 140822798 0 0 0 0 0 0
> eth0: 18117796393 269288710 0 0 0 0 0 1682 18045588486 269228813 0 3 0 0 0 0
>
> lpaa5:~# unshare -n
>
> lpaa5:~# cat /proc/net/dev
> Inter-| Receive | Transmit
> face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
> lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> lpaa5:~# ip tuntap
> adp0: tap vnet_hdr UNKNOWN_FLAGS:940
>
> lpaa5:~# mount -t sysfs sysfs /sys
>
> lpaa5:~# ip tuntap
>
> lpaa5:~# ls -l /sys/class/net
> total 0
> -rw-r--r-- 1 root root 4096 Jan 31 08:51 bonding_masters
> lrwxrwxrwx 1 root root 0 Jan 31 08:51 lo -> ../../devices/virtual/net/lo
> lpaa5:~#
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG iproute2] ip tuntap show
2018-01-31 17:21 ` Serhey Popovych
@ 2018-01-31 17:40 ` David Ahern
2018-01-31 17:43 ` Serhey Popovych
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: David Ahern @ 2018-01-31 17:40 UTC (permalink / raw)
To: Serhey Popovych, Eric Dumazet, Stephen Hemminger
Cc: netdev, Maciej Żenczykowski
On 1/31/18 10:21 AM, Serhey Popovych wrote:
> Eric Dumazet wrote:
>> ip tuntap enumerates devices using /sys/class/net which is unusual.
>>
>> Should we replace this enumeration using /proc/net/dev like "ip tunnel" ?
>>
>> After "unshare -n" maybe mounting /sys should not be required for
>> proper iproute2 behavior.
>>
>> At least ip command should adopt a common enumeration method.
>>
>> What do you think ?
>
> It seems main reason for using /sys/class/net is to get additional
> information for netdev like "owner", "group" and "tun_flags".
>
> On the other hand at least iptunnel and ip6tunnel uses nearly identical
> code to parse /proc/net/dev.
>
> Having single routine that reads /proc/net/dev and calls implementation
> specific callback function with given network device name is good idea.
>
> I can try to prepare v1 for this, if no one objects this.
>
pid_name function needs help too. comm is allocated via sprintf, freed,
and used again and then returned to caller.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG iproute2] ip tuntap show
2018-01-31 17:40 ` David Ahern
@ 2018-01-31 17:43 ` Serhey Popovych
2018-01-31 19:51 ` Serhey Popovych
2018-02-05 15:34 ` Serhey Popovych
2 siblings, 0 replies; 7+ messages in thread
From: Serhey Popovych @ 2018-01-31 17:43 UTC (permalink / raw)
To: David Ahern, Eric Dumazet, Stephen Hemminger
Cc: netdev, Maciej Żenczykowski
[-- Attachment #1.1: Type: text/plain, Size: 1121 bytes --]
David Ahern wrote:
> On 1/31/18 10:21 AM, Serhey Popovych wrote:
>> Eric Dumazet wrote:
>>> ip tuntap enumerates devices using /sys/class/net which is unusual.
>>>
>>> Should we replace this enumeration using /proc/net/dev like "ip tunnel" ?
>>>
>>> After "unshare -n" maybe mounting /sys should not be required for
>>> proper iproute2 behavior.
>>>
>>> At least ip command should adopt a common enumeration method.
>>>
>>> What do you think ?
>>
>> It seems main reason for using /sys/class/net is to get additional
>> information for netdev like "owner", "group" and "tun_flags".
>>
>> On the other hand at least iptunnel and ip6tunnel uses nearly identical
>> code to parse /proc/net/dev.
>>
>> Having single routine that reads /proc/net/dev and calls implementation
>> specific callback function with given network device name is good idea.
>>
>> I can try to prepare v1 for this, if no one objects this.
>>
>
> pid_name function needs help too. comm is allocated via sprintf, freed,
> and used again and then returned to caller.
>
Nice :-) will fix that too. Thanks for pointing.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG iproute2] ip tuntap show
2018-01-31 17:40 ` David Ahern
2018-01-31 17:43 ` Serhey Popovych
@ 2018-01-31 19:51 ` Serhey Popovych
2018-02-05 15:34 ` Serhey Popovych
2 siblings, 0 replies; 7+ messages in thread
From: Serhey Popovych @ 2018-01-31 19:51 UTC (permalink / raw)
To: David Ahern, Eric Dumazet, Stephen Hemminger
Cc: netdev, Maciej Żenczykowski
[-- Attachment #1.1: Type: text/plain, Size: 1164 bytes --]
David Ahern wrote:
> On 1/31/18 10:21 AM, Serhey Popovych wrote:
>> Eric Dumazet wrote:
>>> ip tuntap enumerates devices using /sys/class/net which is unusual.
>>>
>>> Should we replace this enumeration using /proc/net/dev like "ip tunnel" ?
>>>
>>> After "unshare -n" maybe mounting /sys should not be required for
>>> proper iproute2 behavior.
>>>
>>> At least ip command should adopt a common enumeration method.
>>>
>>> What do you think ?
>>
>> It seems main reason for using /sys/class/net is to get additional
>> information for netdev like "owner", "group" and "tun_flags".
>>
>> On the other hand at least iptunnel and ip6tunnel uses nearly identical
>> code to parse /proc/net/dev.
>>
>> Having single routine that reads /proc/net/dev and calls implementation
>> specific callback function with given network device name is good idea.
>>
>> I can try to prepare v1 for this, if no one objects this.
>>
>
> pid_name function needs help too. comm is allocated via sprintf, freed,
> and used again and then returned to caller.
>
Posted v1, but without pid_name patch, will prepare and send separately.
Thanks,
Serhii
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG iproute2] ip tuntap show
2018-01-31 17:40 ` David Ahern
2018-01-31 17:43 ` Serhey Popovych
2018-01-31 19:51 ` Serhey Popovych
@ 2018-02-05 15:34 ` Serhey Popovych
2018-02-05 16:25 ` David Ahern
2 siblings, 1 reply; 7+ messages in thread
From: Serhey Popovych @ 2018-02-05 15:34 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Maciej Żenczykowski
[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]
David Ahern wrote:
> On 1/31/18 10:21 AM, Serhey Popovych wrote:
>> Eric Dumazet wrote:
>>> ip tuntap enumerates devices using /sys/class/net which is unusual.
>>>
>>> Should we replace this enumeration using /proc/net/dev like "ip tunnel" ?
>>>
>>> After "unshare -n" maybe mounting /sys should not be required for
>>> proper iproute2 behavior.
>>>
>>> At least ip command should adopt a common enumeration method.
>>>
>>> What do you think ?
>>
>> It seems main reason for using /sys/class/net is to get additional
>> information for netdev like "owner", "group" and "tun_flags".
>>
>> On the other hand at least iptunnel and ip6tunnel uses nearly identical
>> code to parse /proc/net/dev.
>>
>> Having single routine that reads /proc/net/dev and calls implementation
>> specific callback function with given network device name is good idea.
>>
>> I can try to prepare v1 for this, if no one objects this.
>>
>
> pid_name function needs help too. comm is allocated via sprintf, freed,
> and used again and then returned to caller.
>
Sorry David, but I do no see problem with this function right now:
1. It allocates string using malloc() in asprintf()
2. free() it *after* fopen() to prevent memory leak if fopen() fails
3. or if fopen() succeeded and we fscanf() with %ms that will allcate
buffer we return.
I agree this is GNU extensions, but it does not look as user after free
to me. Should I get rid of these extensions? They are not last as I can
find.
Correct if I miss something.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG iproute2] ip tuntap show
2018-02-05 15:34 ` Serhey Popovych
@ 2018-02-05 16:25 ` David Ahern
0 siblings, 0 replies; 7+ messages in thread
From: David Ahern @ 2018-02-05 16:25 UTC (permalink / raw)
To: Serhey Popovych; +Cc: netdev, Maciej Żenczykowski
On 2/5/18 8:34 AM, Serhey Popovych wrote:
> Sorry David, but I do no see problem with this function right now:
>
> 1. It allocates string using malloc() in asprintf()
> 2. free() it *after* fopen() to prevent memory leak if fopen() fails
> 3. or if fopen() succeeded and we fscanf() with %ms that will allcate
> buffer we return.
>
> I agree this is GNU extensions, but it does not look as user after free
> to me. Should I get rid of these extensions? They are not last as I can
> find.
>
ok, I missed the 'm' in the %ms of the fscanf. Thanks for checking.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-02-05 16:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-01-31 16:58 [BUG iproute2] ip tuntap show Eric Dumazet
2018-01-31 17:21 ` Serhey Popovych
2018-01-31 17:40 ` David Ahern
2018-01-31 17:43 ` Serhey Popovych
2018-01-31 19:51 ` Serhey Popovych
2018-02-05 15:34 ` Serhey Popovych
2018-02-05 16:25 ` David Ahern
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).