[PATCH] scsi: cxlflash: fix assignment of the backend operations
commit cd43c221bb5e ("scsi: cxlflash: Isolate external module
dependencies") introduced the use of ifdefs to avoid compilation
errors when one of the possible backend driver, CXL or OCXL, is not
compiled.
Unfortunately, the wrong defines are used and the backend ops are
never assigned, leading to a kernel crash in any case when the
cxlflash module is loaded.
Signed-off-by: Cédric Le Goater
---
drivers/scsi/cxlflash/main.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxlflash/main.h b/drivers/scsi/cxlflash/main.h
index 2a3977823812..a39be94d110c 100644
--- a/drivers/scsi/cxlflash/main.h
+++ b/drivers/scsi/cxlflash/main.h
@@ -107,12 +107,12 @@ cxlflash_assign_ops(struct dev_dependent_vals *ddv)
{
const struct cxlflash_backend_ops *ops = NULL;
-#ifdef CONFIG_OCXL
+#ifdef CONFIG_OCXL_BASE
if (ddv->flags & CXLFLASH_OCXL_DEV)
ops = &cxlflash_ocxl_ops;
#endif
-#ifdef CONFIG_CXL
+#ifdef CONFIG_CXL_BASE
if (!(ddv->flags & CXLFLASH_OCXL_DEV))
ops = &cxlflash_cxl_ops;
#endif
--
2.13.6
Re: [PATCH] mpt3sas: Fix for regression caused due to cf6bf9710c patch
From: Sreekanth Reddy
Date: Wed, 4 Jul 2018 16:54:05 +0530
>
> Also I tried replacing readl() API with readw()API (as HBA FW will
> send 16 bit data at a time) as shown below and still I see same issue,
>
> MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
> u16 reply1;
> reply1 = readw(&ioc->chip->Doorbell);
> reply[1] = reply1;
>
> printk("LSI debug.. 0x%x, 0x%x, 0x%x \n", reply1, reply[1]);
> writel(0, &ioc->chip->HostInterruptStatus);
>
> printk("LSI MsgLength :%d\n", default_reply->MsgLength);
>
> And I got below output where message length is wrong, when I execute
> above code on SPARC64 machine,
It's the ordering of the u8 objects in the structure that is the problem,
on big endian they need to be swapped.
Re: [PATCHv2] libfc: fixup 'sleeping function called from invalid context'
Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH] libfc: Add lockdep annotations
Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCHv2] libfc: fixup 'sleeping function called from invalid context'
fc_rport_login() will be calling mutex_lock() while running inside
an RCU-protected section, triggering the warning 'sleeping function
called from invalid context'.
To fix this we can drop the rcu functions here altogether as the
disc mutex protecting the list itself is already held, preventing
any list manipulation.
Fixes: a407c593398c ("scsi: libfc: Fixup disc_mutex handling")
Signed-off-by: Hannes Reinecke
---
drivers/scsi/libfc/fc_disc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/libfc/fc_disc.c b/drivers/scsi/libfc/fc_disc.c
index 6125df787200..c1756b9b3ea5 100644
--- a/drivers/scsi/libfc/fc_disc.c
+++ b/drivers/scsi/libfc/fc_disc.c
@@ -287,9 +287,11 @@ static void fc_disc_done(struct fc_disc *disc, enum
fc_disc_event event)
* discovery, reverify or log them in. Otherwise, log them out.
* Skip ports which were never discovered. These are the dNS port
* and ports which were created by PLOGI.
+*
+* We don't need to use the _rcu variant here as the rport list
+* is protected by the disc mutex which is already held on entry.
*/
- rcu_read_lock();
- list_for_each_entry_rcu(rdata, &disc->rports, peers) {
+ list_for_each_entry(rdata, &disc->rports, peers) {
if (!kref_get_unless_zero(&rdata->kref))
continue;
if (rdata->disc_id) {
@@ -300,7 +302,6 @@ static void fc_disc_done(struct fc_disc *disc, enum
fc_disc_event event)
}
kref_put(&rdata->kref, fc_rport_destroy);
}
- rcu_read_unlock();
mutex_unlock(&disc->disc_mutex);
disc->disc_callback(lport, event);
mutex_lock(&disc->disc_mutex);
--
2.12.3
[PATCH] libfc: fixup 'sleeping function called from invalid context'
fc_rport_login() will be calling mutex_lock() while running inside
an RCU-protected section, triggering the warning 'sleeping function
called from invalid context'.
To fix this we can drop the rcu functions here altogether as the
disc mutex protecting the list itself is already held, preventing
any list manipulation.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/libfc/fc_disc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/libfc/fc_disc.c b/drivers/scsi/libfc/fc_disc.c
index 6125df787200..c1756b9b3ea5 100644
--- a/drivers/scsi/libfc/fc_disc.c
+++ b/drivers/scsi/libfc/fc_disc.c
@@ -287,9 +287,11 @@ static void fc_disc_done(struct fc_disc *disc, enum
fc_disc_event event)
* discovery, reverify or log them in. Otherwise, log them out.
* Skip ports which were never discovered. These are the dNS port
* and ports which were created by PLOGI.
+*
+* We don't need to use the _rcu variant here as the rport list
+* is protected by the disc mutex which is already held on entry.
*/
- rcu_read_lock();
- list_for_each_entry_rcu(rdata, &disc->rports, peers) {
+ list_for_each_entry(rdata, &disc->rports, peers) {
if (!kref_get_unless_zero(&rdata->kref))
continue;
if (rdata->disc_id) {
@@ -300,7 +302,6 @@ static void fc_disc_done(struct fc_disc *disc, enum
fc_disc_event event)
}
kref_put(&rdata->kref, fc_rport_destroy);
}
- rcu_read_unlock();
mutex_unlock(&disc->disc_mutex);
disc->disc_callback(lport, event);
mutex_lock(&disc->disc_mutex);
--
2.12.3
[PATCH] libfc: Add lockdep annotations
Convert the free text locking notes into proper lockdep annotations.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/libfc/fc_disc.c | 32 +
drivers/scsi/libfc/fc_lport.c | 108 +-
drivers/scsi/libfc/fc_rport.c | 99 +-
3 files changed, 99 insertions(+), 140 deletions(-)
diff --git a/drivers/scsi/libfc/fc_disc.c b/drivers/scsi/libfc/fc_disc.c
index 3f3569ec5ce3..6125df787200 100644
--- a/drivers/scsi/libfc/fc_disc.c
+++ b/drivers/scsi/libfc/fc_disc.c
@@ -59,9 +59,6 @@ static void fc_disc_restart(struct fc_disc *);
/**
* fc_disc_stop_rports() - Delete all the remote ports associated with the
lport
* @disc: The discovery job to stop remote ports on
- *
- * Locking Note: This function expects that the lport mutex is locked before
- * calling it.
*/
static void fc_disc_stop_rports(struct fc_disc *disc)
{
@@ -69,6 +66,7 @@ static void fc_disc_stop_rports(struct fc_disc *disc)
struct fc_rport_priv *rdata;
lport = fc_disc_lport(disc);
+ lockdep_assert_held(&lport->lp_mutex);
rcu_read_lock();
list_for_each_entry_rcu(rdata, &disc->rports, peers) {
@@ -84,9 +82,6 @@ static void fc_disc_stop_rports(struct fc_disc *disc)
* fc_disc_recv_rscn_req() - Handle Registered State Change Notification (RSCN)
* @disc: The discovery object to which the RSCN applies
* @fp: The RSCN frame
- *
- * Locking Note: This function expects that the disc_mutex is locked
- * before it is called.
*/
static void fc_disc_recv_rscn_req(struct fc_disc *disc, struct fc_frame *fp)
{
@@ -101,6 +96,8 @@ static void fc_disc_recv_rscn_req(struct fc_disc *disc,
struct fc_frame *fp)
LIST_HEAD(disc_ports);
struct fc_disc_port *dp, *next;
+ lockdep_assert_held(&disc->disc_mutex);
+
lport = fc_disc_lport(disc);
FC_DISC_DBG(disc, "Received an RSCN event\n");
@@ -220,12 +217,11 @@ static void fc_disc_recv_req(struct fc_lport *lport,
struct fc_frame *fp)
/**
* fc_disc_restart() - Restart discovery
* @disc: The discovery object to be restarted
- *
- * Locking Note: This function expects that the disc mutex
- * is already locked.
*/
static void fc_disc_restart(struct fc_disc *disc)
{
+ lockdep_assert_held(&disc->disc_mutex);
+
if (!disc->disc_callback)
return;
@@ -271,16 +267,13 @@ static void fc_disc_start(void (*disc_callback)(struct
fc_lport *,
* fc_disc_done() - Discovery has been completed
* @disc: The discovery context
* @event: The discovery completion status
- *
- * Locking Note: This function expects that the disc mutex is locked before
- * it is called. The discovery callback is then made with the lock released,
- * and the lock is re-taken before returning from this function
*/
static void fc_disc_done(struct fc_disc *disc, enum fc_disc_event event)
{
struct fc_lport *lport = fc_disc_lport(disc);
struct fc_rport_priv *rdata;
+ lockdep_assert_held(&disc->disc_mutex);
FC_DISC_DBG(disc, "Discovery complete\n");
disc->pending = 0;
@@ -360,15 +353,14 @@ static void fc_disc_error(struct fc_disc *disc, struct
fc_frame *fp)
/**
* fc_disc_gpn_ft_req() - Send Get Port Names by FC-4 type (GPN_FT) request
* @lport: The discovery context
- *
- * Locking Note: This function expects that the disc_mutex is locked
- * before it is called.
*/
static void fc_disc_gpn_ft_req(struct fc_disc *disc)
{
struct fc_frame *fp;
struct fc_lport *lport = fc_disc_lport(disc);
+ lockdep_assert_held(&disc->disc_mutex);
+
WARN_ON(!fc_lport_test_ready(lport));
disc->pending = 1;
@@ -658,8 +650,6 @@ static void fc_disc_gpn_id_resp(struct fc_seq *sp, struct
fc_frame *fp,
* @lport: The local port to initiate discovery on
* @rdata: remote port private data
*
- * Locking Note: This function expects that the disc_mutex is locked
- * before it is called.
* On failure, an error code is returned.
*/
static int fc_disc_gpn_id_req(struct fc_lport *lport,
@@ -667,6 +657,7 @@ static int fc_disc_gpn_id_req(struct fc_lport *lport,
{
struct fc_frame *fp;
+ lockdep_assert_held(&lport->disc.disc_mutex);
fp = fc_frame_alloc(lport, sizeof(struct fc_ct_hdr) +
sizeof(struct fc_ns_fid));
if (!fp)
@@ -683,14 +674,13 @@ static int fc_disc_gpn_id_req(struct fc_lport *lport,
* fc_disc_single() - Discover the directory information for a single target
* @lport: The local port the remote port is associated with
* @dp: The port to rediscover
- *
- * Locking Note: This function expects that the disc_mutex is locked
- * before it is called.
*/
static int fc_disc_single(struct fc_lport *lport, struct fc_disc_port *dp)
{
struct fc_rport_priv *rdata;
+ lockdep_assert_held(&lport->disc.disc_mutex);
+
Re: [PATCH] mpt3sas: Fix for regression caused due to cf6bf9710c patch
On Tue, Jul 3, 2018 at 8:53 PM, James Bottomley
wrote:
> On Tue, 2018-07-03 at 22:49 +0900, David Miller wrote:
>> From: Sreekanth Reddy
>> Date: Tue, 3 Jul 2018 17:48:49 +0530
>>
>> > Any suggestion/update over my previous mail. I am using 4.13
>> kernel.
>>
>> I think the issue is that if you are reading a 32-bit word and then
>> interpreting it as a struct full of individual bytes, you have to
>> order the bytes in the structure appropriately for the cpu
>> endianness.
>
> This is undoubtedly it. The point being if you read from a structure
> using readX, you have to read every element at its correct length for
> the endian swaps to work. You can't do a readq on 2 32 bit words and
> expect the endianness to be correct (you'll find they come out in the
> wrong order).
>
> I think you're using a shared (device and cpu) memory mapped structured
> data with a doorbell register,
[Sreekanth] Yes it is correct, we are using a shared memory mapped
structured data with a doorbell register.
In this particular handshake function, HBA will send only 16 bit data
at a time. So driver has to read 16 bit data at a time in a loop until
complete reply message is read.
> which is pretty identical to how the
> qla1280 does it. We went through several iterations of fixing that
> driver for big endian but finally settled on putting __le annotations
> on all the structures and doing cpu_to_leX() swaps as we wrote them
> (and obviously leX_to_cpu() swaps to read them), meaning the structure
> in memory is always correct for the device. Then we used a writeX to
> poke the doorbell and the device just picked up the correct
> information.
>
> The rule you want to be following is: memory mapped structure, you're
> responsible for annotation and swapping; readX/writeX to correctly
> sized data, the API will swap for you.
>
> So, can we just revert the original patch which is clearly now a
> regression and try to get this fixed in the merge window?
[Sreekanth] Yes we can revert the original patch.
> I think the
> actual bug is simply you're missing __leX annotations on the shared
> memory mapped structure to fix sparse, but otherwise everything is
> working.
Actually our memory mapped structure variables are declared with
__leX annotations as shown below,
typedef struct _MPI2_DEFAULT_REPLY {
U16 FunctionDependent1; /*0x00 */
U8 MsgLength; /*0x02 */
U8 Function;/*0x03 */
U16 FunctionDependent2; /*0x04 */
U8 FunctionDependent3; /*0x06 */
U8 MsgFlags;/*0x07 */
U8 VP_ID; /*0x08 */
U8 VF_ID; /*0x09 */
U16 Reserved1; /*0x0A */
U16 FunctionDependent5; /*0x0C */
U16 IOCStatus; /*0x0E */
U32 IOCLogInfo; /*0x10 */
} MPI2_DEFAULT_REPLY, *PTR_MPI2_DEFAULT_REPLY,
MPI2DefaultReply_t, *pMPI2DefaultReply_t;
and
typedef u8 U8;
typedef __le16 U16;
typedef __le32 U32;
typedef __le64 U64 __attribute__ ((aligned(4)));
Also I tried replacing readl() API with readw()API (as HBA FW will
send 16 bit data at a time) as shown below and still I see same issue,
MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
u16 reply1;
reply1 = readw(&ioc->chip->Doorbell);
reply[1] = reply1;
printk("LSI debug.. 0x%x, 0x%x, 0x%x \n", reply1, reply[1]);
writel(0, &ioc->chip->HostInterruptStatus);
printk("LSI MsgLength :%d\n", default_reply->MsgLength);
And I got below output where message length is wrong, when I execute
above code on SPARC64 machine,
LSI debug.. 0x311, 0x311
LSI MsgLength :3
Thanks,
Sreekanth
>
> James
>
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Tue, 3 Jul 2018 17:37:56 + Dave Carroll écrivait: > > [ 61.076949] SME is active and system is using DMA bounce buffers > > [ 61.076954] aacraid: Comm Interface type2 enabled > > > > Both controllers are capable of 64-bit DMA, however the communication > area should be 32-bit. Is this issue specific to Secure Memory > Encryption? Does it occur without that enabled? The machine with the big array is a very old Opteron, so it definitely not SME capable. I'll try without SME to be sure, is there a way to disable it that you know of or should I compile another kernel? -- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpBICeXAyukJ.pgp Description: Signature digitale OpenPGP
