<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/scsi/fcoe, branch v3.5</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>[SCSI] fcoe, bnx2fc, libfcoe: SW FCoE and bnx2fc use FCoE Syfs</title>
<updated>2012-05-23T08:43:13+00:00</updated>
<author>
<name>Robert Love</name>
<email>robert.w.love@intel.com</email>
</author>
<published>2012-05-23T02:06:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d55e507d24c6db7eb012c379c62912e642eb75e'/>
<id>8d55e507d24c6db7eb012c379c62912e642eb75e</id>
<content type='text'>
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: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: Add fcoe_sysfs</title>
<updated>2012-05-23T08:40:09+00:00</updated>
<author>
<name>Robert Love</name>
<email>robert.w.love@intel.com</email>
</author>
<published>2012-05-23T02:06:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9a74e884ee71dbf3d0967b0321d7b4529a04826c'/>
<id>9a74e884ee71dbf3d0967b0321d7b4529a04826c</id>
<content type='text'>
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-

fcoe_ctlr_device_add
fcoe_ctlr_device_delete
fcoe_fcf_device_add
fcoe_fcf_device_delete

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-

fcoe_ctlr_device
* fcf_dev_loss_tmo
* lesb_link_fail
* lesb_vlink_fail
* lesb_miss_fka
* lesb_symb_err
* lesb_err_block
* lesb_fcs_error

fcoe_fcf_device
* 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: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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-

fcoe_ctlr_device_add
fcoe_ctlr_device_delete
fcoe_fcf_device_add
fcoe_fcf_device_delete

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-

fcoe_ctlr_device
* fcf_dev_loss_tmo
* lesb_link_fail
* lesb_vlink_fail
* lesb_miss_fka
* lesb_symb_err
* lesb_err_block
* lesb_fcs_error

fcoe_fcf_device
* 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: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] fcoe: Allocate fcoe_ctlr with fcoe_interface, not as a member</title>
<updated>2012-05-23T08:36:27+00:00</updated>
<author>
<name>Robert Love</name>
<email>robert.w.love@intel.com</email>
</author>
<published>2012-05-23T02:06:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=619fe4bed415e5d8a4749937f42b6a8a9031d4aa'/>
<id>619fe4bed415e5d8a4749937f42b6a8a9031d4aa</id>
<content type='text'>
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: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] fcoe: remove a stray unlock</title>
<updated>2012-05-10T07:59:26+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2012-04-20T19:16:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b3b8abd85780e1bb92703354f3c16c921edfa4f6'/>
<id>b3b8abd85780e1bb92703354f3c16c921edfa4f6</id>
<content type='text'>
We moved the locking in dd060e74fb "[SCSI] fcoe: remove frame dropping
code from fcoe_percpu_clean" but this unlock was missed.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We moved the locking in dd060e74fb "[SCSI] fcoe: remove frame dropping
code from fcoe_percpu_clean" but this unlock was missed.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] libfcoe: fix VN2VN N_Port_ID Beacon source MAC</title>
<updated>2012-05-10T07:59:26+00:00</updated>
<author>
<name>Yi Zou</name>
<email>yi.zou@intel.com</email>
</author>
<published>2012-04-20T19:16:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d227f029c2e1e7c226372a6c11969d33ed146f6f'/>
<id>d227f029c2e1e7c226372a6c11969d33ed146f6f</id>
<content type='text'>
FC-BB-6 v1.04 7.9.8.14 N_Port_ID Beacon:

"A N_Port_ID Beacon is multicast and uses the VN_Port MAC address as source
address."

Currently, libfcoe is using ENode MAC, this seems ok and functionality wise
not a problem in my back to back testing setup, however, just fix this to
make libfcoe VN2VN support more spec compliant.

Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
FC-BB-6 v1.04 7.9.8.14 N_Port_ID Beacon:

"A N_Port_ID Beacon is multicast and uses the VN_Port MAC address as source
address."

Currently, libfcoe is using ENode MAC, this seems ok and functionality wise
not a problem in my back to back testing setup, however, just fix this to
make libfcoe VN2VN support more spec compliant.

