1. 25 Jun, 2013 1 commit
    • Robert Love's avatar
      fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs · 2884d423
      Robert Love authored
      fcoe_xmit was coded such that it would skip the vlan net device/layer
      and instead set some vlan flags and transmit on the real net device.
      The real net device has code that would add the vlan tag for fcoe skbs.
      This avoids some extra processing for data frames and provides a small
      performance improvement.
      Since fcoe_xmit was not using the vlan net device, __vlan_put_tag
      within the real net device's xmit routine was ultimately being
      called to set the vlan tag.
      With the below change the behavior of __vlan_put_tag changed slightly,
      it now sets the skb->protocol = vlan_proto. vlan_proto was not a field
      being set by fcoe_xmit, so the skb->protocol is now not being set to
      ETH_P_8021Q, as it should be.
      This patch converts fcoe_xmit to use the vlan_put_tag routine which
      will tag the skb and fcoe will continue to transmit fcoe skbs on the
      real net device.
      For reference, the below change was the one that altered the
      __vlan_put_tag behavior.
        commit 86a9bad3
        Author: Patrick McHardy <kaber@trash.net>
        Date:   Fri Apr 19 02:04:30 2013 +0000
            net: vlan: add protocol argument to packet tagging functions
            Add a protocol argument to the VLAN packet tagging functions. In case of HW
            tagging, we need that protocol available in the ndo_start_xmit functions,
            so it is stored in a new field in the skb. The new field fits into a hole
            (on 64 bit) and doesn't increase the sks's size.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
  2. 10 May, 2013 1 commit
  3. 30 Apr, 2013 1 commit
  4. 19 Apr, 2013 1 commit
  5. 25 Mar, 2013 4 commits
    • Robert Love's avatar
      libfcoe: Fix fcoe_sysfs VN2VN mode · 0db0e377
      Robert Love authored
      The libfc discovery layer is being initialized in the
      'create' paths for both legacy libfcoe module parameters
      and fcoe_sysfs control interfaces. The problem is that
      for VN2VN mode the discovery layer is initialized as if
      it were in 'fabric' mode and it is not re-configured when
      the mode is changed to 'vn2vn'.
      This patch splits out code that needs to be initialized
      once and code that can, and should be, re-configured when
      the mode changes. Additionally this patch makes that change
      so that the discovery layer can be reconfigured to the
      libfcoe implementation when in 'vn2vn' mode.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarJack Morgan <jack.morgan@intel.com>
      Reviewed-by: default avatarBhanu Prakash Gollapudi <bprakash@broadcom.com>
    • Robert Love's avatar
      libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config} · 0807619d
      Robert Love authored
      Split discovery initialization in code that is setup once (fcoe_disc_init)
      and code that can be re-configured (fcoe_disc_config).
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarJack Morgan <jack.morgan@intel.com>
      Reviewed-by: default avatarBhanu Prakash Gollapudi <bprakash@broadcom.com>
    • Robert Love's avatar
      libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery layer initialization · 8a9a7138
      Robert Love authored
      Currently libfcoe is doing some libfc discovery layer initialization outside of
      libfc. This patch moves this code into libfc and sets up a split in discovery
      (one time) initialization code and (re-configurable) settings that will come in
      the next patch.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarJack Morgan <jack.morgan@intel.com>
      Reviewed-by: default avatarBhanu Prakash Gollapudi <bprakash@broadcom.com>
    • Robert Love's avatar
      fcoe: Fix deadlock between create and destroy paths · f9c4358e
      Robert Love authored
      We can deadlock (s_active and fcoe_config_mutex) if a
      port is being destroyed at the same time one is being created.
      [ 4200.503113] ======================================================
      [ 4200.503114] [ INFO: possible circular locking dependency detected ]
      [ 4200.503116] 3.8.0-rc5+ #8 Not tainted
      [ 4200.503117] -------------------------------------------------------
      [ 4200.503118] kworker/3:2/2492 is trying to acquire lock:
      [ 4200.503119]  (s_active#292){++++.+}, at: [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70
      [ 4200.503127]
      but task is already holding lock:
      [ 4200.503128]  (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02f3338>] fcoe_destroy_work+0xe8/0x120 [fcoe]
      [ 4200.503133]
      which lock already depends on the new lock.
      [ 4200.503135]
      the existing dependency chain (in reverse order) is:
      [ 4200.503136]
      -> #1 (fcoe_config_mutex){+.+.+.}:
      [ 4200.503139]        [<ffffffff810c7711>] lock_acquire+0xa1/0x140
      [ 4200.503143]        [<ffffffff816ca7be>] mutex_lock_nested+0x6e/0x360
      [ 4200.503146]        [<ffffffffa02f11bd>] fcoe_enable+0x1d/0xb0 [fcoe]
      [ 4200.503148]        [<ffffffffa02f127d>] fcoe_ctlr_enabled+0x2d/0x50 [fcoe]
      [ 4200.503151]        [<ffffffffa02ffbe8>] store_ctlr_enabled+0x38/0x90 [libfcoe]
      [ 4200.503154]        [<ffffffff81424878>] dev_attr_store+0x18/0x30
      [ 4200.503157]        [<ffffffff8122b750>] sysfs_write_file+0xe0/0x150
      [ 4200.503160]        [<ffffffff811b334c>] vfs_write+0xac/0x180
      [ 4200.503162]        [<ffffffff811b3692>] sys_write+0x52/0xa0
      [ 4200.503164]        [<ffffffff816d7159>] system_call_fastpath+0x16/0x1b
      [ 4200.503167]
      -> #0 (s_active#292){++++.+}:
      [ 4200.503170]        [<ffffffff810c680f>] __lock_acquire+0x135f/0x1c90
      [ 4200.503172]        [<ffffffff810c7711>] lock_acquire+0xa1/0x140
      [ 4200.503174]        [<ffffffff8122c626>] sysfs_deactivate+0x116/0x160
      [ 4200.503176]        [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70
      [ 4200.503178]        [<ffffffff8122b2eb>] sysfs_hash_and_remove+0x5b/0xb0
      [ 4200.503180]        [<ffffffff8122f3d1>] sysfs_remove_group+0x61/0x100
      [ 4200.503183]        [<ffffffff814251eb>] device_remove_groups+0x3b/0x60
      [ 4200.503185]        [<ffffffff81425534>] device_remove_attrs+0x44/0x80
      [ 4200.503187]        [<ffffffff81425e97>] device_del+0x127/0x1c0
      [ 4200.503189]        [<ffffffff81425f52>] device_unregister+0x22/0x60
      [ 4200.503191]        [<ffffffffa0300970>] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe]
      [ 4200.503194]        [<ffffffffa02f1b5c>] fcoe_interface_cleanup+0x6c/0xa0 [fcoe]
      [ 4200.503196]        [<ffffffffa02f3355>] fcoe_destroy_work+0x105/0x120 [fcoe]
      [ 4200.503198]        [<ffffffff8107ee91>] process_one_work+0x1a1/0x580
      [ 4200.503203]        [<ffffffff81080c6e>] worker_thread+0x15e/0x440
      [ 4200.503205]        [<ffffffff8108715a>] kthread+0xea/0xf0
      [ 4200.503207]        [<ffffffff816d70ac>] ret_from_fork+0x7c/0xb0
      [ 4200.503209]
      other info that might help us debug this:
      [ 4200.503211]  Possible unsafe locking scenario:
      [ 4200.503212]        CPU0                    CPU1
      [ 4200.503213]        ----                    ----
      [ 4200.503214]   lock(fcoe_config_mutex);
      [ 4200.503215]                                lock(s_active#292);
      [ 4200.503218]                                lock(fcoe_config_mutex);
      [ 4200.503219]   lock(s_active#292);
      [ 4200.503221]
       *** DEADLOCK ***
      [ 4200.503223] 3 locks held by kworker/3:2/2492:
      [ 4200.503224]  #0:  (fcoe){.+.+.+}, at: [<ffffffff8107ee2b>] process_one_work+0x13b/0x580
      [ 4200.503228]  #1:  ((&port->destroy_work)){+.+.+.}, at: [<ffffffff8107ee2b>] process_one_work+0x13b/0x580
      [ 4200.503232]  #2:  (fcoe_config_mutex){+.+.+.}, at: [<ffffffffa02f3338>] fcoe_destroy_work+0xe8/0x120 [fcoe]
      [ 4200.503236]
      stack backtrace:
      [ 4200.503238] Pid: 2492, comm: kworker/3:2 Not tainted 3.8.0-rc5+ #8
      [ 4200.503240] Call Trace:
      [ 4200.503243]  [<ffffffff816c2f09>] print_circular_bug+0x1fb/0x20c
      [ 4200.503246]  [<ffffffff810c680f>] __lock_acquire+0x135f/0x1c90
      [ 4200.503248]  [<ffffffff810c463a>] ? debug_check_no_locks_freed+0x9a/0x180
      [ 4200.503250]  [<ffffffff810c7711>] lock_acquire+0xa1/0x140
      [ 4200.503253]  [<ffffffff8122d20b>] ? sysfs_addrm_finish+0x3b/0x70
      [ 4200.503255]  [<ffffffff8122c626>] sysfs_deactivate+0x116/0x160
      [ 4200.503258]  [<ffffffff8122d20b>] ? sysfs_addrm_finish+0x3b/0x70
      [ 4200.503260]  [<ffffffff8122d20b>] sysfs_addrm_finish+0x3b/0x70
      [ 4200.503262]  [<ffffffff8122b2eb>] sysfs_hash_and_remove+0x5b/0xb0
      [ 4200.503265]  [<ffffffff8122f3d1>] sysfs_remove_group+0x61/0x100
      [ 4200.503273]  [<ffffffff814251eb>] device_remove_groups+0x3b/0x60
      [ 4200.503275]  [<ffffffff81425534>] device_remove_attrs+0x44/0x80
      [ 4200.503277]  [<ffffffff81425e97>] device_del+0x127/0x1c0
      [ 4200.503279]  [<ffffffff81425f52>] device_unregister+0x22/0x60
      [ 4200.503282]  [<ffffffffa0300970>] fcoe_ctlr_device_delete+0xe0/0xf0 [libfcoe]
      [ 4200.503285]  [<ffffffffa02f1b5c>] fcoe_interface_cleanup+0x6c/0xa0 [fcoe]
      [ 4200.503287]  [<ffffffffa02f3355>] fcoe_destroy_work+0x105/0x120 [fcoe]
      [ 4200.503290]  [<ffffffff8107ee91>] process_one_work+0x1a1/0x580
      [ 4200.503292]  [<ffffffff8107ee2b>] ? process_one_work+0x13b/0x580
      [ 4200.503295]  [<ffffffffa02f3250>] ? fcoe_if_destroy+0x230/0x230 [fcoe]
      [ 4200.503297]  [<ffffffff81080c6e>] worker_thread+0x15e/0x440
      [ 4200.503299]  [<ffffffff81080b10>] ? busy_worker_rebind_fn+0x100/0x100
      [ 4200.503301]  [<ffffffff8108715a>] kthread+0xea/0xf0
      [ 4200.503304]  [<ffffffff81087070>] ? kthread_create_on_node+0x160/0x160
      [ 4200.503306]  [<ffffffff816d70ac>] ret_from_fork+0x7c/0xb0
      [ 4200.503308]  [<ffffffff81087070>] ? kthread_create_on_node+0x160/0x160
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarJack Morgan <jack.morgan@intel.com>
  6. 19 Feb, 2013 1 commit
  7. 12 Feb, 2013 1 commit
  8. 28 Jan, 2013 2 commits
    • Neerav Parikh's avatar
      fcoe: Fix deadlock while deleting FCoE interface with NPIV ports · 94aa743a
      Neerav Parikh authored
      This patch fixes following deadlock caused by destroying of
      an FCoE interface with active NPIV ports on that interface.
          Call Trace:
          [<ffffffff814b7e88>] schedule+0x64/0x66
          [<ffffffff814b6b4f>] schedule_timeout+0x36/0xe3
          [<ffffffff81070c55>] ? update_curr+0xd6/0x110
          [<ffffffff81071f6b>] ? hrtick_update+0x1b/0x4d
          [<ffffffff81072405>] ? dequeue_task_fair+0x1ca/0x1d9
          [<ffffffff8106a369>] ? need_resched+0x1e/0x28
          [<ffffffff814b7d14>] wait_for_common+0x9b/0xf1
          [<ffffffff8106e7be>] ? try_to_wake_up+0x1e0/0x1e0
          [<ffffffff814b7e22>] wait_for_completion+0x1d/0x1f
          [<ffffffff8105ae82>] flush_workqueue+0x116/0x2a1
          [<ffffffff8105b357>] drain_workqueue+0x66/0x14c
          [<ffffffff8105b8ef>] destroy_workqueue+0x1a/0xcf
          [<ffffffffa009211e>] fc_remove_host+0x154/0x17f [scsi_transport_fc]
          [<ffffffffa00edbb8>] fcoe_if_destroy+0x184/0x1c9 [fcoe]
          [<ffffffffa00edc28>] fcoe_destroy_work+0x2b/0x44 [fcoe]
          [<ffffffff8105a82a>] process_one_work+0x1a8/0x2a4
          [<ffffffffa00edbfd>] ? fcoe_if_destroy+0x1c9/0x1c9 [fcoe]
          [<ffffffff8105c396>] worker_thread+0x1db/0x268
          [<ffffffff810604a3>] ? wake_up_bit+0x2a/0x2a
          [<ffffffff8105c1bb>] ? manage_workers.clone.16+0x1f6/0x1f6
          [<ffffffff8105ffd6>] kthread+0x6f/0x77
          [<ffffffff814c0304>] kernel_thread_helper+0x4/0x10
          [<ffffffff8105ff67>] ? kthread_freezable_should_stop+0x4b/0x4b
          Call Trace:
          [<ffffffff814b7e88>] schedule+0x64/0x66
          [<ffffffff814b8041>] schedule_preempt_disabled+0xe/0x10
          [<ffffffff814b70a1>] __mutex_lock_common.clone.5+0x117/0x17a
          [<ffffffff814b7117>] __mutex_lock_slowpath+0x13/0x15
          [<ffffffff814b6f76>] mutex_lock+0x23/0x37
          [<ffffffff8125b890>] ? list_del+0x11/0x30
          [<ffffffffa00edc84>] fcoe_vport_destroy+0x43/0x5f [fcoe]
          [<ffffffffa009130a>] fc_vport_terminate+0x48/0x110 [scsi_transport_fc]
          [<ffffffffa00913ef>] fc_vport_sched_delete+0x1d/0x79 [scsi_transport_fc]
          [<ffffffff8105a82a>] process_one_work+0x1a8/0x2a4
          [<ffffffffa00913d2>] ? fc_vport_terminate+0x110/0x110 [scsi_transport_fc]
          [<ffffffff8105c396>] worker_thread+0x1db/0x268
          [<ffffffff8105c1bb>] ? manage_workers.clone.16+0x1f6/0x1f6
          [<ffffffff8105ffd6>] kthread+0x6f/0x77
          [<ffffffff814c0304>] kernel_thread_helper+0x4/0x10
          [<ffffffff8105ff67>] ? kthread_freezable_should_stop+0x4b/0x4b
          [<ffffffff814c0300>] ? gs_change+0x13/0x13
      A prior attempt to fix this issue is posted here:
      Based on feedback and discussion with Neil Horman it seems that the above patch
      may have a case where the fcoe_vport_destroy() and fcoe_destroy_work() can
      race; hence that patch has been withdrawn with this patch that is trying to
      solve the same problem in a different way.
      In the current approach instead of removing the fcoe_config_mutex from the
      vport_delete callback function; I've chosen to delete all the NPIV ports first
      on a given root lport before continuing with the removal of the root lport.
      Signed-off-by: default avatarNeerav Parikh <Neerav.Parikh@intel.com>
      Tested-by: default avatarMarcus Dennis <marcusx.e.dennis@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
    • Neil Horman's avatar
      fcoe: close race on link speed detection in fcoe code · f9184df3
      Neil Horman authored
      When creating an fcoe interfce, we call fcoe_link_speed_update before we add the
      lports fcoe interface to the fc_hostlist.  Since network device events like
      NETDEV_CHANGE are only processed if an fcoe interface is found with an
      underlying netdev that matches the netdev of the event.  Since this processing
      in fcoe_device_notification is how link_speed changes get communicated to the
      libfc  code (via fcoe_link_speed_update), we have a race condition - if a
      NETDEV_CHANGE event is sent after the call to fcoe_link_speed_update in
      fcoe_netdev_config, but before we add the interface to the fc_hostlist, we will
      loose the event and attributes like /sys/class/fc_host/hostX/speed will not get
      updated properly.
      Fix this by moving the add to the fc_hostlist above the serialized call to
      fcoe_netdev_config, ensuring that we catch netdev envents before we make a
      direct call to fcoe_link_speed_update.
      Also use this opportunity to clean up access to the fc_hostlist a bit by
      creating a fcoe_hostlist_del accessor and replacing the cleanup in fcoe_exit to
      use it properly.
      Tested by myself successfully
      [ Comment over 80 chars broken into multi-line by Robert Love to
        satisfy checkpatch.pl ]
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reviewed-by: default avatarYi Zou <yi.zou@intel.com>
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
  9. 18 Dec, 2012 1 commit
    • Akinobu Mita's avatar
      random32: rename random32 to prandom · 496f2f93
      Akinobu Mita authored
      This renames all random32 functions to have 'prandom_' prefix as follows:
        void prandom_seed(u32 seed);	/* rename from srandom32() */
        u32 prandom_u32(void);		/* rename from random32() */
        void prandom_seed_state(struct rnd_state *state, u64 seed);
        				/* rename from prandom32_seed() */
        u32 prandom_u32_state(struct rnd_state *state);
        				/* rename from prandom32() */
      The purpose of this renaming is to prevent some kernel developers from
      assuming that prandom32() and random32() might imply that only
      prandom32() was the one using a pseudo-random number generator by
      prandom32's "p", and the result may be a very embarassing security
      exposure.  This concern was expressed by Theodore Ts'o.
      And furthermore, I'm going to introduce new functions for getting the
      requested number of pseudo-random bytes.  If I continue to use both
      prandom32 and random32 prefixes for these functions, the confusion
      is getting worse.
      As a result of this renaming, "prandom_" is the common prefix for
      pseudo-random number library.
      Currently, srandom32() and random32() are preserved because it is
      difficult to rename too many users at once.
      Signed-off-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: Robert Love <robert.w.love@intel.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
      Cc: David Laight <david.laight@aculab.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Artem Bityutskiy <dedekind1@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Eilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  10. 14 Dec, 2012 8 commits
  11. 04 Dec, 2012 1 commit
    • Robert Love's avatar
      libfcoe: Save some memory and optimize name lookups · ef60f674
      Robert Love authored
      Instead of creating a structure with an enum and a pointer
      to a string, simply allocate an array of strings and use
      the enum values for the indicies.
      This means that we do not need to iterate through the list
      of entries when looking up a string name by its enum key.
      This will also help with a latter patch that will add
      more fcoe_sysfs attributes that will also use the
      fcoe_enum_name_search macro. One attribute will also do
      a reverse lookup which requires less code when the
      enum-to-string mappings are organized as this patch makes
      them to be.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
  12. 07 Oct, 2012 1 commit
  13. 20 Jul, 2012 4 commits
  14. 23 May, 2012 3 commits
    • Robert Love's avatar
      [SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE Syfs · 8d55e507
      Robert Love authored
      This patch has the SW FCoE driver and the bnx2fc
      driver make use of the new fcoe_sysfs API added
      earlier in this patch series.
      After this patch a fcoe_ctlr_device is allocated with
      private data in this order.
      +------------------+   +------------------+
      | fcoe_ctlr_device |   | fcoe_ctlr_device |
      +------------------+   +------------------+
      | fcoe_ctlr        |   | fcoe_ctlr        |
      +------------------+   +------------------+
      | fcoe_interface   |   | bnx2fc_interface |
      +------------------+   +------------------+
      libfcoe also takes part in this new model since it
      discovers and manages fcoe_fcf instances. The memory
      allocation is different for FCFs. I didn't want to
      impact libfcoe's fcoe_fcf processing, so this patch
      creates fcoe_fcf_device instances for each discovered
      fcoe_fcf. The two are paired using a (void * priv)
      member of the fcoe_ctlr_device. This allows libfcoe
      to continue maintaining its list of fcoe_fcf instances
      and simply attaches and detaches them from existing
      or new fcoe_fcf_device instances.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
    • Robert Love's avatar
      [SCSI] libfcoe: Add fcoe_sysfs · 9a74e884
      Robert Love authored
      This patch adds a 'fcoe bus' infrastructure to the kernel
      that is driven by changes to libfcoe which allow LLDs to
      present FIP (FCoE Initialization Protocol) discovered
      entities and their attributes to user space via sysfs.
      This patch adds the following APIs-
      They allow the LLD to expose the FCoE ENode Controller
      and any discovered FCFs (Fibre Channel Forwarders, e.g.
      FCoE switches) to the user. Each of these new devices
      has their own bus_type so that they are grouped together
      for easy lookup from a user space application. Each
      new class has an attribute_group to expose attributes
      for any created instances. The attributes are-
      * fcf_dev_loss_tmo
      * lesb_link_fail
      * lesb_vlink_fail
      * lesb_miss_fka
      * lesb_symb_err
      * lesb_err_block
      * lesb_fcs_error
      * fabric_name
      * switch_name
      * priority
      * selected
      * fc_map
      * vfid
      * mac
      * fka_peroid
      * fabric_state
      * dev_loss_tmo
      A device loss infrastructre similar to the FC Transport's
      is also added by this patch. It is nice to have so that a
      link flapping adapter doesn't continually advance the count
      used to identify the discovered FCF. FCFs will exist in a
      "Disconnected" state until either the timer expires or the
      FCF is rediscovered and becomes "Connected."
      This patch generates a few checkpatch.pl WARNINGS that
      I'm not sure what to do about. They're macros modeled
      around the FC Transport attribute building macros, which
      have the same 'feature' where the caller can ommit a cast
      in the argument list and no cast occurs in the code. I'm
      not sure how to keep the code condensed while keeping the
      macros. Any advice would be appreciated.
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
    • Robert Love's avatar
      [SCSI] fcoe: Allocate fcoe_ctlr with fcoe_interface, not as a member · 619fe4be
      Robert Love authored
      Currently the fcoe_ctlr associated with an interface is allocated
      as a member of struct fcoe_interface. This causes problems when
      attempting to use the new fcoe_sysfs APIs which allow us to allocate
      the fcoe_interface as private data to the fcoe_ctlr_device instance.
      The problem is that libfcoe wants to be able use pointer math to find a
      fcoe_ctlr's fcoe_ctlr_device as well as finding a fcoe_ctlr_device's
      assocated fcoe_ctlr. To do this we need to allocate the
      fcoe_ctlr_device, with private data for the LLD. The private data
      contains the fcoe_ctlr and its private data is the fcoe_interface.
      This patch only allocates the fcoe_interface with the fcoe_ctlr, the
      fcoe_ctlr_device will be added in a later patch, which will complete
      the below diagram-
      | fcoe_ctlr_device |
      | fcoe_ctlr        |
      | fcoe_interface   |
      This prep work will allow us to go from a fcoe_ctlr_device instance
      to its fcoe_ctlr as well as from a fcoe_ctlr to its fcoe_ctlr_device
      once the fcoe_sysfs API is in use (later patches in this series).
      Signed-off-by: default avatarRobert Love <robert.w.love@intel.com>
      Tested-by: default avatarRoss Brattain <ross.b.brattain@intel.com>
      Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
  15. 10 May, 2012 5 commits
  16. 28 Mar, 2012 5 commits