| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull first round of SCSI updates from James Bottomley:
"This patch set is driver updates for qla4xxx, scsi_debug, pm80xx,
fcoe/libfc, eas2r, lpfc, be2iscsi and megaraid_sas plus some assorted
bug fixes and cleanups"
* tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (106 commits)
[SCSI] scsi_error: Escalate to LUN reset if abort fails
[SCSI] Add 'eh_deadline' to limit SCSI EH runtime
[SCSI] remove check for 'resetting'
[SCSI] dc395: Move 'last_reset' into internal host structure
[SCSI] tmscsim: Move 'last_reset' into host structure
[SCSI] advansys: Remove 'last_reset' references
[SCSI] dpt_i2o: return SCSI_MLQUEUE_HOST_BUSY when in reset
[SCSI] dpt_i2o: Remove DPTI_STATE_IOCTL
[SCSI] megaraid_sas: Fix synchronization problem between sysPD IO path and AEN path
[SCSI] lpfc: Fix typo on NULL assignment
[SCSI] scsi_dh_alua: ALUA handler attach should succeed while TPG is transitioning
[SCSI] scsi_dh_alua: ALUA check sense should retry device internal reset unit attention
[SCSI] esas2r: Cleanup snprinf formatting of firmware version
[SCSI] esas2r: Remove superfluous mask of pcie_cap_reg
[SCSI] esas2r: Fixes for big-endian platforms
[SCSI] esas2r: Directly call kernel functions for atomic bit operations
[SCSI] lpfc 8.3.43: Update lpfc version to driver version 8.3.43
[SCSI] lpfc 8.3.43: Fixed not processing task management IOCB response status
[SCSI] lpfc 8.3.43: Fixed spinlock hang.
[SCSI] lpfc 8.3.43: Fixed invalid Total_Data_Placed value received for els and ct command responses
...
|
|
Preliminary to removing compare_ether_addr altogether:
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
In this pending patch:
http://patchwork.open-fcoe.org/patch/104/
Tomas Henzl noted that the error path when fcoe_fcf_device_add fails, was
missing a mutex_unlock call.
Not sure what staet the integration of the above patch is in, but if you could
either merge this with it, or apply it on top of what you already have, that
would be great. Thanks!
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: thenzl@redhat.com
Reported-by: thenzl@redhat.com
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
fnic doesn't use any of the create/destroy/enable/disable interfaces
either from the (legacy) module paramaters or the (new) fcoe_sysfs
interfaces. When fcoe_sysfs was introduced fnic wasn't changed since
it wasn't using the interfaces. libfcoe incorrectly assumed that that
all of its users were using fcoe_sysfs and when adding and deleting
FCFs would assume the existance of a fcoe_ctlr_device. fnic was not
allocating this structure because it doesn't care about the standard
user interfaces (fnic starts on link only). If/When libfcoe tried to use
the fcoe_ctlr_device's lock for the first time a NULL pointer exception
would be triggered.
Since fnic doesn't care about sysfs or user interfaces, the solution
is to drop libfcoe's assumption that all drivers are using fcoe_sysfs.
This patch accomplishes this by changing some of the structure
relationships.
We need a way to determine when a LLD is using fcoe_sysfs or not and
we can do that by checking for the existance of the fcoe_ctlr_device.
Prior to this patch, it was assumed that the fcoe_ctlr structure was
allocated with the fcoe_ctlr_device and immediately followed it in
memory. To reach the fcoe_ctlr_device we would simply go back in memory
from the fcoe_ctlr to get the fcoe_ctlr_device.
Since fnic doesn't allocate the fcoe_ctlr_device, we cannot keep that
assumption. This patch adds a pointer from the fcoe_ctlr to the
fcoe_ctlr_device. For bnx2fc and fcoe we will continue to allocate the
two structures together, but then we'll set the ctlr->cdev pointer
to point at the fcoe_ctlr_device. fnic will not change and will continue
to allocate the fcoe_ctlr itself, and ctlr->cdev will remain NULL.
When libfcoe adds fcoe_fcf's to the fcoe_ctlr it will check if ctlr->cdev
is set and only if so will it continue to interact with fcoe_sysfs.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Hiral Patel <hiralpat@cisco.com>
|
|
I had a typo in a variable name for the previous patch (SCSI: fcoe:
convert bus code to use bus_group) that broke the build, this fixes
that.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the fcoe bus code to use the
correct field.
Cc: Robert Love <robert.w.love@intel.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch fixes the following compiler warning:
drivers/scsi/fcoe/fcoe_ctlr.c: In function fcoe_sysfs_fcf_add:
drivers/scsi/fcoe/fcoe_ctlr.c:211:1: warning: the frame size of 1480 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
FCoE debug statements must end in a newline. Add one where it is missing.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
The function fcoe_ctlr_mode_set() is local, hence declare it static.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
the return codes from fcoe_rcv should be NET_RX_*, not 0 or -1.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Based on my last patch I noticed that fcoe_rcv has a simmilar problem, in that
it manipulates the passed in skb without checking to see if it has other users.
Making manipulations to a shared skb can result in various corruptions.
Easy fix, just make sure the skb is unshared prior to doing anything with it.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Recently had this Oops reported to me on the 3.10 kernel:
[ 807.554955] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 807.562799] IP: [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[ 807.568296] PGD 20c889067 PUD 20c8b8067 PMD 0
[ 807.572769] Oops: 0002 [#1] SMP
[ 807.655597] Hardware name: Dell Inc. PowerEdge R415/0DDT2D, BIOS 1.8.6 12/06/2011
[ 807.663079] Workqueue: events fcoe_ctlr_recv_work [libfcoe]
[ 807.668656] task: ffff88020b42a160 ti: ffff88020ae6c000 task.ti: ffff88020ae6c000
[ 807.676126] RIP: 0010:[<ffffffff814e6fc7>] [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[ 807.684046] RSP: 0000:ffff88020ae6dd70 EFLAGS: 00010097
[ 807.689349] RAX: 0000000000000246 RBX: ffff8801d04d6700 RCX: 0000000000000000
[ 807.696474] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88020df26434
[ 807.703598] RBP: ffff88020ae6dd88 R08: 00000000000173e0 R09: ffff880216e173e0
[ 807.710723] R10: ffffffff814e5897 R11: ffffea0007413580 R12: ffff88020df26420
[ 807.717847] R13: ffff88020df26434 R14: 0000000000000004 R15: ffff8801d04c42ce
[ 807.724972] FS: 00007fdaab6048c0(0000) GS:ffff880216e00000(0000) knlGS:0000000000000000
[ 807.733049] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 807.738785] CR2: 0000000000000008 CR3: 000000020cbc9000 CR4: 00000000000006f0
[ 807.745910] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 807.753033] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 807.760156] Stack:
[ 807.762162] ffff8801d04d6700 0000000000000001 ffff88020df26400 ffff88020ae6de20
[ 807.769586] ffffffffa0444409 ffff88020b046a00 ffff88020ae6dde8 ffffffff810105be
[ 807.777008] ffff88020b42a868 0000000000000000 ffff88020df264a8 ffff88020df26348
[ 807.784431] Call Trace:
[ 807.786885] [<ffffffffa0444409>] fcoe_ctlr_recv_work+0x59/0x9a0 [libfcoe]
[ 807.793755] [<ffffffff810105be>] ? __switch_to+0x13e/0x4a0
[ 807.799324] [<ffffffff8107d0e6>] process_one_work+0x176/0x420
[ 807.805151] [<ffffffff8107dd0b>] worker_thread+0x11b/0x3a0
[ 807.810717] [<ffffffff8107dbf0>] ? rescuer_thread+0x350/0x350
[ 807.816545] [<ffffffff810842b0>] kthread+0xc0/0xd0
[ 807.821416] [<ffffffff810841f0>] ? insert_kthread_work+0x40/0x40
[ 807.827503] [<ffffffff8160ce2c>] ret_from_fork+0x7c/0xb0
[ 807.832897] [<ffffffff810841f0>] ? insert_kthread_work+0x40/0x40
[ 807.858500] RIP [<ffffffff814e6fc7>] skb_dequeue+0x47/0x70
[ 807.864076] RSP <ffff88020ae6dd70>
[ 807.867558] CR2: 0000000000000008
Looks like the root cause is the fact that the packet recieve function
fcoe_ctlr_recv enqueues the skb to a sk_buff_head_list prior to ensuring that
the skb is unshared. This can happen when multiple packet listeners recieve an
skb, as the deliver_skb function just increments skb->users for each handler.
As a result, having multiple users of a single skb results in multiple
manipulators of its methods, implying list corruption, and the oops recorded
above.
The fix is pretty easy, just make sure that we clone the skb if its got multiple
users with the skb_share_check function, like other protocols do.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull final round of SCSI updates from James Bottomley:
"This is the remaining set of SCSI patches for the merge window. It's
mostly driver updates (scsi_debug, qla2xxx, storvsc, mp3sas). There
are also several bug fixes in fcoe, libfc, and megaraid_sas. We also
have a couple of core changes to try to make device destruction more
deterministic"
* tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (46 commits)
[SCSI] scsi constants: command, sense key + additional sense strings
fcoe: Reduce number of sparse warnings
fcoe: Stop fc_rport_priv structure leak
libfcoe: Fix meaningless log statement
libfc: Differentiate echange timer cancellation debug statements
libfc: Remove extra space in fc_exch_timer_cancel definition
fcoe: fix the link error status block sparse warnings
fcoe: Fix smatch warning in fcoe_fdmi_info function
libfc: Reject PLOGI from nodes with incompatible role
[SCSI] enable destruction of blocked devices which fail LUN scanning
[SCSI] Fix race between starved list and device removal
[SCSI] megaraid_sas: fix a bug for 64 bit arches
[SCSI] scsi_debug: reduce duplication between prot_verify_read and prot_verify_write
[SCSI] scsi_debug: simplify offset calculation for dif_storep
[SCSI] scsi_debug: invalidate protection info for unmapped region
[SCSI] scsi_debug: fix NULL pointer dereference with parameters dif=0 dix=1
[SCSI] scsi_debug: fix incorrectly nested kmap_atomic()
[SCSI] scsi_debug: fix invalid address passed to kunmap_atomic()
[SCSI] mpt3sas: Bump driver version to v02.100.00.00
[SCSI] mpt3sas: when async scanning is enabled then while scanning, devices are removed but their transport layer entries are not removed
...
|
|
Declare local variables and functions 'static'. This patch does not
change any functionality.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
When repeatedly doing rmmod and modprobe on the ixgbe
driver while FCoE is active in a VN2VN configuration,
memory leaks would be discovered by kmemleak with the
following backtrace:
unreferenced object 0xffff88003d076000 (size 1024):
comm "kworker/0:3", pid 2998, jiffies 4295436448 (age 1015.332s)
hex dump (first 32 bytes):
48 8a fe 6f 00 88 ff ff 00 00 00 00 00 00 00 00 H..o............
01 00 00 00 02 00 00 00 7b ac 87 21 1b 00 00 10 ........{..!....
backtrace:
[<ffffffff814b308b>] kmemleak_alloc+0x5b/0xc0
[<ffffffff8115c6e8>] __kmalloc+0xd8/0x1b0
[<ffffffffa0216638>] fc_rport_create+0x48/0x1f0 [libfc]
[<ffffffffa023cd86>] fcoe_ctlr_vn_add.isra.10+0x56/0x1a0 [libfcoe]
[<ffffffffa023f440>] fcoe_ctlr_vn_recv+0x8b0/0xab0 [libfcoe]
[<ffffffffa023fb06>] fcoe_ctlr_recv_work+0x4c6/0xf60 [libfcoe]
[<ffffffff81067404>] process_one_work+0x1e4/0x4d0
[<ffffffff81068def>] worker_thread+0x10f/0x380
[<ffffffff8107019a>] kthread+0xea/0xf0
[<ffffffff814d32ec>] ret_from_fork+0x7c/0xb0
[<ffffffffffffffff>] 0xffffffffffffffff
This patch stops the leak of the fc_rport_priv structure.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
ctlr_dev was initialized to NULL, and never re-assigned. This
caused the log statement to always report failure. This patch
removes the unused variable and fixes the log statement to always
report 'success', as that is what should be logged if the code
reaches this point.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
|
|
Both fcoe_fc_els_lesb and fc_els_lesb are in __be32 already, and both are
exactly the same size in bytes, with somewhat different member names to
reflect the fact the former is for Ethernet media the latter is for Fiber
Channel, so, remove conversion and use __be32 directly. This fixes the warning
from sparse check.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
This patch fixes a smatch warning as below:
smatch warnings:
drivers/scsi/fcoe/fcoe.c:782 fcoe_fdmi_info() warn: 'fdmi' puts 896 bytes on
stack
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Neerav Parikh <Neerav.Parikh@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Conflicts:
drivers/net/ethernet/freescale/fec_main.c
drivers/net/ethernet/renesas/sh_eth.c
net/ipv4/gre.c
The GRE conflict is between a bug fix (kfree_skb --> kfree_skb_list)
and the splitting of the gre.c code into seperate files.
The FEC conflict was two sets of changes adding ethtool support code
in an "!CONFIG_M5272" CPP protected block.
Finally the sh_eth.c conflict was between one commit add bits set
in the .eesr_err_check mask whilst another commit removed the
.tx_error_check member and assignments.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch fixes a critical bug that was introduced in 3.9
related to VLAN tagging FCoE frames.
|
|
3.10 fixes
|
|
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 86a9bad3ab6b6f858fd4443b48738cabbb6d094c
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: Robert Love <robert.w.love@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
|
|
So far, only net_device * could be passed along with netdevice notifier
event. This patch provides a possibility to pass custom structure
able to provide info that event listener needs to know.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
v2->v3: fix typo on simeth
shortened dev_getter
shortened notifier_info struct name
v1->v2: fix notifier_call parameter in call_netdevice_notifier()
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When multiple FCFs in use, and first FIP Advertisement received is
with "Available for Login" i.e A bit set to 0, FCF selection will fail.
The fix is to remove the assumption in the code that first FCF is only
allowed selectable FCF.
Consider the scenario fip->fcfs contains FCF1(fabricname X, marked A=0)
FCF2(fabricname Y, marked A=1). list_first_entry(first) points to FCF1
and 1st iteration we ignore the FCF and on 2nd iteration we compare
FCF1 & FCF2 fabric name and we fails to perform FCF selection.
Signed-off-by: Krishna Mohan <krmohan@cisco.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Pull networking updates from David Miller:
"Highlights (1721 non-merge commits, this has to be a record of some
sort):
1) Add 'random' mode to team driver, from Jiri Pirko and Eric
Dumazet.
2) Make it so that any driver that supports configuration of multiple
MAC addresses can provide the forwarding database add and del
calls by providing a default implementation and hooking that up if
the driver doesn't have an explicit set of handlers. From Vlad
Yasevich.
3) Support GSO segmentation over tunnels and other encapsulating
devices such as VXLAN, from Pravin B Shelar.
4) Support L2 GRE tunnels in the flow dissector, from Michael Dalton.
5) Implement Tail Loss Probe (TLP) detection in TCP, from Nandita
Dukkipati.
6) In the PHY layer, allow supporting wake-on-lan in situations where
the PHY registers have to be written for it to be configured.
Use it to support wake-on-lan in mv643xx_eth.
From Michael Stapelberg.
7) Significantly improve firewire IPV6 support, from YOSHIFUJI
Hideaki.
8) Allow multiple packets to be sent in a single transmission using
network coding in batman-adv, from Martin Hundebøll.
9) Add support for T5 cxgb4 chips, from Santosh Rastapur.
10) Generalize the VXLAN forwarding tables so that there is more
flexibility in configurating various aspects of the endpoints.
From David Stevens.
11) Support RSS and TSO in hardware over GRE tunnels in bxn2x driver,
from Dmitry Kravkov.
12) Zero copy support in nfnelink_queue, from Eric Dumazet and Pablo
Neira Ayuso.
13) Start adding networking selftests.
14) In situations of overload on the same AF_PACKET fanout socket, or
per-cpu packet receive queue, minimize drop by distributing the
load to other cpus/fanouts. From Willem de Bruijn and Eric
Dumazet.
15) Add support for new payload offset BPF instruction, from Daniel
Borkmann.
16) Convert several drivers over to mdoule_platform_driver(), from
Sachin Kamat.
17) Provide a minimal BPF JIT image disassembler userspace tool, from
Daniel Borkmann.
18) Rewrite F-RTO implementation in TCP to match the final
specification of it in RFC4138 and RFC5682. From Yuchung Cheng.
19) Provide netlink socket diag of netlink sockets ("Yo dawg, I hear
you like netlink, so I implemented netlink dumping of netlink
sockets.") From Andrey Vagin.
20) Remove ugly passing of rtnetlink attributes into rtnl_doit
functions, from Thomas Graf.
21) Allow userspace to be able to see if a configuration change occurs
in the middle of an address or device list dump, from Nicolas
Dichtel.
22) Support RFC3168 ECN protection for ipv6 fragments, from Hannes
Frederic Sowa.
23) Increase accuracy of packet length used by packet scheduler, from
Jason Wang.
24) Beginning set of changes to make ipv4/ipv6 fragment handling more
scalable and less susceptible to overload and locking contention,
from Jesper Dangaard Brouer.
25) Get rid of using non-type-safe NLMSG_* macros and use nlmsg_*()
instead. From Hong Zhiguo.
26) Optimize route usage in IPVS by avoiding reference counting where
possible, from Julian Anastasov.
27) Convert IPVS schedulers to RCU, also from Julian Anastasov.
28) Support cpu fanouts in xt_NFQUEUE netfilter target, from Holger
Eitzenberger.
29) Network namespace support for nf_log, ebt_log, xt_LOG, ipt_ULOG,
nfnetlink_log, and nfnetlink_queue. From Gao feng.
30) Implement RFC3168 ECN protection, from Hannes Frederic Sowa.
31) Support several new r8169 chips, from Hayes Wang.
32) Support tokenized interface identifiers in ipv6, from Daniel
Borkmann.
33) Use usbnet_link_change() helper in USB net driver, from Ming Lei.
34) Add 802.1ad vlan offload support, from Patrick McHardy.
35) Support mmap() based netlink communication, also from Patrick
McHardy.
36) Support HW timestamping in mlx4 driver, from Amir Vadai.
37) Rationalize AF_PACKET packet timestamping when transmitting, from
Willem de Bruijn and Daniel Borkmann.
38) Bring parity to what's provided by /proc/net/packet socket dumping
and the info provided by netlink socket dumping of AF_PACKET
sockets. From Nicolas Dichtel.
39) Fix peeking beyond zero sized SKBs in AF_UNIX, from Benjamin
Poirier"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1722 commits)
filter: fix va_list build error
af_unix: fix a fatal race with bit fields
bnx2x: Prevent memory leak when cnic is absent
bnx2x: correct reading of speed capabilities
net: sctp: attribute printl with __printf for gcc fmt checks
netlink: kconfig: move mmap i/o into netlink kconfig
netpoll: convert mutex into a semaphore
netlink: Fix skb ref counting.
net_sched: act_ipt forward compat with xtables
mlx4_en: fix a build error on 32bit arches
Revert "bnx2x: allow nvram test to run when device is down"
bridge: avoid OOPS if root port not found
drivers: net: cpsw: fix kernel warn on cpsw irq enable
sh_eth: use random MAC address if no valid one supplied
3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA)
tg3: fix to append hardware time stamping flags
unix/stream: fix peeking with an offset larger than data in queue
unix/dgram: fix peeking with an offset larger than data in queue
unix/dgram: peek beyond 0-sized skbs
openvswitch: Remove unneeded ovs_netdev_get_ifindex()
...
|
|
Use preferable function name which implies using a pseudo-random
number generator.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Robert Love <robert.w.love@intel.com>
Cc: James Smart <james.smart@emulex.com>
Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Rename the hardware VLAN acceleration features to include "CTAG" to indicate
that they only support CTAGs. Follow up patches will introduce 802.1ad
server provider tagging (STAGs) and require the distinction for hardware not
supporting acclerating both.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
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: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
|
|
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: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
|
|
initialization
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: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
Reviewed-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
|
|
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: Robert Love <robert.w.love@intel.com>
Tested-by: Jack Morgan <jack.morgan@intel.com>
|
|
FCoE Updates for 3.9
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
When there are multiple FCFs in the fabric, and one of them becomes
unavailable, the fabric name for the unavailable FCF becomes 0 along
with FIP_FL_AVAIL getting reset. In this case, FCF selection logic does
not select any FCF as it first checks for conflicting FCFs (since fabric
name is 0, it fails the condition), instead of first checking if it is
usable or not. Fix it by first checking if FCF is usable and skip that
FCF, and go to the next one in the list to check if it can be selected.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
When a CVL is received while we wait to select best FCF, we drop it
without handling it. This causes initiator and the switch to go
out-of-sync. Initiator proceeds selecting one of the FCFs and tries to
send FIP FLOGI. However the switch may reject the FLOGI, as it has
cleared its internal state, and expects the initiator to start FIP
discovery protocol. Fix this condition by resetting the fcoe
controller.
Signed-off-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Reviewed-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
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:
http://lists.open-fcoe.org/pipermail/devel/2012-October/012318.html
or
http://article.gmane.org/gmane.linux.scsi.open-fcoe.devel/11924
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: Neerav Parikh <Neerav.Parikh@intel.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
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: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Yi Zou <yi.zou@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
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: Akinobu 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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
AFAICS, the situation for fcoe_transport_disable() seems to be
the same as for fcoe_transport_enable(). IOW, shouldn't it have
restart_syscall() removed as well? I don't see any in-tree ->disable()
instances that could return -ERESTARTSYS, anyway...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Similarly they can be moved into libfcoe instead of being private to fcoe now.
Also add comments particularly on the term LESB to the corresponding function.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
With the previous patch, fcoe_link_speed_update() can be moved into libfcoe and
exported to used by fcoe, bnx2fc, and etc.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Adds support to fcoe_port's newly added get_netdev fucntion pointer.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Cc: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
|
|
Convert libfc, libfcoe and fcoe's debug_logging macros
to use pr_info() instead of printk(KERN_INFO, ...). checkpatch.pl
now complains about this, so convert libfcoe to preferred
method.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
|
|
This patch adds support for the new fcoe_sysfs
control interface to fcoe.ko. It keeps the deprecated
interface in tact and therefore either the legacy
or the new control interfaces can be used. A mixed mode
is not supported. A user must either use the new
interfaces or the old ones, but not both.
The fcoe_ctlr's link state is now driven by both the
netdev link state as well as the fcoe_ctlr_device's
enabled attribute. The link must be up and the
fcoe_ctlr_device must be enabled before the FCoE
Controller starts discovery or login.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
|
|
This patch does a few things.
1) Makes /sys/bus/fcoe/ctlr_{create,destroy} interfaces.
These interfaces take an <ifname> and will either
create an FCoE Controller or destroy an FCoE
Controller depending on which file is written to.
The new FCoE Controller will start in a DISABLED
state and will not do discovery or login until it
is ENABLED. This pause will allow us to configure
the FCoE Controller before enabling it.
2) Makes the 'mode' attribute of a fcoe_ctlr_device
writale. This allows the user to configure the mode
in which the FCoE Controller will start in when it
is ENABLED.
Possible modes are 'Fabric', or 'VN2VN'.
The default mode for a fcoe_ctlr{,_device} is 'Fabric'.
Drivers must implement the set_fcoe_ctlr_mode routine
to support this feature.
libfcoe offers an exported routine to set a FCoE
Controller's mode. The mode can only be changed
when the FCoE Controller is DISABLED.
This patch also removes the get_fcoe_ctlr_mode pointer
in the fcoe_sysfs function template, the code in
fcoe_ctlr.c to get the mode and the assignment of
the fcoe_sysfs function pointer to the fcoe_ctlr.c
implementation (in fcoe and bnx2fc). fcoe_sysfs can
return that value for the mode without consulting the
LLD.
3) Make a 'enabled' attribute of a fcoe_ctlr_device. On a
read, fcoe_sysfs will return the attribute's value. On
a write, fcoe_sysfs will call the LLD (if there is a
callback) to notifiy that the enalbed state has changed.
This patch maintains the old FCoE control interfaces as
module parameters, but it adds comments pointing out that
the old interfaces are deprecated.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
|
|
Add a macro to print fcoe_sysfs debug statements.
Signed-off-by: Robert Love <robert.w.love@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
|
|
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: Robert Love <robert.w.love@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
|
|
SCSI errors were generated while writing to LUNs
connected via NPIV ports.
Debugging this it was found that the FCoE packets
transmitted via the NPIV ports were not tagged with
correct user priority as negotiated with peer by DCB
agent. This resulted in FCoE traffic going with priority
zero(0) that did not have priority flow control (PFC)
enabled for it. The initiator after transferring data
to the target never saw any reply indicating the transfer
was complete. This resulted in error recovery (ABTS) and
SCSI command retries by the scsi-mid layer; eventually
resulting in I/O errors.
This patch fixes this issue by keeping the FCoE user
priority information in the fcoe_interface instance
that is common for both the physical port as well as
NPIV ports connected to that physical port; instead
of storing it in fcoe_port structure that has a per
port instance.
Signed-off-by: Neerav Parikh <Neerav.Parikh@intel.com>
Acked-by: Yi Zou <yi.zou@intel.com>
Acked-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
Noticed that we can shuffle the code around in fcoe_percpu_receive_thread a bit
and avoid taking the fcoe_rx_list lock twice per iteration. This should improve
throughput somewhat. With this change we take the lock, and check for new
frames in a single critical section. Only if the list is empty do we drop the
lock and re-acquire it after being signaled to wake up.
Change Notes:
v2) did some further cleanup on the patch by replacing the 2nd call of
spin_lock/splice_init with a goto to the top of the outer loop. This allows me
to change the inner while loop to an if conditional and remove the sencond check
of kthread_should_stop. Based on suggestion from Vasu Dev.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
strtoul returns an 'unsigned long' so there is no
reason to check if the value is less than zero.
strtoul already checks for the '-' character deep
in its bowels. It will return an error if the user
has provided a negative value and fcoe_str_to_dev_loss
will return that error to its caller.
This patch fixes the following Coverity reported warning:
CID 703581 - NO_EFFECT Unsigned compared against 0 - This
less-than-zero comparison of an unsigned value is never true. "*val < 0UL".
drivers/scsi/fcoe/fcoe_sysfs.c:105
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
|
Recent changes to add fcoe_sysfs caused libfcoe_init to call fcoe_transport_exit
in a module initialization routine. The change resulted in the below error. This
patch removes the __exit keyword from the fcoe_transport_exit definition such
that it may be called from an __init routine.
WARNING: drivers/scsi/fcoe/libfcoe.o(.init.text+0x21): Section mismatch in reference from the function init_module() to the function .exit.text:fcoe_transp
exit()
The function __init init_module() references
a function __exit fcoe_transport_exit().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __exit annotation of
fcoe_transport_exit() so it may be used outside an exit section.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
|
