linux-kernel - Re: [PATCH] staging:rts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 9 Oct 2011 09:06:44 +0300
From:	Dan Carpenter <dan.carpenter@...cle.com>
To:	wei_wang@...lsil.com.cn
Cc:	gregkh@...e.de, devel@...uxdriverproject.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging:rts_pstor:Fix SDIO issue

Adding the check for if (sd_check_err_code(chip, SD_NO_CARD)) is
good, but introducing the new "reset_pass" variable is wrong.

I don't think you are updating the new variable consistently on
all paths.  For example, if it's a 0x5209 chip and the code is like
this:
                   retval = sd_change_bank_voltage(chip, SD_IO_3V3);
                   if (retval != STATUS_SUCCESS) {
                   	TRACE_RET(chip, STATUS_FAIL);
                   }

In the old system that was considered a successful reset, but under
your new system we don't update "reset_pass" here so we pass this
test and then we immediately return STATUS_FAIL because reset_pass
isn't set.  If that's what you intended then just write it like that.

		retval = sd_change_bank_voltage(chip, SD_IO_3V3);
		TRACE_RET(chip, STATUS_FAIL);

So could you write it again but just set retval = STATUS_FAIL; for
the new failure pathes.  Or better yet, just return STATUS_FAIL
directly.  So this code would be:

> +				if (retval == STATUS_SUCCESS)
> +					reset_pass = 1;

				if (retval != STATUS_SUCCESS)
					TRACE_RET(chip, retval);
regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/