Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-24 Thread Arnd Bergmann
On Monday, October 24, 2016 3:34:27 PM CEST Binoy Jayan wrote:
> Hi Arnd
> 
> On 20 October 2016 at 14:36, Arnd Bergmann  wrote:
> > On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
> >> Semaphores are going away in the future, so replace the semaphore
> >> sync_request_sem with the a mutex lock. timeout_msecs is not used
> >> for the lock sync_request_sem, so remove the timed locking too.
> >>
> >> Signed-off-by: Binoy Jayan 
> >
> > The patch looks correct to me, but I think if you remove the support
> > for handling timeouts, you should update the prototype of
> > pqi_submit_raid_request_synchronous to no longer pass the timeout
> > argument in the first place.
> 
> But we still need "timeout_msecs" in a call to
> pqi_submit_raid_request_synchronous_with_io_request()
> 
> drivers/scsi/smartpqi/smartpqi_init.c +3484

Why? If it's always zero, we can remove that too.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-24 Thread Binoy Jayan
On 20 October 2016 at 14:40, Arnd Bergmann  wrote:
> On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
>> -   sema_init(_info->sync_request_sem,
>> -   PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS);
>> +   mutex_init(_info->sync_request_mutex);
>>
>
> Looking at this again, I see that PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS
> is '3', so this is in fact a counting semaphore rather than a mutex,
> and the conversion is changing the behavior.
>
> The patch can't go in unless you either show that it should be
> a normal mutex rather than a counting semaphore, or you find a way
> to keep the behavior the same.

This still holds true, will try changing this accordingly.

-Binoy
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-24 Thread Binoy Jayan
Hi Arnd

On 20 October 2016 at 14:36, Arnd Bergmann  wrote:
> On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
>> Semaphores are going away in the future, so replace the semaphore
>> sync_request_sem with the a mutex lock. timeout_msecs is not used
>> for the lock sync_request_sem, so remove the timed locking too.
>>
>> Signed-off-by: Binoy Jayan 
>
> The patch looks correct to me, but I think if you remove the support
> for handling timeouts, you should update the prototype of
> pqi_submit_raid_request_synchronous to no longer pass the timeout
> argument in the first place.

But we still need "timeout_msecs" in a call to
pqi_submit_raid_request_synchronous_with_io_request()

drivers/scsi/smartpqi/smartpqi_init.c +3484

-Binoy
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-20 Thread Arnd Bergmann
On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
> -   sema_init(_info->sync_request_sem,
> -   PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS);
> +   mutex_init(_info->sync_request_mutex);
> 

Looking at this again, I see that PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS
is '3', so this is in fact a counting semaphore rather than a mutex,
and the conversion is changing the behavior.

The patch can't go in unless you either show that it should be
a normal mutex rather than a counting semaphore, or you find a way
to keep the behavior the same.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-20 Thread Arnd Bergmann
On Thursday, October 20, 2016 2:24:01 PM CEST Binoy Jayan wrote:
> Semaphores are going away in the future, so replace the semaphore
> sync_request_sem with the a mutex lock. timeout_msecs is not used
> for the lock sync_request_sem, so remove the timed locking too.
> 
> Signed-off-by: Binoy Jayan 

The patch looks correct to me, but I think if you remove the support
for handling timeouts, you should update the prototype of
pqi_submit_raid_request_synchronous to no longer pass the timeout
argument in the first place.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] scsi: smartpqi: Replace semaphore sync_request_sem with mutex

2016-10-20 Thread Binoy Jayan
Semaphores are going away in the future, so replace the semaphore
sync_request_sem with the a mutex lock. timeout_msecs is not used
for the lock sync_request_sem, so remove the timed locking too.

Signed-off-by: Binoy Jayan 
---
 drivers/scsi/smartpqi/smartpqi.h  |  4 +++-
 drivers/scsi/smartpqi/smartpqi_init.c | 31 ++-
 2 files changed, 9 insertions(+), 26 deletions(-)

diff --git a/drivers/scsi/smartpqi/smartpqi.h b/drivers/scsi/smartpqi/smartpqi.h
index 07b6444..b4559b1 100644
--- a/drivers/scsi/smartpqi/smartpqi.h
+++ b/drivers/scsi/smartpqi/smartpqi.h
@@ -19,6 +19,8 @@
 #if !defined(_SMARTPQI_H)
 #define _SMARTPQI_H
 
+#include 
+
 #pragma pack(1)
 
 #define PQI_DEVICE_SIGNATURE   "PQI DREG"
@@ -961,7 +963,7 @@ struct pqi_ctrl_info {
unsigned intnum_heartbeats_requested;
struct timer_list heartbeat_timer;
 
-   struct semaphore sync_request_sem;
+   struct mutex sync_request_mutex;
struct semaphore lun_reset_sem;
 };
 
diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
b/drivers/scsi/smartpqi/smartpqi_init.c
index a535b26..4974f7e 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -3444,29 +3444,11 @@ static int pqi_submit_raid_request_synchronous(struct 
pqi_ctrl_info *ctrl_info,
unsigned long msecs_blocked;
size_t iu_length;
 
-   /*
-* Note that specifying PQI_SYNC_FLAGS_INTERRUPTABLE and a timeout value
-* are mutually exclusive.
-*/
-
-   if (flags & PQI_SYNC_FLAGS_INTERRUPTABLE) {
-   if (down_interruptible(_info->sync_request_sem))
+   if (flags & PQI_SYNC_FLAGS_INTERRUPTABLE)
+   if (mutex_lock_interruptible(_info->sync_request_mutex))
return -ERESTARTSYS;
-   } else {
-   if (timeout_msecs == NO_TIMEOUT) {
-   down(_info->sync_request_sem);
-   } else {
-   start_jiffies = jiffies;
-   if (down_timeout(_info->sync_request_sem,
-   msecs_to_jiffies(timeout_msecs)))
-   return -ETIMEDOUT;
-   msecs_blocked =
-   jiffies_to_msecs(jiffies - start_jiffies);
-   if (msecs_blocked >= timeout_msecs)
-   return -ETIMEDOUT;
-   timeout_msecs -= msecs_blocked;
-   }
-   }
+   else
+   mutex_lock(_info->sync_request_mutex);
 
io_request = pqi_alloc_io_request(ctrl_info);
 
@@ -3508,7 +3490,7 @@ static int pqi_submit_raid_request_synchronous(struct 
pqi_ctrl_info *ctrl_info,
 
pqi_free_io_request(io_request);
 
-   up(_info->sync_request_sem);
+   mutex_unlock(_info->sync_request_mutex);
 
return rc;
 }
@@ -5540,8 +5522,7 @@ static struct pqi_ctrl_info *pqi_alloc_ctrl_info(int 
numa_node)
INIT_DELAYED_WORK(_info->rescan_work, pqi_rescan_worker);
INIT_DELAYED_WORK(_info->update_time_work, pqi_update_time_worker);
 
-   sema_init(_info->sync_request_sem,
-   PQI_RESERVED_IO_SLOTS_SYNCHRONOUS_REQUESTS);
+   mutex_init(_info->sync_request_mutex);
sema_init(_info->lun_reset_sem, PQI_RESERVED_IO_SLOTS_LUN_RESET);
 
ctrl_info->ctrl_id = atomic_inc_return(_controller_count) - 1;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html