Jacob Keller [Fri, 11 Nov 2016 20:39:37 +0000 (12:39 -0800)]
i40e: when adding or removing MAC filters, correctly handle VLANs
Instead of using i40e_add_filter or i40e_del_filter directly, when
adding a MAC address, we should normally be using i40e_add_mac_filter or
i40e_del_mac_filter. These functions correctly handle the various cases
of VLAN mode or PVID settings. This ensures consistency and avoids the
issues that can occur with the recent addition of a WARN_ON() in
i40e_sync_vsi_filters.
Change-ID: I7fe62db063391fdd1180b2d6a6a3c5ab4307eeee Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 9569a9a4547d5636827c3f6b09be73ed924b1d16) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:36 +0000 (12:39 -0800)]
i40e: avoid O(n^2) loop when deleting all filters
Use __i40e_del_filter instead of using i40e_del_filter() which will
avoid doing an additional search to delete a filter we already have the
pointer for.
Change-ID: Iea5a7e3cafbf8c682ed9d3b6c69cf5ff53f44daf Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 148141bb26cf942e6bc7249c55d9958dd62dd4f2) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:35 +0000 (12:39 -0800)]
i40e: rename i40e_put_mac_in_vlan and i40e_del_mac_all_vlan
These functions purpose is to add a new MAC filter correctly, whether
we're using VLANs or not. Their goal is to ensure that all active VLANs
get the new MAC filter. Rename them so that their intent is clear. They
function correctly regardless of whether we have any active VLANs or
only have I40E_VLAN_ANY filters. The new names convey how they function
in a more clear manner.
Change-ID: Iec1961f968c0223a7132724a74e26a665750b107 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit feffdbe47d6f4c02b5e2764e14490c5f9d250bdb) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:34 +0000 (12:39 -0800)]
i40e: no need to check is_vsi_in_vlan before calling i40e_del_mac_all_vlan
This function won't be appreciably slower when in VLAN mode, so there is
no real reason to not just call it directly. In either case, we still
must search the full table for a MAC/VLAN pair. We do get to stop
searching a tiny bit early in the case of knowing we are not in VLAN
mode, but this is a minor savings and we can avoid the code complexity
by not having to worry about the check.
Change-ID: I533412195b3a42f51cf629e3675dd5145aea8625 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit d983001f044cf823490af7dcfcde39cfb42be0db) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Fri, 11 Nov 2016 20:39:33 +0000 (12:39 -0800)]
i40e: fold the i40e_is_vsi_in_vlan check into i40e_put_mac_in_vlan
Fold the check for determining when to call i40e_put_mac_in_vlan directly
into the function so that we don't need to decide which function to use
ahead of time. This allows us to just call i40e_put_mac_in_vlan directly
without having to check ahead of time.
Change-ID: Ifff526940748ac14b8418be5df5a149502eed137 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 7aaf9536c45021772a5bc6cd4b620a11eac750f7) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Jacob Keller [Wed, 7 Dec 2016 22:05:34 +0000 (14:05 -0800)]
i40e: don't allow i40e_vsi_(add|kill)_vlan to operate when VID<1
Now that we have the separate i40e_(add|rm)_vlan_all_mac functions, we
should not be using the i40e_vsi_kill_vlan or i40e_vsi_add_vlan
functions when PVID is set or when VID is less than 1. This allows us to
remove some checks in i40e_vsi_add_vlan and ensures that callers which
need to handle VID=0 or VID=-1 don't accidentally invoke the VLAN mode
handling used to convert filters when entering VLAN mode. We also update
the functions to take u16 instead of s16 as well since they no longer
expect to be called with VID=I40E_VLAN_ANY.
Change-ID: Ibddf44a8bb840dde8ceef2a4fdb92fd953b05a57 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit f94484b7584765eebded5d7bfdeb0b2c7b1caf51) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Bimmy Pujari [Tue, 8 Nov 2016 21:05:19 +0000 (13:05 -0800)]
i40e: Changed version from 1.6.21 to 1.6.25
Signed-off-by: Bimmy Pujari <bimmy.pujari@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Orabug: 26132523
(cherry picked from commit 360238693d2bc93fb6ff73146ed358e84fe67961) Signed-off-by: Jack Vogel <jack.vogel@oracle.com> Reviewed-by: Brian Maly <brian.maly@oracle.com>
Sowmini Varadhan [Wed, 7 Jun 2017 21:09:38 +0000 (14:09 -0700)]
rds: tcp: fix memory leak in TIME_WAIT sockets
Due to a toxic cocktail of an endian-ness bug, plus some other changes
in mprds to make sure that the side with the numerically smaller address
must initiate the tcp connection, end result is an infinite connection
attempt and a memory leak in TIME_WAIT sockets.
Sowmini Varadhan [Wed, 31 May 2017 19:11:20 +0000 (12:11 -0700)]
rds: tcp: canonical connection order for all paths with index > 0
The rds_connect_worker() has a bug in the check that enforces the
canonical connection order described in the comments of
rds_tcp_state_change(). The intention is to make sure that all
the multipath connections are always initiated by the smaller IP
address via rds_start_mprds. To achieve this, rds_connection_worker
should check that cp_index > 0.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Sowmini Varadhan [Wed, 31 May 2017 19:08:34 +0000 (12:08 -0700)]
rds: tcp: allow progress of rds_conn_shutdown if the rds_connection is marked ERROR by an intervening FIN
rds_conn_shutdown() runs in workq context, and marks the rds_connection
as DISCONNECTING before quiescing Tx/Rx paths. However, after all I/O
has quiesced, we may still find the rds_connection state to be
RDS_CONN_ERROR if an intervening FIN was processed in softirq context.
This is not a fatal error: rds_conn_shutdown() should continue the
shutdown, and there is no need to log noisy messages about this event.
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Wei Lin Guay [Wed, 7 Dec 2016 08:08:09 +0000 (09:08 +0100)]
IB/cm: remove unnecessary ib_query_device in PSIF RNR WA
The query device is performed in CM REQ/REP to retrieve the
vendorID of the sif device. This operation is illegal because
it is calling a sleeping function (ib_query_device) from
a non-sleepable context. Thus, this patch removes this illegal
call and reuses the cached vendorID/DeviceID in the pci_dev
data structure.
James Smart [Fri, 21 Apr 2017 23:05:05 +0000 (16:05 -0700)]
Fix Express lane queue creation.
The older sli4 adapters only supported the 64 byte WQE entry size.
The new adapter (fw) support both 64 and 128 byte WQE entry sizies.
The Express lane WQ was not being created with the 128 byte WQE sizes
when it was supported.
Not having the right WQE size created for the express lane work queue
caused the the firmware to overwrite the lun indentifier in the FCP header.
This patch correctly creates the express lane work queue with the
supported size.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by: James Smart <james.smart@broadcom.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
(cherry picked from commit 7e04e21afa82ef024416f5413b5bdb66e0505bcd)
Hou Tao [Fri, 3 Feb 2017 22:39:07 +0000 (14:39 -0800)]
xfs: reset b_first_retry_time when clear the retry status of xfs_buf_t
After successful IO or permanent error, b_first_retry_time also
needs to be cleared, else the invalid first retry time will be
used by the next retry check.
Signed-off-by: Hou Tao <houtao1@huawei.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
(cherry picked from commit 4dd2eb633598cb6a5a0be2fd9a2be0819f5eeb5f)
Carlos Maiolino [Wed, 4 Jan 2017 04:34:17 +0000 (20:34 -0800)]
xfs: fix max_retries _show and _store functions
max_retries _show and _store functions should test against cfg->max_retries,
not cfg->retry_timeout
Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
(cherry picked from commit ff97f2399edac1e0fb3fa7851d5fbcbdf04717cf)
Eric Sandeen [Tue, 13 Sep 2016 21:51:30 +0000 (07:51 +1000)]
xfs: normalize "infinite" retries in error configs
As it stands today, the "fail immediately" vs. "retry forever"
values for max_retries and retry_timeout_seconds in the xfs metadata
error configurations are not consistent.
A retry_timeout_seconds of 0 means "retry forever," but a
max_retries of 0 means "fail immediately."
retry_timeout_seconds < 0 is disallowed, while max_retries == -1
means "retry forever."
Make this consistent across the error configs, such that a value of
0 means "fail immediately" (i.e. wait 0 seconds, or retry 0 times),
and a value of -1 always means "retry forever."
This makes retry_timeout a signed long to accommodate the -1, even
though it stores jiffies. Given our limit of a 1 day maximum
timeout, this should be sufficient even at much higher HZ values
than we have available today.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 77169812739dd800bc3620d781a77c50c75165cc)
Eric Sandeen [Wed, 20 Jul 2016 00:54:09 +0000 (10:54 +1000)]
xfs: don't reset b_retries to 0 on every failure
With the code as it stands today, b_retries never increments because
it gets reset to 0 in the error callback.
Remove that, and fix a similar problem where the first retry time
was constantly being overwritten, which defeated the timeout tunable
as well. We now only set first retry time if a non-zero timeout is
set, to match the behavior of only incrementing retries if a retry
value is set.
This way max retries & timeouts consistently take effect after a
tunable is set, rather than acting retroactively on a buffer which
has failed at some point in the past and has accumulated state from
those prior failures.
Thanks to dchinner for talking through this with me.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 5539d36752eb789f4067a9f88e72177895d56317)
Eric Sandeen [Wed, 20 Jul 2016 00:48:51 +0000 (10:48 +1000)]
xfs: fix xfs_error_get_cfg for negative errnos
xfs_error_get_cfg() is called with bp->b_error as an arg, which is
negative, so the switch statement won't ever find any matches.
This results in only the default error handler having any effect, as
EIO/ENOSPC/ENODEV get ignored due to the wrong sign.
It seems simplest to always flip the error sign to positive, so that
we can handle either negative errors in bp->b_error, or possibly a
positive errno via something like xfs_error_get_cfg(EIO) - this
future-proofs the function.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e97f6c545f963abd7de56a58a29ba73a9edee015)
Carlos Maiolino [Wed, 18 May 2016 01:11:27 +0000 (11:11 +1000)]
xfs: add "fail at unmount" error handling configuration
If we take "retry forever" literally on metadata IO errors, we can
hang at unmount, once it retries those writes forever. This is the
default behavior, unfortunately.
Add an error configuration option for this behavior and default it
to "fail" so that an unmount will trigger actuall errors, a shutdown
and allow the unmount to succeed. It will be noisy, though, as it
will log the errors and shutdown that occurs.
To fix this, we need to mark the filesystem as being in the process
of unmounting. Do this with a mount flag that is added at the
appropriate time (i.e. before the blocking AIL sync). We also need
to add this flag if mount fails after the initial phase of log
recovery has been run.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e6b3bb78962e65c4ad125598755cfbf2a8779e86)
Carlos Maiolino [Wed, 18 May 2016 01:09:28 +0000 (11:09 +1000)]
xfs: add configuration handlers for specific errors
now most of the infrastructure is in place, we can start adding
support for configuring specific errors such as ENODEV, ENOSPC, EIO,
etc. Add these error configurations and configure them all to have
appropriate behaviours. That is, all will be configured to retry
forever by default, except for ENODEV, which is an unrecoverable
error, so it will be configured to not retry on error
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit e0a431b3a3cc3d0a4c38ccfca8c7320fde40efb6)
Carlos Maiolino [Wed, 18 May 2016 01:08:15 +0000 (11:08 +1000)]
xfs: add configuration of error failure speed
On reception of an error, we can fail immediately, perform some
bound amount of retries or retry indefinitely. The current behaviour
we have is to retry forever.
However, we'd like the ability to choose how long the filesystem
should try after an error, it can either fail immediately, retry a
few times, or retry forever. This is implemented by using
max_retries sysfs attribute, to hold the amount of times we allow
the filesystem to retry after an error. Being -1 a special case
where the filesystem will retry indefinitely.
Add both a maximum retry count and a retry timeout so that we can
bound by time and/or physical IO attempts.
Finally, plumb these into xfs_buf_iodone error processing so that
the error behaviour follows the selected configuration.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit a5ea70d25d76950e11690110b526374307d05d81)
Carlos Maiolino [Wed, 18 May 2016 01:06:44 +0000 (11:06 +1000)]
xfs: introduce table-based init for error behaviors
Before we start expanding the number of error classes and errors we
can configure behaviour for, we need a simple and clear way to
define the default behaviour that we initialized each mount with.
Introduce a table based method for keeping the initial configuration
in, and apply that to the existing initialization code.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit ef6a50fbb1bba7951aa23adcfb40e99ca72dc51c)
Carlos Maiolino [Wed, 18 May 2016 01:05:33 +0000 (11:05 +1000)]
xfs: add configurable error support to metadata buffers
With the error configuration handle for async metadata write errors
in place, we can now add initial support to the IO error processing
in xfs_buf_iodone_error().
Add an infrastructure function to look up the configuration handle,
and rearrange the error handling to prepare the way for different
error handling conigurations to be used.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit df3093907ccc718459c54c99da29dd774af41186)
Carlos Maiolino [Wed, 18 May 2016 01:01:00 +0000 (11:01 +1000)]
xfs: introduce metadata IO error class
Now we have the basic infrastructure, add the first error class so
we can build up the infrastructure in a meaningful way. Add the
metadata async write IO error class and sysfs entry, and introduce a
default configuration that matches the existing "retry forever"
behavior for async write metadata buffers.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit ffd40ef697dfd3e06f44b1bb5fea93079de8c77d)
Carlos Maiolino [Wed, 18 May 2016 00:58:51 +0000 (10:58 +1000)]
xfs: configurable error behavior via sysfs
We need to be able to change the way XFS behaviours in error
conditions depending on the type of underlying storage. This is
necessary for handling non-traditional block devices with extended
error cases, such as thin provisioned devices that can return ENOSPC
as an IO error.
Introduce the basic sysfs infrastructure needed to define and
configure error behaviours. This is done to be generic enough to
extend to configuring behaviour in other error conditions, such as
ENOMEM, which also has different desired behaviours according to
machine configuration.
Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com>
(cherry picked from commit 192852be8b5fb14268c2133fe9ce5312e4745963)
Mike Kravetz [Fri, 2 Jun 2017 21:51:12 +0000 (14:51 -0700)]
sparc64: mm: fix copy_tsb to correctly copy huge page TSBs
When a TSB grows beyond its current capacity, a new TSB is allocated
and copy_tsb is called to copy entries from the old TSB to the new.
A hash shift based on page size is used to calculate the index of an
entry in the TSB. copy_tsb has hard coded PAGE_SHIFT in these
calculations. However, for huge page TSBs the value REAL_HPAGE_SHIFT
should be used. As a result, when copy_tsb is called for a huge page
TSB the entries are placed at the incorrect index in the newly
allocated TSB. When doing hardware table walk, the MMU does not
match these entries and we end up in the TSB miss handling code.
This code will then create and write an entry to the correct index
in the TSB. We take a performance hit for the table walk miss and
recreation of these entries.
Pass a new parameter to copy_tsb that is the page size shift to be
used when copying the TSB.
Suggested-by: Anthony Yznaga <anthony.yznaga@oracle.com> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from Linus repo on 7 July 2017
commit 654f4807624a657f364417c2a7454f0df9961734) Reviewed-by: Steve Sistare steven.sistare@oracle.com Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
IB/mlx4: Fix incorrect order of formal and actual parameters
The last two actual parameters when calling id_map_find_by_sl_id()
from id_map_get() are swapped. However, the same formal parameters to
id_map_get() have them swapped as well, inverting the effect of the
first error.
This commit improves readability, but makes no functional change to
the code.
Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com> Reviewed-by: Wengang Wang <wen.gang.wang@oracle.com> Reviewed-by: Knut Omang <knut.omang@oracle.com> Acked-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
(cherry picked from commit b03ee4ca0cec348c84dccf08aaec2454c4d236c2)
Now that we're guaranteed to have a meaningful root dentry, we can just
export seq_dentry() and use it in btrfs_show_options(). The subvolume ID
is easy to get and can also be useful, so put that in there, too.
Reviewed-by: David Sterba <dsterba@suse.cz> Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Chris Mason <clm@fb.com>
(cherry picked from commit c8d3fe028f64054d75c72566efb9ecf3c75ee161) Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Current sense_len checks for size of cp->sense_buffer which is of type
pointer. Passing truncated sense data(size of pointer) to upper scsi
layers(aula) is causing delay in discovering FC LUN's.
Fixed sense_len assignment to SCSI_SENSE_BUFFERSIZE, this resolved
delay in discovering FC LUN's.
As part of updating NVMe driver (Bug 25130845), the nvme device mapping was done
before getting the nvme device information. This change got introduced while
resolving a merge conflict. This caused the kernel panic during nvme probe.
Signed-off-by: Ashok Vairavan <ashok.vairavan@oracle.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Thomas Tai [Fri, 6 Jan 2017 14:18:38 +0000 (06:18 -0800)]
sparc: Fix kernel BUG at arch/sparc/kernel/mdesc.c
When running ldoms reboot test for long hours, ldom guest panic with
kernel BUG at arch/sparc/kernel/mdesc.c:176! It is because the mdesc
size has changed, mdesc_update should retry the operation by decrement
refcnt before mdesc_free.
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-By: Liam Merwick <Liam.Merwick@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Signed-off-by: Thomas Tai <thomas.tai@oracle.com> Reviewed-by: Chris Hyser <chris.hyser@oracle.com> Reviewed-by: Liam Merwick <liam.merwick@oracle.com> Signed-off-by: Allen Pais <allen.pais@oracle.com>
Shamir Rabinovitch [Tue, 14 Mar 2017 16:35:27 +0000 (09:35 -0700)]
sparc64/mlx4_core: relaxed order for mlx4_core dma mappings
SPARC PCI require relaxed order PCI transactions from the HCA to the
host memory to enable maximum performance. CX3 is not capable of setting
the relaxed order for the PCI transactions. Only mlx4_core driver can set
relaxed order on the right DMA mappings. Fix it!
This is temporary fix only for UEK4. Upstream changed the way the IB
subsystem work with DMA and upstreaming of this fix requires first to
fix net-next tree panic when rdma service is started (Orabug 25760394)
and only then upstreaming the fix for the SPARC/CX3 performance issue.
This cannot be done in short time and require back-port of lots of
upstream code introduced with upstream commit: "Merge tag
'for-next-dma_ops' of
git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma".
The current decision is to limit the change to mlx4 drivers and the ULPs
that use it. This patch only override the mlx4 DMA functions as opposed
for doing this from ib_verbs DMA functions.
This patch is already used in UEK2/SPARC and was proven as working under
all the product testing and so it is ported as-is.
IOCTL for ccb submission failed due to get_user_pages error should
return EFAULT instead of EPERM. This was a regression introduced by a
prior patch that cleaned up a few functions in this code path.
Reviewed-by: Shannon Nelson <shannon.nelson@oracle.com> Signed-off-by: Sanath Kumar <sanath.s.kumar@oracle.com>
Anthony Yznaga [Wed, 31 May 2017 19:34:59 +0000 (12:34 -0700)]
sparc64: fix M8 ADI support
For platforms that support ADI two things must be done during boot.
First, etrap is patched to ensure that execution in the kernel runs with
PSTATE.mcde=1. This ensures that version checking is enabled if the
kernel accesses ADI-enabled user memory through copy_{to/from}_user,
etc..
Second, the initialization of the common flags used in TTEs must be
adjusted to not set TTE.cv (cacheable-in-virtually-indexed-cache) which
has been replaced by TTE.mcd which enables MCD (aka ADI).
These steps are currently done for M7. This patch adds support for M8
and does some minor cleanup to avoid M7-specific naming and reduce the
number of places chip type needs to be checked (and adjusted in the
future).
Orabug: 26096575 Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com> Reviewed-by: Steve Sistare <steven.sistare@oracle.com>
Return value check of atomic_dec_if_positive is required as it returns
old value minus one. Without this fix, driver will send small ios to
firmware path and that will be a performance issue.
Not critical, but good to have r1_ldio_hint as default value in sdev
private.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 49524b3c6e12375627ddd870613fcc6b24909898) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
For RAID1 FastPath writes, driver needs to allocate extra commands
internally to accommodate for the extra peer command being sent.
Currently driver is allocating 2 extra commands for each but only one
extra command is necessary. Set RAID_1_10_RMW_CMDS to 2 and also change
macro name to RAID_1_PEER_CMDS.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a73b0a4b5d17ee39b2cbac7638a97077189b80cc) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Fix indentation issues and smatch warning reported by Dan Carpenter
for previous series as discussed below.
http://www.spinics.net/lists/linux-scsi/msg103635.html
http://www.spinics.net/lists/linux-scsi/msg103603.html
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 41064f1bf8886bc43afbd9aa23a698f97bc65664) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Fix to account for the reply_q_sz not exceeding the maximum commands
that the firmware can support, instance->max_fw_cmds is already
decremented in megasas_fusion_update_can_queue(). Remove the extra
decrement logic in code.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit cf4e55e7be0a4c009908803ff4c3140c9822c033) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Issue is limited for Syncro firmware where pd_after_lb is not set but is
accidentally used. Not a functional issue, but results in low
performance due to improper load balancing between two LUNs.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit b41c0a4aa7c0fc1f98648c020358598498d48f06) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Conflicts:
drivers/scsi/megaraid/megaraid_sas_fp.c
Fetch the latest controller OCR capability from FW before sending
MR_DCMD_CTRL_SHUTDOWN When application sends a shutdown DCMD
(MR_DCMD_CTRL_SHUTDOWN), driver will fetch latest controller information
from firmware. This is to ensure that driver always has latest OCR
capability of controller before sending the DCMD.
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 95c060869e6872ea03a4a9d15236adcffb1d8b07) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Change MR_TargetIdToLdGet return type from u8 to u16.
ld id range check is added at two places in this patch -
@megasas_build_ldio_fusion and @megasas_build_ld_nonrw_fusion. Previous
driver code used different data type for lds TargetId returned from
MR_TargetIdToLdGet. Prior to this change, above two functions was
safeguarded due to function always return u8 and maximum value of ld id
returned was 255.
In below check, fw_supported_vd_count as of today is 64 or 256 and valid
range to support is either 0-63 or 0-255. Ideally want to filter
accessing raid map for ld ids which are not valid. With the u16 change,
invalid ld id value is 0xFFFF and we will see kernel panic due to random
memory access in MR_LdRaidGet. The changes will ensure we do not call
MR_LdRaidGet if ld id is beyond size of ldSpanMap array.
if (ld < instance->fw_supported_vd_count)
>From firmware perspective,ld id 0xFF is invalid and even though current
driver code forward such command, firmware fails with target not
available.
ld target id issue occurs mainly whenever driver loops to populate raid
map (ea. MR_ValidateMapInfo). These are the only two places where we
may see out of range target ids and wants to protect raid map access
based on range provided by Firmware API.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit d2d0358bcd09139a8e71afbca35bcd6b219dd1bf) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
On a host, if an ld is deleted there is a hole in the ld array returned
by the FW. But in MR_ValidateMapInfo we are not accounting for holes in
the ld array and traverse only upto index num_lds. This patch takes
care of converting the capability field of all the valid lds in the ld
raid map.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a09454ce5dd11184c5040ed536d323e2a302a579) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Currently fusion context has fixed array load_balance_info. Use dynamic
allocation. In few places, driver do not want physically contigious
memory. Attempt to use vmalloc if physical contiguous memory is not
available.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 5fc499b612c5401a7ae0674086befcdf8b148516) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Conflicts:
drivers/scsi/megaraid/megaraid_sas.h
Avoid Host side PCI bandwidth bottleneck and hint FW to do Write
buffering using RaidFlag MR_RAID_FLAGS_IO_SUB_TYPE_LDIO_BW_LIMIT. Once
IO is landed in FW with MR_RAID_FLAGS_IO_SUB_TYPE_LDIO_BW_LIMIT, it will
do single DMA from host and buffer the Write operation. On back end, FW
will DMA same buffer to the Mirror and Data Arm. This will improve
large block IO performance which bottleneck due to Host side PCI
bandwidth limitation.
Consistent ~4000MB T.P for 256K Block size is expected performance
numbers. IOPS for small Block size should be on par with Disk
performance. (E.g 42 SAS Disk in JBOD mode gives 3700MB T.P. Same
Drive used in R1 WT mode, should give ~1800MB T.P)
Using this patch 24 R1 VDs (HDD) gives below performance for Sequential
Write. Without this patch, we cannot reach above 3200MB (Throughput is
in MB.)
With the changes to remove checks for a valid request descriptor,
issue_dcmd will now always return DCMD_SUCCESS. This patch changes
return type of issue_dcmd to void and change all callers appropriately.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit f4fc209326c79b03fecd38a6709cf08da47f15f7) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
No functional change. Code clean up. Removing error code which is not
valid scenario. In megasas_get_request_descriptor we can remove the
error handling which is not required. With fusion controllers, if there
is a valid message frame available, we are guaranteed to get a
corresponding request descriptor.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 52205ac8940b43cca1711abfb43a05e7df08c09e) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
megasas_fire_cmd_fusion can always use 32 bit descriptor write for
ventura. No need to pass extra flag. Only IOC INIT required 64 bit
Descriptor write.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 45b8a35eed7b1d7e51a4dc04b5b694301a383afa) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Remove function megasas_fpio_to_ldio as we never require to convert fpio
to ldio because of frame unavailability. Grab extra frame of raid 1
write fast path before it creates first frame as Fast Path. Removed
is_raid_1_fp_write flag as raid 1 write fast path command is decided
using r1_alt_dev_handle only. Move resetting megasas_cmd_fusion fields
at common function megasas_return_cmd_fusion.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 8bf7c65d379a6d923dfebb50eb04c2407e4762ed) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
This reverts commit "3e5eadb1a881" ("scsi: megaraid_sas: Enable or
Disable Fast path based on the PCI Threshold Bandwidth")
This patch was aimed to increase performance of R1 Write operation for
large IO size. Since this method used timer approach, it turn on/off
fast path did not work as expected. Patch 0013 describes new algorithm
and performance number.
Signed-off-by: Shivasharan S <shivasharan.srikanteshwara@broadcom.com> Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 18bbcabdc6cc6be8c7f6d80c85d314535d76188d) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
To improve RAID 1/10 Write performance, OS drivers need to issue the
required Write IOs as Fast Path IOs (after the appropriate checks
allowing Fast Path to be used) to the appropriate physical drives
(translated from the OS logical IO) and wait for all Write IOs to complete.
Design: A write IO on RAID volume will be examined if it can be sent in
Fast Path based on IO size and starting LBA and ending LBA falling on to
a Physical Drive boundary. If the underlying RAID volume is a RAID 1/10,
driver issues two fast path write IOs one for each corresponding physical
drive after computing the corresponding start LBA for each physical drive.
Both write IOs will have the same payload and are posted to HW such that
replies land in the same reply queue.
If there are no resources available for sending two IOs, driver will send
the original IO from SCSI layer to RAID volume through the Firmware.
Based on PCI bandwidth and write payload, every second this feature is
enabled/disabled.
When both IOs are completed by HW, the resources will be released
and SCSI IO completion handler will be called.
Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 69c337c0f8d74d71e085efa8869be9fc51e5962b) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Detect sequential Write IOs and pass the hint that it is part of sequential
stream to help HBA Firmware do the Full Stripe Writes. For read IOs on
certain RAID volumes like Read Ahead volumes,this will help driver to
send it to Firmware even if the IOs can potentially be sent to
hardware directly (called fast path) bypassing firmware.
Design: 8 streams are maintained per RAID volume as per the combined
firmware/driver design. When there is no stream detected the LRU stream
is used for next potential stream and LRU/MRU map is updated to make this
as MRU stream. Every time a stream is detected the MRU map
is updated to make the current stream as MRU stream.
Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit fdd84e2514b0157219720cf8f3f55757938a39cd) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
An UNMAP command on a PI formatted device will leave the Logical Block Application
Tag and Logical Block Reference Tag as all F's (for those LBAs that are unmapped).
To avoid IO errors if those LBAs are subsequently read before they are written with
valid tag fields, the MPI SCSI IO requests need to set the EEDPFlags element EEDP
Escape Mode field, Bits [7:6] appropriately. A value of 2 should be set to disable
all PI checks if the Logical Block Application Tag is 0xFFFF for PI types 1 and 2.
A value of 3 should be set to disable all PI checks if the Logical Block Application
Tag is 0xFFFF and the Logical Block Reference Tag is 0xFFFFFFFF for PI type 3.
Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 45d446038c7b93c40b2fe5ba0e95380f19e0493e) Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Signed-off-by: Kirtikar Kashyap <kirtikar.kashyap@oracle.com> Reviewed-by: Dhaval Giani <dhaval.giani@oracle.com>
Damien Le Moal [Wed, 1 Mar 2017 08:27:00 +0000 (17:27 +0900)]
scsi: sd: Check for unaligned partial completion
Commit <f2e767bb5d6e> ("mpt3sas: Force request partial completion
alignment") was not considering the case of commands not operating on
logical block size units (e.g. REQ_OP_ZONE_REPORT and its 64B aligned
partial replies). In this case, forcing alignment of resid to the device
logical block size can break the command result, e.g. in the case of
REQ_OP_ZONE_REPORT, the exact number of zone reported by the device.
Move the partial completion alignement check of mpt3sas to a generic
implementation in sd_done(). The check is added within the default
section of the initial req_op() switch case so that the report and reset
zone commands are ignored. In addition, as sd_done() is not called for
passthrough requests, resid corrections are not done as intended by the
initial mpt3sas patch.
Fixes: f2e767bb5d6e ("mpt3sas: Force request partial completion alignment") Cc: <stable@vger.kernel.org> # v4.10 Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit c46f09175dabd5dd6a1507f36250bfa734a0156e
change sd.c modification to avoid req_op conversion in current kernel)
Sudip Mukherjee [Wed, 23 Dec 2015 15:35:26 +0000 (21:05 +0530)]
PCI/AER: include header file
We are having build failure with sparc allmodconfig with the error:
drivers/nvme/host/pci.c:15:0:
include/linux/aer.h: In function 'pci_enable_pcie_error_reporting':
include/linux/aer.h:49:10: error: 'EINVAL' undeclared (first use in this function)
The file aer.h is using the error values but they are defined in
errno.h. Include errno.h so that we have the definitions of the error
codes.
Samsung uses D2H command with Vendor Uniq Command (VUC) code F7
(the 0th bit of which is 1) for retrieving memory dump. In UEK4,
Bit 0 of the D2H command code has to be 0. Because of this voilation,
the nvmecli is unable to do crash and memory dumps in UEK4.
As the Samsung firmware can only understand VUC command code F7,
the IO direction is reversed for this vendor command code to
retrieve memory and crash dump.
Signed-off-by: Ashok Vairavan <ashok.vairavan@oracle.com> Reviewed-By: Martin K. Petersen <martin.petersen@oracle.com>
Christoph Hellwig [Mon, 6 Jun 2016 21:20:46 +0000 (23:20 +0200)]
nvme.h: add AER constants
Reviewed-by: Jay Freyensee <james.p.freyensee@intel.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Reviewed-by: Ming Lin <ming.l@ssi.samsung.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit 79f370eac63796a8933b210bca02f006ba32d22e)
Johannes Thumshirn [Tue, 10 May 2016 13:14:28 +0000 (15:14 +0200)]
NVMe: Only release requested regions
The NVMe driver only requests the PCIe device's memory regions but releases
all possible regions (including eventual I/O regions). This leads to a stale
warning entry in dmesg about freeing non existent resources.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Jens Axboe <axboe@fb.com>
(cherry picked from commit edb50a5403d2e2d2b2b63a8365c4378c9c300ed6)