linux-kernel - barrier question

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>] [day] [month] [year] [list]

Message-ID: <OF7CDB8A02.07DC9F04-ONC125782E.00582B5A-C125782E.0058E203@transmode.se>
Date:	Sat, 5 Feb 2011 17:10:50 +0100
From:	Joakim Tjernlund <joakim.tjernlund@...nsmode.se>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: barrier question


Looking for a bug in the cfi_cmd0001.c flash driver and I wonder
if the following is enough for chip->state to be reloaded every time it
accessed or if some barrier is needed:


	int chip_state = chip->state; /* save state before dropping lock */


	mutex_unlock(&chip->mutex);
	if (inval_len)
		INVALIDATE_CACHED_RANGE(map, inval_adr, inval_len);
	mutex_lock(&chip->mutex);


	for (;;) {
		while (chip->state != chip_state) {
			/* Someone's suspended the operation: sleep */
			DECLARE_WAITQUEUE(wait, current);
			set_current_state(TASK_UNINTERRUPTIBLE);
			add_wait_queue(&chip->wq, &wait);
			mutex_unlock(&chip->mutex);
			schedule();
			remove_wait_queue(&chip->wq, &wait);
			mutex_lock(&chip->mutex);
		}
...
	}

 Jocke

--
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/