Signed-off-by: Yi Zou &lt;yi.zou@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] fcoe: Don't hold rtnl_mutex in fcoe_update_src_mac</title>
<updated>2012-05-10T07:59:25+00:00</updated>
<author>
<name>Robert Love</name>
<email>robert.w.love@intel.com</email>
</author>
<published>2012-04-20T19:16:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=949e71f17d9a5c59fa7b02cce3b548384bff1c92'/>
<id>949e71f17d9a5c59fa7b02cce3b548384bff1c92</id>
<content type='text'>
The rtnl_mutex was held to protect calls to dev_uc_add
and dev_uc_del. Holding rtnl is not required as those
functions make use of the netif_addr_lock* API to
protect the MAC changing.

This change fixes the following regression by removing
the rtnl usage when fcoe_update_src_mac is called.

https://bugzilla.kernel.org/show_bug.cgi?id=42918

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;fip-&gt;ctlr_mutex){+.+...}:
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;f8970c32&gt;] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
       [&lt;f894620e&gt;] fcoe_create+0x47e/0x6e0 [fcoe]
       [&lt;f8973dd3&gt;] fcoe_transport_create+0x143/0x250 [libfcoe]
       [&lt;c10527e0&gt;] param_attr_store+0x30/0x60
       [&lt;c1052696&gt;] module_attr_store+0x26/0x40
       [&lt;c11a201e&gt;] sysfs_write_file+0xae/0x100
       [&lt;c11449df&gt;] vfs_write+0x8f/0x160
       [&lt;c1144cbd&gt;] sys_write+0x3d/0x70
       [&lt;c147a0c4&gt;] syscall_call+0x7/0xb

-&gt; #0 (rtnl_mutex){+.+.+.}:
       [&lt;c109164b&gt;] __lock_acquire+0x140b/0x1720
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;c13a10c4&gt;] rtnl_lock+0x14/0x20
       [&lt;f89445ac&gt;] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
       [&lt;f8971712&gt;] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
       [&lt;c104fb69&gt;] process_one_work+0x179/0x5d0
       [&lt;c10502f1&gt;] worker_thread+0x121/0x2d0
       [&lt;c10550ed&gt;] kthread+0x7d/0x90
       [&lt;c1481a82&gt;] kernel_thread_helper+0x6/0x10

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;fip-&gt;ctlr_mutex);
                               lock(rtnl_mutex);
                               lock(&amp;fip-&gt;ctlr_mutex);
  lock(rtnl_mutex);

 *** DEADLOCK ***

Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The rtnl_mutex was held to protect calls to dev_uc_add
and dev_uc_del. Holding rtnl is not required as those
functions make use of the netif_addr_lock* API to
protect the MAC changing.

This change fixes the following regression by removing
the rtnl usage when fcoe_update_src_mac is called.

https://bugzilla.kernel.org/show_bug.cgi?id=42918

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;fip-&gt;ctlr_mutex){+.+...}:
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;f8970c32&gt;] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
       [&lt;f894620e&gt;] fcoe_create+0x47e/0x6e0 [fcoe]
       [&lt;f8973dd3&gt;] fcoe_transport_create+0x143/0x250 [libfcoe]
       [&lt;c10527e0&gt;] param_attr_store+0x30/0x60
       [&lt;c1052696&gt;] module_attr_store+0x26/0x40
       [&lt;c11a201e&gt;] sysfs_write_file+0xae/0x100
       [&lt;c11449df&gt;] vfs_write+0x8f/0x160
       [&lt;c1144cbd&gt;] sys_write+0x3d/0x70
       [&lt;c147a0c4&gt;] syscall_call+0x7/0xb

-&gt; #0 (rtnl_mutex){+.+.+.}:
       [&lt;c109164b&gt;] __lock_acquire+0x140b/0x1720
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;c13a10c4&gt;] rtnl_lock+0x14/0x20
       [&lt;f89445ac&gt;] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
       [&lt;f8971712&gt;] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
       [&lt;c104fb69&gt;] process_one_work+0x179/0x5d0
       [&lt;c10502f1&gt;] worker_thread+0x121/0x2d0
       [&lt;c10550ed&gt;] kthread+0x7d/0x90
       [&lt;c1481a82&gt;] kernel_thread_helper+0x6/0x10

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;fip-&gt;ctlr_mutex);
                               lock(rtnl_mutex);
                               lock(&amp;fip-&gt;ctlr_mutex);
  lock(rtnl_mutex);

 *** DEADLOCK ***

Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Tested-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] libfc: defer releasing master lport until complete fcoe interface cleanuped up</title>
<updated>2012-05-10T07:59:25+00:00</updated>
<author>
<name>Vasu Dev</name>
<email>vasu.dev@intel.com</email>
</author>
<published>2012-04-20T19:16:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3cab4468fd0a4b3c9f22a380e4318c17b6c202d6'/>
<id>3cab4468fd0a4b3c9f22a380e4318c17b6c202d6</id>
<content type='text'>
The fcoe controller has back references, therefore defer
releasing master lport which gets freed along scsi_host_put
and then free it once fcoe interface is fully cleaned.

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The fcoe controller has back references, therefore defer
releasing master lport which gets freed along scsi_host_put
and then free it once fcoe interface is fully cleaned.

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] fcoe: remove lport from net device before doing per cpu rx thread cleanup</title>
<updated>2012-05-10T07:59:24+00:00</updated>
<author>
<name>Vasu Dev</name>
<email>vasu.dev@intel.com</email>
</author>
<published>2012-04-20T19:16:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=433eba04c2cb53e0bbd2fb6da22d18f725bbf33f'/>
<id>433eba04c2cb53e0bbd2fb6da22d18f725bbf33f</id>
<content type='text'>
Remove lport from net device and then do synchronize net device to flush
inflight rx frames for the lport before doing fcoe_percpu_clean.

In case of master lport, remove all rx packet handlers completely and
then only do fcoe_percpu_clean. This required splitting fcoe_interface_cleanup
to do remove part separately and for that added func fcoe_interface_remove
and then  call it from fcoe_if_destory before doing fcoe_percpu_clean.
However if fcoe_interface_remove() is already called then
don't call again from fcoe_interface_cleanup() to preserve its
existing flows.

This patch along with Neil's other patch to avoid soft irq context
on ingress will avoid passing up frames on disabled lport as
discussed in this mail thread:-
http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove lport from net device and then do synchronize net device to flush
inflight rx frames for the lport before doing fcoe_percpu_clean.

In case of master lport, remove all rx packet handlers completely and
then only do fcoe_percpu_clean. This required splitting fcoe_interface_cleanup
to do remove part separately and for that added func fcoe_interface_remove
and then  call it from fcoe_if_destory before doing fcoe_percpu_clean.
However if fcoe_interface_remove() is already called then
don't call again from fcoe_interface_cleanup() to preserve its
existing flows.

This patch along with Neil's other patch to avoid soft irq context
on ingress will avoid passing up frames on disabled lport as
discussed in this mail thread:-
http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html

Signed-off-by: Vasu Dev &lt;vasu.dev@intel.com&gt;
Acked-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
Tested-by: Ross Brattain &lt;ross.b.brattain@intel.com&gt;
Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6</title>
<updated>2012-03-31T20:31:23+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-03-31T20:31:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a75ee6ecd411a50bf4da927c2fdb2cb56246a2bd'/>
<id>a75ee6ecd411a50bf4da927c2fdb2cb56246a2bd</id>
<content type='text'>
Pull SCSI updates from James Bottomley:
 "This is primarily another round of driver updates (lpfc, bfa, fcoe,
  ipr) plus a new ufshcd driver.  There shouldn't be anything
  controversial in here (The final deletion of scsi proc_ops which
  caused some build breakage has been held over until the next merge
  window to give us more time to stabilise it).

  I'm afraid, with me moving continents at exactly the wrong time,
  anything submitted after the merge window opened has been held over to
  the next merge window."

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (63 commits)
  [SCSI] ipr: Driver version 2.5.3
  [SCSI] ipr: Increase alignment boundary of command blocks
  [SCSI] ipr: Increase max concurrent oustanding commands
  [SCSI] ipr: Remove unnecessary memory barriers
  [SCSI] ipr: Remove unnecessary interrupt clearing on new adapters
  [SCSI] ipr: Fix target id allocation re-use problem
  [SCSI] atp870u, mpt2sas, qla4xxx use pci_dev-&gt;revision
  [SCSI] fcoe: Drop the rtnl_mutex before calling fcoe_ctlr_link_up
  [SCSI] bfa: Update the driver version to 3.0.23.0
  [SCSI] bfa: BSG and User interface fixes.
  [SCSI] bfa: Fix to avoid vport delete hang on request queue full scenario.
  [SCSI] bfa: Move service parameter programming logic into firmware.
  [SCSI] bfa: Revised Fabric Assigned Address(FAA) feature implementation.
  [SCSI] bfa: Flash controller IOC pll init fixes.
  [SCSI] bfa: Serialize the IOC hw semaphore unlock logic.
  [SCSI] bfa: Modify ISR to process pending completions
  [SCSI] bfa: Add fc host issue lip support
  [SCSI] mpt2sas: remove extraneous sas_log_info messages
  [SCSI] libfc: fcoe_transport_create fails in single-CPU environment
  [SCSI] fcoe: reduce contention for fcoe_rx_list lock [v2]
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull SCSI updates from James Bottomley:
 "This is primarily another round of driver updates (lpfc, bfa, fcoe,
  ipr) plus a new ufshcd driver.  There shouldn't be anything
  controversial in here (The final deletion of scsi proc_ops which
  caused some build breakage has been held over until the next merge
  window to give us more time to stabilise it).

  I'm afraid, with me moving continents at exactly the wrong time,
  anything submitted after the merge window opened has been held over to
  the next merge window."

* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (63 commits)
  [SCSI] ipr: Driver version 2.5.3
  [SCSI] ipr: Increase alignment boundary of command blocks
  [SCSI] ipr: Increase max concurrent oustanding commands
  [SCSI] ipr: Remove unnecessary memory barriers
  [SCSI] ipr: Remove unnecessary interrupt clearing on new adapters
  [SCSI] ipr: Fix target id allocation re-use problem
  [SCSI] atp870u, mpt2sas, qla4xxx use pci_dev-&gt;revision
  [SCSI] fcoe: Drop the rtnl_mutex before calling fcoe_ctlr_link_up
  [SCSI] bfa: Update the driver version to 3.0.23.0
  [SCSI] bfa: BSG and User interface fixes.
  [SCSI] bfa: Fix to avoid vport delete hang on request queue full scenario.
  [SCSI] bfa: Move service parameter programming logic into firmware.
  [SCSI] bfa: Revised Fabric Assigned Address(FAA) feature implementation.
  [SCSI] bfa: Flash controller IOC pll init fixes.
  [SCSI] bfa: Serialize the IOC hw semaphore unlock logic.
  [SCSI] bfa: Modify ISR to process pending completions
  [SCSI] bfa: Add fc host issue lip support
  [SCSI] mpt2sas: remove extraneous sas_log_info messages
  [SCSI] libfc: fcoe_transport_create fails in single-CPU environment
  [SCSI] fcoe: reduce contention for fcoe_rx_list lock [v2]
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>[SCSI] fcoe: Drop the rtnl_mutex before calling fcoe_ctlr_link_up</title>
<updated>2012-03-28T09:06:34+00:00</updated>
<author>
<name>Robert Love</name>
<email>robert.w.love@intel.com</email>
</author>
<published>2012-03-14T01:22:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2280512342ead9a2858b1490b21e5bcaf4f4cfc7'/>
<id>2280512342ead9a2858b1490b21e5bcaf4f4cfc7</id>
<content type='text'>
The rtnl_lock is primarily used to serialize networking
driver changes as well as to ensure that a networking driver
is not removed when making changes to it. fcoe also uses
the rtnl_lock to protect the fcoe hostlist.

fcoe_create holds the rtnl_lock over the entirity of the
routine including a the call to fcoe_ctlr_link_up.
This causes the below deadlock because fcoe_ctlr_link_up
acquires the fcoe_ctlr ctlr_mutex and this deadlocks with
a libfcoe thread that acquires the fcoe_ctlr ctlr_mutex and
then the rtnl_lock (to update a MAC address).

This patch drops the rtnl_lock before calling
fcoe_ctlr_link_up and therefore the deadlock is prevented.

https://bugzilla.kernel.org/show_bug.cgi?id=42918

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;fip-&gt;ctlr_mutex){+.+...}:
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;f8970c32&gt;] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
       [&lt;f894620e&gt;] fcoe_create+0x47e/0x6e0 [fcoe]
       [&lt;f8973dd3&gt;] fcoe_transport_create+0x143/0x250 [libfcoe]
       [&lt;c10527e0&gt;] param_attr_store+0x30/0x60
       [&lt;c1052696&gt;] module_attr_store+0x26/0x40
       [&lt;c11a201e&gt;] sysfs_write_file+0xae/0x100
       [&lt;c11449df&gt;] vfs_write+0x8f/0x160
       [&lt;c1144cbd&gt;] sys_write+0x3d/0x70
       [&lt;c147a0c4&gt;] syscall_call+0x7/0xb

-&gt; #0 (rtnl_mutex){+.+.+.}:
       [&lt;c109164b&gt;] __lock_acquire+0x140b/0x1720
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;c13a10c4&gt;] rtnl_lock+0x14/0x20
       [&lt;f89445ac&gt;] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
       [&lt;f8971712&gt;] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
       [&lt;c104fb69&gt;] process_one_work+0x179/0x5d0
       [&lt;c10502f1&gt;] worker_thread+0x121/0x2d0
       [&lt;c10550ed&gt;] kthread+0x7d/0x90
       [&lt;c1481a82&gt;] kernel_thread_helper+0x6/0x10

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;fip-&gt;ctlr_mutex);
                               lock(rtnl_mutex);
                               lock(&amp;fip-&gt;ctlr_mutex);
  lock(rtnl_mutex);

 *** DEADLOCK ***

Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The rtnl_lock is primarily used to serialize networking
driver changes as well as to ensure that a networking driver
is not removed when making changes to it. fcoe also uses
the rtnl_lock to protect the fcoe hostlist.

fcoe_create holds the rtnl_lock over the entirity of the
routine including a the call to fcoe_ctlr_link_up.
This causes the below deadlock because fcoe_ctlr_link_up
acquires the fcoe_ctlr ctlr_mutex and this deadlocks with
a libfcoe thread that acquires the fcoe_ctlr ctlr_mutex and
then the rtnl_lock (to update a MAC address).

This patch drops the rtnl_lock before calling
fcoe_ctlr_link_up and therefore the deadlock is prevented.

https://bugzilla.kernel.org/show_bug.cgi?id=42918

the existing dependency chain (in reverse order) is:

-&gt; #1 (&amp;fip-&gt;ctlr_mutex){+.+...}:
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;f8970c32&gt;] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
       [&lt;f894620e&gt;] fcoe_create+0x47e/0x6e0 [fcoe]
       [&lt;f8973dd3&gt;] fcoe_transport_create+0x143/0x250 [libfcoe]
       [&lt;c10527e0&gt;] param_attr_store+0x30/0x60
       [&lt;c1052696&gt;] module_attr_store+0x26/0x40
       [&lt;c11a201e&gt;] sysfs_write_file+0xae/0x100
       [&lt;c11449df&gt;] vfs_write+0x8f/0x160
       [&lt;c1144cbd&gt;] sys_write+0x3d/0x70
       [&lt;c147a0c4&gt;] syscall_call+0x7/0xb

-&gt; #0 (rtnl_mutex){+.+.+.}:
       [&lt;c109164b&gt;] __lock_acquire+0x140b/0x1720
       [&lt;c1091f70&gt;] lock_acquire+0x80/0x1b0
       [&lt;c147655d&gt;] mutex_lock_nested+0x6d/0x340
       [&lt;c13a10c4&gt;] rtnl_lock+0x14/0x20
       [&lt;f89445ac&gt;] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
       [&lt;f8971712&gt;] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
       [&lt;c104fb69&gt;] process_one_work+0x179/0x5d0
       [&lt;c10502f1&gt;] worker_thread+0x121/0x2d0
       [&lt;c10550ed&gt;] kthread+0x7d/0x90
       [&lt;c1481a82&gt;] kernel_thread_helper+0x6/0x10

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;fip-&gt;ctlr_mutex);
                               lock(rtnl_mutex);
                               lock(&amp;fip-&gt;ctlr_mutex);
  lock(rtnl_mutex);

 *** DEADLOCK ***

Signed-off-by: Robert Love &lt;robert.w.love@intel.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Parallels.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
