25 May, 2011
1 commit
-
libfcoe's interface consists of create, destroy, enable,
disable and create_vn2vn. These are currently module
paramaters added durring the module initialization. A
concern arose that the module parameters were being added
with write permissions before the module had completed
initialization. The following code was added to each
sysfs store file.* Make sure the module has been initialized, and is not about to be
* removed. Module parameter sysfs files are writable before the
* module_init function is called and after module_exit.
*/
if (THIS_MODULE->state != MODULE_STATE_LIVE)
goto out_nodev;This check was called out as unhelpful as the module can
go dead at any time and therefore its state isn't a reliable
thing to look at as a sign of stability and initialization
completion. Also, that functional interfaces like these
should be added after module initialization.This patch removes the unnecessary checks and hopes to
disprove the concern about initialization ordering.Recent fcoe transport rework changes now require fcoe
transports to register with libfcoe before any operation
can take place. libfcoe may access some static variables
but nothing that could cause a problem. Once a fcoe transport
is registered, libfcoe is usable and any interface calls will
be functional.Signed-off-by: Robert Love
Tested-by: Ross Brattain
Signed-off-by: James Bottomley
01 May, 2011
4 commits
-
fix typo of '_attach' -> '_detach' in the comment.
Reported-by: Frank Zhang
Signed-off-by: Yi Zou
Tested-by: Ross Brattain
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
possible buffer overflow in fcoe_transport_show when reaching the end of
buffer and crossing PAGE_SIZE boundary.Signed-off-by: Yi Zou
Signed-off-by: Tomas Henzl
Tested-by: Ross Brattain
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
When rmmoving the underlying fcoe transport driver module by force when
it's attached and in use, the correspoding netdev mapping should be
cleaned up properly as well, otherwise the lookup for a given netdev
for the transport would still return non NULL pointer, causing "unable
to handle paging request" bug.Signed-off-by: Yi Zou
Tested-by: Ross Brattain
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
This code was incorrectly ported from fcoe.c when the
fcoe transport infrastructure was put into place. It
was originally needed in fcoe.c when dealing with
the rtnl mutex. In that code it was only needed to
avoid a lockdep false positive. In libfcoe we don't
deal with the rtnl mutex, we don't get the lockdep
false positive and therefore we don't need these
checks.Signed-off-by: Robert Love
Tested-by: Ross Brattain
Signed-off-by: James Bottomley
01 Mar, 2011
1 commit
-
When L2 driver is unloaded, libfcoe_destroy tries to access the fcoe
transport structure matching the netdev. However, since the netdev is
unregistered by that time, it fails to do so. Hence the stale mappings
exists in the fcoe-netdev list. Handle NETDEV_UREGISTER device
notification mechanism to remove the stale fcoe-netdev mapping.Signed-off-by: Bhanu Prakash Gollapudi
Signed-off-by: Robert Love
Signed-off-by: James Bottomley
13 Feb, 2011
3 commits
-
To facilitate LLDDs to reuse the code, skb queue related functions are moved to
libfcoe, so that both fcoe and bnx2fc drivers can use them. The common structures
fcoe_port, fcoe_percpu_s are moved to libfcoe. fcoe_port will now have an
opaque pointer that points to corresponding driver's interface structure.
Also, fcoe_start_io and fcoe_fc_crc are moved to libfcoe.As part of this change, fixed fcoe_start_io to return ENOMEM if
skb_clone fails.Signed-off-by: Bhanu Prakash Gollapudi
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
Now we can include the fcoe_transport.c to the build of the kernel libfcoe
module. Move the module information to fcoe_transport, and it will have
all the module parameters later for the create/destroy/enable/disable of an
FCoE instance.Signed-off-by: Yi Zou
Signed-off-by: Bhanu Prakash Gollapudi
Signed-off-by: Robert Love
Signed-off-by: James Bottomley -
Add the new fcoe_transport.c file that implements basic fcoe transport
interface. Eventually, the sysfs entries to create/destroy/enable/disable
an FCoE instance will be coming to the fcoe transport layer, who does a
look-up to find the corresponding transport provide and pass the corresponding
action over to the identified provider.The fcoe.ko will become the default fcoe transport provider that can support
FCoE on any given netdev interfaces, as the Open-FCoE.org's default software
FCoE HBA solution. Any vendor specific FCoE HBA driver that is built on top
of Open-FCoE's kernel stack of libfc & libfcoe as well as the user land tool
of fcoe-utils can easily plug-in and start running FCoE on their network
interfaces. The fcoe.ko will be converted to act as the default provider if
no vendor specific transport provider is found, as it is always added to the
very end of the list of attached transports.Signed-off-by: Yi Zou
Signed-off-by: Bhanu Prakash Gollapudi
Signed-off-by: Robert Love
Signed-off-by: James Bottomley