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]
Message-ID: <20111009060644.GN18470@longonot.mountain>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