In little endian cases, the macro htons unfolds to __swab16 which
provides special case for constants. In big endian cases,
__constant_htons and htons expand directly to the same expression.
So, replace __constant_htons with htons with the goal of getting
rid of the definition of __constant_htons completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_htons(x)
+ htons(x)
Signed-off-by: Vaishali Thakkar <vthakkar1994@gmail.com>
Acked-by: Vasu Dev <vasu.dev@intel.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Pull networking updates from David Miller:
1) New offloading infrastructure and example 'rocker' driver for
offloading of switching and routing to hardware.
This work was done by a large group of dedicated individuals, not
limited to: Scott Feldman, Jiri Pirko, Thomas Graf, John Fastabend,
Jamal Hadi Salim, Andy Gospodarek, Florian Fainelli, Roopa Prabhu
2) Start making the networking operate on IOV iterators instead of
modifying iov objects in-situ during transfers. Thanks to Al Viro
and Herbert Xu.
3) A set of new netlink interfaces for the TIPC stack, from Richard
Alpe.
4) Remove unnecessary looping during ipv6 routing lookups, from Martin
KaFai Lau.
5) Add PAUSE frame generation support to gianfar driver, from Matei
Pavaluca.
6) Allow for larger reordering levels in TCP, which are easily
achievable in the real world right now, from Eric Dumazet.
7) Add a variable of napi_schedule that doesn't need to disable cpu
interrupts, from Eric Dumazet.
8) Use a doubly linked list to optimize neigh_parms_release(), from
Nicolas Dichtel.
9) Various enhancements to the kernel BPF verifier, and allow eBPF
programs to actually be attached to sockets. From Alexei
Starovoitov.
10) Support TSO/LSO in sunvnet driver, from David L Stevens.
11) Allow controlling ECN usage via routing metrics, from Florian
Westphal.
12) Remote checksum offload, from Tom Herbert.
13) Add split-header receive, BQL, and xmit_more support to amd-xgbe
driver, from Thomas Lendacky.
14) Add MPLS support to openvswitch, from Simon Horman.
15) Support wildcard tunnel endpoints in ipv6 tunnels, from Steffen
Klassert.
16) Do gro flushes on a per-device basis using a timer, from Eric
Dumazet. This tries to resolve the conflicting goals between the
desired handling of bulk vs. RPC-like traffic.
17) Allow userspace to ask for the CPU upon what a packet was
received/steered, via SO_INCOMING_CPU. From Eric Dumazet.
18) Limit GSO packets to half the current congestion window, from Eric
Dumazet.
19) Add a generic helper so that all drivers set their RSS keys in a
consistent way, from Eric Dumazet.
20) Add xmit_more support to enic driver, from Govindarajulu
Varadarajan.
21) Add VLAN packet scheduler action, from Jiri Pirko.
22) Support configurable RSS hash functions via ethtool, from Eyal
Perry.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1820 commits)
Fix race condition between vxlan_sock_add and vxlan_sock_release
net/macb: fix compilation warning for print_hex_dump() called with skb->mac_header
net/mlx4: Add support for A0 steering
net/mlx4: Refactor QUERY_PORT
net/mlx4_core: Add explicit error message when rule doesn't meet configuration
net/mlx4: Add A0 hybrid steering
net/mlx4: Add mlx4_bitmap zone allocator
net/mlx4: Add a check if there are too many reserved QPs
net/mlx4: Change QP allocation scheme
net/mlx4_core: Use tasklet for user-space CQ completion events
net/mlx4_core: Mask out host side virtualization features for guests
net/mlx4_en: Set csum level for encapsulated packets
be2net: Export tunnel offloads only when a VxLAN tunnel is created
gianfar: Fix dma check map error when DMA_API_DEBUG is enabled
cxgb4/csiostor: Don't use MASTER_MUST for fw_hello call
net: fec: only enable mdio interrupt before phy device link up
net: fec: clear all interrupt events to support i.MX6SX
net: fec: reset fep link status in suspend function
net: sock: fix access via invalid file descriptor
net: introduce helper macro for_each_cmsghdr
...
Since we got rid of ordered tag support in 2010 the prime use case of
switching on and off ordered tags has been obsolete. The other function
of enabling/disabling tagging entirely has only been correctly implemented
by the 53c700 driver and isn't generally useful.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com
Reviewed-by: Hannes Reinecke <hare@suse.de>
Drop the now unused reason argument from the ->change_queue_depth method.
Also add a return value to scsi_adjust_queue_depth, and rename it to
scsi_change_queue_depth now that it can be used as the default
->change_queue_depth implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Hannes Reinecke <hare@suse.de>
All drivers use the implementation for ramping the queue up and down, so
instead of overloading the change_queue_depth method call the
implementation diretly if the driver opts into it by setting the
track_queue_depth flag in the host template.
Note that a few drivers validated the new queue depth in their
change_queue_depth method, but as we never go over the queue depth
set during slave_configure or the sysfs file this isn't nessecary
and can safely be removed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Venkatesh Srinivas <venkateshs@google.com>
Always returns the same skb it gets, so change to void.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Allow a driver to ask for block layer tags by setting .use_blk_tags in the
host template, in which case it will always see a valid value in
request->tag, similar to the behavior when using blk-mq. This means even
SCSI "untagged" commands will now have a tag, which is especially useful
when using a host-wide tag map.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Most drivers use exactly the same implementation, so provide it as a
library function.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Mike Christie <michaelc@cs.wisc.edu>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Subsystems that want to register CPU hotplug callbacks, as well as perform
initialization for the CPUs that are already online, often do it as shown
below:
get_online_cpus();
for_each_online_cpu(cpu)
init_cpu(cpu);
register_cpu_notifier(&foobar_cpu_notifier);
put_online_cpus();
This is wrong, since it is prone to ABBA deadlocks involving the
cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently
with CPU hotplug operations).
Instead, the correct and race-free way of performing the callback
registration is:
cpu_notifier_register_begin();
for_each_online_cpu(cpu)
init_cpu(cpu);
/* Note the use of the double underscored version of the API */
__register_cpu_notifier(&foobar_cpu_notifier);
cpu_notifier_register_done();
Fix the fcoe code in scsi by using this latter form of callback registration.
Cc: Robert Love <robert.w.love@intel.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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>
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>
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 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>
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.
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJR4NdLAAoJEDeqqVYsXL0MgLcIAIMpnHPPO0xTB1brAhIA2r4H
MHcD3/iRu+b+YuzEOuErw+pNzsAUGG9MD1b4m74qZ4z9PaVl4U0lWt61++P/OW91
ZD9TAF70t+3/R6Wz2eZp8WqmgWkLcEu9wDQxJKGPCcyWB9MphbsxaakM60B1swCy
5H3VGBWOy8MieLCHzdYgXfB83fnSy/75h/jErDiNwoEUuRci0rb9yOtpNamXPOiB
2JpW8hegixdup6srt+4Uq3gSWKJhqV1MD3leu6i3cHmoqTGueCX46patqlciSLRo
lN8fB3RgZjtIj8zattaeaGchEUMAE7yKcbjC+LyGPQe3+DKVutGNrEFT68KKRcQ=
=7slg
-----END PGP SIGNATURE-----
Merge tag 'scsi-for-linus' of 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
...
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>
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 86a9bad3ab
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>
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>
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>
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>
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>
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>
The libfc is used by fcoe but fcoe agnostic,
and therefore should not have any fcoe references.
So renaming fcoe_dev_stats from libfc as its for fc_stats.
After that libfc is fcoe string free except some strings for
Open-FCoE.org.
Signed-off-by: Vasu Dev <vasu.dev@intel.com>
Acked-by : Robert Love <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Acked-by: Bhanu Prakash Gollapudi <bprakash@broadcom.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
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 <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
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 <robert.w.love@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
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 <dan.carpenter@oracle.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
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:
-> #1 (&fip->ctlr_mutex){+.+...}:
[<c1091f70>] lock_acquire+0x80/0x1b0
[<c147655d>] mutex_lock_nested+0x6d/0x340
[<f8970c32>] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
[<f894620e>] fcoe_create+0x47e/0x6e0 [fcoe]
[<f8973dd3>] fcoe_transport_create+0x143/0x250 [libfcoe]
[<c10527e0>] param_attr_store+0x30/0x60
[<c1052696>] module_attr_store+0x26/0x40
[<c11a201e>] sysfs_write_file+0xae/0x100
[<c11449df>] vfs_write+0x8f/0x160
[<c1144cbd>] sys_write+0x3d/0x70
[<c147a0c4>] syscall_call+0x7/0xb
-> #0 (rtnl_mutex){+.+.+.}:
[<c109164b>] __lock_acquire+0x140b/0x1720
[<c1091f70>] lock_acquire+0x80/0x1b0
[<c147655d>] mutex_lock_nested+0x6d/0x340
[<c13a10c4>] rtnl_lock+0x14/0x20
[<f89445ac>] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
[<f8971712>] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
[<c104fb69>] process_one_work+0x179/0x5d0
[<c10502f1>] worker_thread+0x121/0x2d0
[<c10550ed>] kthread+0x7d/0x90
[<c1481a82>] kernel_thread_helper+0x6/0x10
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fip->ctlr_mutex);
lock(rtnl_mutex);
lock(&fip->ctlr_mutex);
lock(rtnl_mutex);
*** DEADLOCK ***
Signed-off-by: Robert Love <robert.w.love@intel.com>
Tested-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
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 <vasu.dev@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
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 <vasu.dev@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJPdrIWAAoJEDeqqVYsXL0Mny4IAMTzXGOXCykpWhdIe2R8w0Ys
eIoTJhBKoQWnLTV8cOODtwmtZcoQLeXkZmizZiAJvX6O1tOgueg+W4AFa9grxXGI
O0d1bSb2ardzU7VZrZSY60Hd4bylMwn4Xv/0dRrQMwTJO0LEeGWsJPV2+2BuXwMB
lGCNB67oUBXgMOI1jUZQRwx/mBzQ3e/gINjnpZTNKHia7YkX/yVTFISq7htgfDN7
1wRGxymbHtVap3NbtUO96BUUndAiF5vom+4WNvaQUyPrCc6aoGWjv+J9DQXY/zgv
AYjujAluK396D6YncGFAWBzYOg9WFbq54v0PRUanjcTTAu5ILs2BxqWdhmnvl14=
=IH8T
-----END PGP SIGNATURE-----
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
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->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]
...
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:
-> #1 (&fip->ctlr_mutex){+.+...}:
[<c1091f70>] lock_acquire+0x80/0x1b0
[<c147655d>] mutex_lock_nested+0x6d/0x340
[<f8970c32>] fcoe_ctlr_link_up+0x22/0x180 [libfcoe]
[<f894620e>] fcoe_create+0x47e/0x6e0 [fcoe]
[<f8973dd3>] fcoe_transport_create+0x143/0x250 [libfcoe]
[<c10527e0>] param_attr_store+0x30/0x60
[<c1052696>] module_attr_store+0x26/0x40
[<c11a201e>] sysfs_write_file+0xae/0x100
[<c11449df>] vfs_write+0x8f/0x160
[<c1144cbd>] sys_write+0x3d/0x70
[<c147a0c4>] syscall_call+0x7/0xb
-> #0 (rtnl_mutex){+.+.+.}:
[<c109164b>] __lock_acquire+0x140b/0x1720
[<c1091f70>] lock_acquire+0x80/0x1b0
[<c147655d>] mutex_lock_nested+0x6d/0x340
[<c13a10c4>] rtnl_lock+0x14/0x20
[<f89445ac>] fcoe_update_src_mac+0x2c/0xb0 [fcoe]
[<f8971712>] fcoe_ctlr_timer_work+0x712/0xb60 [libfcoe]
[<c104fb69>] process_one_work+0x179/0x5d0
[<c10502f1>] worker_thread+0x121/0x2d0
[<c10550ed>] kthread+0x7d/0x90
[<c1481a82>] kernel_thread_helper+0x6/0x10
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&fip->ctlr_mutex);
lock(rtnl_mutex);
lock(&fip->ctlr_mutex);
lock(rtnl_mutex);
*** DEADLOCK ***
Signed-off-by: Robert Love <robert.w.love@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
There is potentially lots of contention for the rx_list_lock. On a cpu that is
receiving lots of fcoe traffic, the softirq context has to add and release the
lock for every frame it receives, as does the receiving per-cpu thread. We can
reduce this contention somewhat by altering the per-cpu threads loop such that
when traffic is detected on the fcoe_rx_list, we splice it to a temporary list.
In this way, we can process multiple skbs while only having to acquire and
release the fcoe_rx_list lock once.
[ Braces around single statement while loop removed by Robert Love
to satisfy checkpath.pl. ]
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>
commit e7a51997da ([SCSI] fcoe: flush per-cpu
thread work when destroying interface) added a skb flush to the fcoe_rx_list,
which ensures that we push any pending frames on the list through the per-cpu
receive thread. Because of this, its redundant to lock and scan the list
first, dropping any arriving frames.
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>
The fcoe sw recive packet function (fcoe_rcv) only ever executes in softirq
context. Given that, and the fact that no use of the fcoe_rx_list is made in
irq context, its not necessecary to disable bottom halves while actually
receiving the frame. Convert spin_*_bh calls in that function to their
lock-only equivalents
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>
commit 859b7b649a introduced the ability to call
fcoe_recv_frame in softirq context. While this is beneficial to performance,
its not safe to do, as it breaks the serialization of access to the lport
structure (i.e. when an fcoe interface is being torn down, theres no way to
serialize the teardown effort with the completion of receieve operations
occuring in softirq context. As a result, lport (and other) data structures can
be read and modified in parallel leading to corruption. Most notable is the
vport list, which is protected by a mutex, that will cause a panic if a softirq
receive while said mutex is locked. Additionaly, the ema_list, discussed here:
http://lists.open-fcoe.org/pipermail/devel/2012-February/011947.html
Can be corrupted if a list traversal occurs in softirq context at the same time
as a list delete in process context. And generally the lport state variables
will not be stable, and may lead to unpredictable results.
The most direct fix is to remove the bits from the above commit that allowed
fcoe_recv_frame to be called in softirq context. We just force all frames to be
handled by the per-cpu rx threads. This will allow the fcoe_if_destroy's use of
fcoe_percpu_clean to function properly, ensuring that no frames are being
received while the lport is being torn down.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJPZxSnAAoJEDeqqVYsXL0M0Y4IAMX0vrTVZbg6psA5/gMcWGRP
CkFXEQ8n0PL2SCaj6BoDqamJFe5Nc7dnqxM0fGawB4S9vr3rHhiOlwO+NbV9zFYC
2skBTpeL3sjgtN/jTBdfeeAa7xTYpu/XGyei0NS1A5c2AyMVXV0uYV2s4VNZxe44
tVIn1OEzM2giZ9EB1OZslDMrg5XXm3MBIUECP0LbWUhBm/35caSFKzMXRwhh7WiK
+AVmc2AZYtdEwuknDyiH7KlsaoB3vGL9pPrAUJzIgEhy2pOo2A7W72HfA4Fj+y6a
uF9HBS5zciMp1+sGWry62AjNbWgin9BRlozBEO/lJhIfMGDV1nXEIJsOkOgkdoE=
=1TxB
-----END PGP SIGNATURE-----
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
SCSI updates from James Bottomley:
"The update includes the usual assortment of driver updates (lpfc,
qla2xxx, qla4xxx, bfa, bnx2fc, bnx2i, isci, fcoe, hpsa) plus a huge
amount of infrastructure work in the SAS library and transport class
as well as an iSCSI update. There's also a new SCSI based virtio
driver."
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6: (177 commits)
[SCSI] qla4xxx: Update driver version to 5.02.00-k15
[SCSI] qla4xxx: trivial cleanup
[SCSI] qla4xxx: Fix sparse warning
[SCSI] qla4xxx: Add support for multiple session per host.
[SCSI] qla4xxx: Export CHAP index as sysfs attribute
[SCSI] scsi_transport: Export CHAP index as sysfs attribute
[SCSI] qla4xxx: Add support to display CHAP list and delete CHAP entry
[SCSI] iscsi_transport: Add support to display CHAP list and delete CHAP entry
[SCSI] pm8001: fix endian issue with code optimization.
[SCSI] pm8001: Fix possible racing condition.
[SCSI] pm8001: Fix bogus interrupt state flag issue.
[SCSI] ipr: update PCI ID definitions for new adapters
[SCSI] qla2xxx: handle default case in qla2x00_request_firmware()
[SCSI] isci: improvements in driver unloading routine
[SCSI] isci: improve phy event warnings
[SCSI] isci: debug, provide state-enum-to-string conversions
[SCSI] scsi_transport_sas: 'enable' phys on reset
[SCSI] libsas: don't recover end devices attached to disabled phys
[SCSI] libsas: fixup target_port_protocols for expanders that don't report sata
[SCSI] libsas: set attached device type and target protocols for local phys
...
Pull kmap_atomic cleanup from Cong Wang.
It's been in -next for a long time, and it gets rid of the (no longer
used) second argument to k[un]map_atomic().
Fix up a few trivial conflicts in various drivers, and do an "evil
merge" to catch some new uses that have come in since Cong's tree.
* 'kmap_atomic' of git://github.com/congwang/linux: (59 commits)
feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal
highmem: kill all __kmap_atomic() [swarren@nvidia.com: highmem: Fix ARM build break due to __kmap_atomic rename]
drbd: remove the second argument of k[un]map_atomic()
zcache: remove the second argument of k[un]map_atomic()
gma500: remove the second argument of k[un]map_atomic()
dm: remove the second argument of k[un]map_atomic()
tomoyo: remove the second argument of k[un]map_atomic()
sunrpc: remove the second argument of k[un]map_atomic()
rds: remove the second argument of k[un]map_atomic()
net: remove the second argument of k[un]map_atomic()
mm: remove the second argument of k[un]map_atomic()
lib: remove the second argument of k[un]map_atomic()
power: remove the second argument of k[un]map_atomic()
kdb: remove the second argument of k[un]map_atomic()
udf: remove the second argument of k[un]map_atomic()
ubifs: remove the second argument of k[un]map_atomic()
squashfs: remove the second argument of k[un]map_atomic()
reiserfs: remove the second argument of k[un]map_atomic()
ocfs2: remove the second argument of k[un]map_atomic()
ntfs: remove the second argument of k[un]map_atomic()
...
Vaishali Thakkar