scsi_debug.c:1626: possible bad test ?
Hello there,
drivers/scsi/scsi_debug.c:1626:20: warning: logical ‘and’ of mutually exclusive
tests is always false [-Wlogical-op]
Source code is
if (alloc_len < 4 && alloc_len> 0x) {
Suggest swap && for ||. Adding -Wlogical-op to the build might also help
Regards
David Binderman
--
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] scsi_debug: fix sanity check in resp_rsup_opcodes
David Binderman pointed out in this post:
http://marc.info/?l=linux-scsi&m=141924469523474&w=2
a sanity check that was flawed. See attached fix. Should
be applied to lk 3.19.0-rc1 and Christoph's branches.
ChangeLog:
fix alloc_len sanity check in resp_rsup_opcodes()
---
drivers/scsi/scsi_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Signed-off-by: Douglas Gilbert
>From 89e7ac4920ef22943fe94112221ab3760dc3f763 Mon Sep 17 00:00:00 2001
From: Douglas Gilbert
Date: Mon, 22 Dec 2014 10:16:55 -0500
Subject: [PATCH] scsi_debug sanity check in resp_rsup_opcodes
fix alloc_len sanity check in resp_rsup_opcodes()
---
drivers/scsi/scsi_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 7b8b51b..63a2e1f 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -1623,7 +1623,7 @@ resp_rsup_opcodes(struct scsi_cmnd *scp, struct sdebug_dev_info *devip)
req_opcode = cmd[3];
req_sa = get_unaligned_be16(cmd + 4);
alloc_len = get_unaligned_be32(cmd + 6);
- if (alloc_len < 4 && alloc_len > 0x) {
+ if (alloc_len < 4 || alloc_len > 0x) {
mk_sense_invalid_fld(scp, SDEB_IN_CDB, 6, -1);
return check_condition_result;
}
--
1.9.1
Re: [PATCH] scsi_debug: fix sanity check in resp_rsup_opcodes
On Mon, 2014-12-22 at 11:37 -0500, Douglas Gilbert wrote: > David Binderman pointed out in this post: > > http://marc.info/?l=linux-scsi&m=141924469523474&w=2 > > a sanity check that was flawed. See attached fix. Should > be applied to lk 3.19.0-rc1 and Christoph's branches. > > ChangeLog: > fix alloc_len sanity check in resp_rsup_opcodes() > > > --- > drivers/scsi/scsi_debug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Signed-off-by: Douglas Gilbert Reviewed-by: Ewan D. Milne -- 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] scsi: 3w-9xxx.c: Cleaning up missing null-terminate in conjunction with strncpy
2014-08-01 0:19 GMT+02:00 adam radford : > On Sun, Jul 27, 2014 at 8:11 AM, Rickard Strandqvist > wrote: >> Replacing strncpy with strlcpy to avoid strings that lacks null terminate. >> And use the sizeof on the to string rather than strlen on the from string. >> >> Signed-off-by: Rickard Strandqvist >> --- >> drivers/scsi/3w-9xxx.c |3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c >> index 0a73253..f4d2331 100644 >> --- a/drivers/scsi/3w-9xxx.c >> +++ b/drivers/scsi/3w-9xxx.c >> @@ -621,7 +621,8 @@ static int twa_check_srl(TW_Device_Extension *tw_dev, >> int *flashed) >> } >> >> /* Load rest of compatibility struct */ >> - strncpy(tw_dev->tw_compat_info.driver_version, TW_DRIVER_VERSION, >> strlen(TW_DRIVER_VERSION)); >> + strlcpy(tw_dev->tw_compat_info.driver_version, TW_DRIVER_VERSION, >> + sizeof(tw_dev->tw_compat_info.driver_version)); >> tw_dev->tw_compat_info.driver_srl_high = TW_CURRENT_DRIVER_SRL; >> tw_dev->tw_compat_info.driver_branch_high = TW_CURRENT_DRIVER_BRANCH; >> tw_dev->tw_compat_info.driver_build_high = TW_CURRENT_DRIVER_BUILD; >> -- >> 1.7.10.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > > Rickard, > > This patch looks fine. > > Acked-by: Adam Radford > > -Adam Hi Adam! What happened to this patch? Kind regards Rickard Strandqvist -- 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] scsi: 3w-9xxx.c: Cleaning up missing null-terminate in conjunction with strncpy
On Mon, Dec 22, 2014 at 2:52 PM, Rickard Strandqvist wrote: > 2014-08-01 0:19 GMT+02:00 adam radford : >> On Sun, Jul 27, 2014 at 8:11 AM, Rickard Strandqvist >> wrote: >>> Replacing strncpy with strlcpy to avoid strings that lacks null terminate. >>> And use the sizeof on the to string rather than strlen on the from string. >>> >>> Signed-off-by: Rickard Strandqvist >>> --- >>> drivers/scsi/3w-9xxx.c |3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c >>> index 0a73253..f4d2331 100644 >>> --- a/drivers/scsi/3w-9xxx.c >>> +++ b/drivers/scsi/3w-9xxx.c >>> @@ -621,7 +621,8 @@ static int twa_check_srl(TW_Device_Extension *tw_dev, >>> int *flashed) >>> } >>> >>> /* Load rest of compatibility struct */ >>> - strncpy(tw_dev->tw_compat_info.driver_version, TW_DRIVER_VERSION, >>> strlen(TW_DRIVER_VERSION)); >>> + strlcpy(tw_dev->tw_compat_info.driver_version, TW_DRIVER_VERSION, >>> + sizeof(tw_dev->tw_compat_info.driver_version)); >>> tw_dev->tw_compat_info.driver_srl_high = TW_CURRENT_DRIVER_SRL; >>> tw_dev->tw_compat_info.driver_branch_high = >>> TW_CURRENT_DRIVER_BRANCH; >>> tw_dev->tw_compat_info.driver_build_high = TW_CURRENT_DRIVER_BUILD; >>> -- >>> 1.7.10.4 >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Please read the FAQ at http://www.tux.org/lkml/ >> >> Rickard, >> >> This patch looks fine. >> >> Acked-by: Adam Radford >> >> -Adam > > > Hi Adam! > > What happened to this patch? It just didn't get picked up into scsi.git/for-next for some reason. All I can do is Ack it, which I already did :) -Adam -- 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 V2 1/4] be2iscsi : Fix the retry count for boot targets
On 12/19/2014 06:51 PM, John Soni Jose wrote:
> @@ -5376,8 +5387,14 @@ beiscsi_hw_health_check(struct work_struct *work)
> be_eqd_update(phba);
>
> if (phba->state & BE_ADAPTER_CHECK_BOOT) {
> - phba->state &= ~BE_ADAPTER_CHECK_BOOT;
> - be_check_boot_session(phba);
> + if ((phba->get_boot > 0) && (!phba->boot_kset)) {
> + phba->get_boot--;
> + if (!(phba->get_boot % BE_GET_BOOT_TO))
> + be_check_boot_session(phba);
> + } else {
> + phba->state &= ~BE_ADAPTER_CHECK_BOOT;
> + phba->get_boot = 0;
> + }
> }
Hey, I just want to make sure I am reading this patch correctly. If the
user had the network up, but the target was not able to handle the login
for longer than the timeout we are adding in this patch, then we will
not be able to get any notification (the iscsi boot info would not show
up in sysfs) later when we can login.
--
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 V2 1/4] be2iscsi : Fix the retry count for boot targets
On 12/22/2014 05:47 PM, Mike Christie wrote:
> On 12/19/2014 06:51 PM, John Soni Jose wrote:
>> @@ -5376,8 +5387,14 @@ beiscsi_hw_health_check(struct work_struct *work)
>> be_eqd_update(phba);
>>
>> if (phba->state & BE_ADAPTER_CHECK_BOOT) {
>> -phba->state &= ~BE_ADAPTER_CHECK_BOOT;
>> -be_check_boot_session(phba);
>> +if ((phba->get_boot > 0) && (!phba->boot_kset)) {
>> +phba->get_boot--;
>> +if (!(phba->get_boot % BE_GET_BOOT_TO))
>> +be_check_boot_session(phba);
>> +} else {
>> +phba->state &= ~BE_ADAPTER_CHECK_BOOT;
>> +phba->get_boot = 0;
>> +}
>> }
>
> Hey, I just want to make sure I am reading this patch correctly. If the
> user had the network up, but the target was not able to handle the login
> for longer than the timeout we are adding in this patch, then we will
> not be able to get any notification (the iscsi boot info would not show
> up in sysfs) later when we can login.
>
Actually, I think I am wrong. If we hit the above scenario, then
eventually the fw would log in and we would then get a
ASYNC_EVENT_NEW_ISCSI_CONN event right?
--
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 3/4 v3] scsi:stex.c Add reboot support
On 12/18/2014 11:41 AM, Charles Chiou wrote: On 12/17/2014 05:30 PM, Christoph Hellwig wrote: I'm not going to add a new reboot notifier for a driver. If you can convince the driver model / PM people to pass this information to ->shutdown we can add support for this difference, but not in this way. Can you send me a series that just adds the hardware support for now, so we can dash this PM issue out separately? Hi, we need to provide this information to our device. We face the HW signal issue on various motherboards. We experiment on many motherboards, and we observe that the restart signal is different on different motherboard. If device misses the signal, PCI loss or volume disappearance might happen. To make power management easier, driver provide the shutdown or reboot information to the device. Sorry, I'm not understand what is meaning of "series". Could you specify what you what me to send you? Thank you BRS Charles Hi, after our internal discussion, we can use shutdown flow for reboot temporarily. Some signal issue will happen (depend on MB), and it can be fixed by plug in and plug out manually. We will add reboot feature after PM can pass reboot information to ->shutdown. BRS Charles -- 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
