* [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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.