| 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
| ||
|
Message-Id: <1196912898.14754.13.camel@concordia>
Date: Thu, 06 Dec 2007 14:48:18 +1100
From: Michael Ellerman <michael@...erman.id.au>
To: Greg KH <greg@...ah.com>
Cc: "Kyle A. Lucke" <klucke@...ibm.com>,
David Gibson <dwg@....ibm.com>, linuxppc-dev@...abs.org,
paulus@...ba.org, linux-kernel@...r.kernel.org
Subject: Re: drivers/net/iseries_veth.c dubious sysfs usage
On Wed, 2007-12-05 at 13:41 -0800, Greg KH wrote:
> On Wed, Dec 05, 2007 at 10:10:31PM +1100, Michael Ellerman wrote:
> > On Wed, 2007-12-05 at 01:30 -0800, Greg KH wrote:
> > > In doing a massive kobject cleanup of the kernel tree, I ran across the
> > > iseries_veth.c driver.
> > >
> > > It looks like the driver is creating a number of subdirectories under
> > > the driver sysfs directory. This is odd and probably wrong. You want
> > > these virtual connections to show up in the main sysfs device tree, not
> > > under the driver directory.
> > >
> > > I'll be glad to totally guess and try to move it around in the sysfs
> > > tree, but odds are I'll get it all wrong as I can't really test this
> > > out :)
> > >
> > > Any hints on what this driver is trying to do in this sysfs directories?
> >
> > I wrote the code, I think, but it's been a while - I'll have a look at
> > it tomorrow.
>
> Yes, can you send me the sysfs tree output of the driver directory, and
> what exactly the different files in there are supposed to be used for?
Sure. My version of tar (1.15.1) doesn't seem to be able to tar up /sys,
so hopefully this is sufficient:
igoeast:~# cd /sys/class/net/eth1/
igoeast:/sys/class/net/eth1# ls -la
total 0
drwxr-xr-x 4 root root 0 Dec 6 10:22 .
drwxr-xr-x 6 root root 0 Dec 6 10:21 ..
-r--r--r-- 1 root root 4096 Dec 6 10:30 addr_len
-r--r--r-- 1 root root 4096 Dec 6 10:30 address
-r--r--r-- 1 root root 4096 Dec 6 10:30 broadcast
-r--r--r-- 1 root root 4096 Dec 6 10:30 carrier
lrwxrwxrwx 1 root root 0 Dec 6 10:22 device -> ../../../devices/vio/3
-r--r--r-- 1 root root 4096 Dec 6 10:30 dormant
-r--r--r-- 1 root root 4096 Dec 6 10:30 features
-rw-r--r-- 1 root root 4096 Dec 6 10:30 flags
-r--r--r-- 1 root root 4096 Dec 6 10:30 ifindex
-r--r--r-- 1 root root 4096 Dec 6 10:30 iflink
-r--r--r-- 1 root root 4096 Dec 6 10:30 link_mode
-rw-r--r-- 1 root root 4096 Dec 6 10:30 mtu
-r--r--r-- 1 root root 4096 Dec 6 10:30 operstate
drwxr-xr-x 2 root root 0 Dec 6 10:30 statistics
lrwxrwxrwx 1 root root 0 Dec 6 10:30 subsystem -> ../../../class/net
-rw-r--r-- 1 root root 4096 Dec 6 10:30 tx_queue_len
-r--r--r-- 1 root root 4096 Dec 6 10:30 type
-rw-r--r-- 1 root root 4096 Dec 6 10:30 uevent
drwxr-xr-x 2 root root 0 Dec 6 10:30 veth_port
Each net device has a port structure associated with it, the fields
should be fairly self explanatory, they're all read only I think.
igoeast:/sys/class/net/eth1# find veth_port/
veth_port/
veth_port/mac_addr
veth_port/lpar_map
veth_port/stopped_map
veth_port/promiscuous
veth_port/num_mcast
igoeast:/sys/class/net/eth1# cd device/driver
igoeast:/sys/class/net/eth1/device/driver# ls -l
total 0
lrwxrwxrwx 1 root root 0 Dec 6 10:21 2 -> ../../../../devices/vio/2
lrwxrwxrwx 1 root root 0 Dec 6 10:21 3 -> ../../../../devices/vio/3
--w------- 1 root root 4096 Dec 6 10:21 bind
drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx00
drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx02
drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx03
drwxr-xr-x 2 root root 0 Dec 6 10:21 cnx04
lrwxrwxrwx 1 root root 0 Dec 6 10:21 module -> ../../../../module/iseries_veth
--w------- 1 root root 4096 Dec 6 10:21 uevent
--w------- 1 root root 4096 Dec 6 10:21 unbind
The driver has a connection to all the other lpars, this is entirely
independent of the net devices.
igoeast:/sys/class/net/eth1/device/driver# find cnx00/
cnx00/
cnx00/outstanding_tx
cnx00/remote_lp
cnx00/num_events
cnx00/reset_timeout
cnx00/last_contact
cnx00/state
cnx00/src_inst
cnx00/dst_inst
cnx00/num_pending_acks
cnx00/num_ack_events
cnx00/ack_timeout
> > Why is it "odd and probably wrong" to create subdirectories under the
> > driver in sysfs?
>
> Because a driver does not have "devices" under it in the sysfs tree.
> All devices liven in the /sys/devices/ tree so we can properly manage
> them that way. A driver will then bind to a device, and the driver core
> will set up the linkages in sysfs properly so that everthing looks
> uniform.
OK. They're not "devices" that we create under the driver, they're just
attributes of the driver, and they happen to be in groups so I put them
in subdirectories.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists