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] [day] [month] [year] [list]
Message-ID: <49344092.9050908@s5r6.in-berlin.de>
Date:	Mon, 01 Dec 2008 20:52:50 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	linux1394-devel@...ts.sourceforge.net
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ieee1394: sbp2: fix race condition in state change

I wrote:
> An intermediate transition from _RUNNING to _IN_SHUTDOWN could have been
> missed by the former code.
> 
> Signed-off-by: Stefan Richter <stefanr@...6.in-berlin.de>
> ---
>  drivers/ieee1394/sbp2.c |    9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> Index: linux/drivers/ieee1394/sbp2.c
> ===================================================================
> --- linux.orig/drivers/ieee1394/sbp2.c
> +++ linux/drivers/ieee1394/sbp2.c
> @@ -895,12 +895,13 @@ static void sbp2_host_reset(struct hpsb_
>  		return;
>  
>  	read_lock_irqsave(&sbp2_hi_logical_units_lock, flags);
> +
>  	list_for_each_entry(lu, &hi->logical_units, lu_list)
> -		if (likely(atomic_read(&lu->state) !=
> -			   SBP2LU_STATE_IN_SHUTDOWN)) {
> -			atomic_set(&lu->state, SBP2LU_STATE_IN_RESET);
> +		if (atomic_cmpxchg(&lu->state,
> +				   SBP2LU_STATE_RUNNING, SBP2LU_STATE_IN_RESET)
> +		    == SBP2LU_STATE_RUNNING)
>  			scsi_block_requests(lu->shost);
> -		}
> +
>  	read_unlock_irqrestore(&sbp2_hi_logical_units_lock, flags);
>  }
>  

Still not entirely correct.  Maybe

		scsi_block_requests(lu->shost);
		if (atomic_cmpxchg(&lu->state,
				   SBP2LU_STATE_RUNNING,
				   SBP2LU_STATE_IN_RESET)
		    == SBP2LU_IN_SHUTDOWN)
			scsi_unblock_requests(lu->shost);

Does What I Mean.  Or I should just put a lock around all lu->state and
shost->host_self_blocked manipulations.
-- 
Stefan Richter
-=====-==--- ==-- ----=
http://arcgraph.de/sr/
--
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