Signed-off-by: Nick Piggin <npiggin@suse.de>
---

 kernel/wait.c |    2 +-

 1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/kernel/wait.c

===================================================================

--- linux-2.6.orig/kernel/wait.c

+++ linux-2.6/kernel/wait.c

@@ -195,7 +195,7 @@ __wait_on_bit_lock(wait_queue_head_t *wq

 			if ((ret = (*action)(q->key.flags)))

 				break;

 		}

-	} while (test_and_set_bit(q->key.bit_nr, q->key.flags));

+	} while (test_and_set_bit_lock(q->key.bit_nr, q->key.flags));

 	finish_wait(wq, &q->wait);

 	return ret;

 }
-- 
-

Sorry, I'm just not going to apply a patch like that.
I mean, how the heck is anyone else supposed to understand what you're up

to?  There's a bit of documentation in Documentation/atomic_ops.txt

(probably enough, I guess) but it is totally unobvious to 98.3% of kernel

developers when they should use test_and_set_bit() versus

test_and_set_bit_lock() and it is far too much work to work out why it was

used in __wait_on_bit_lock(), whether it is correct, what advantages it

brings and whether and where others should emulate it.
So in my opinion this submission isn't of sufficient quality to be

included in Linux.
IOW: please write changelogs.  Preferably good ones.
-

Hmm, I might just withdraw this patch 1/5. This is generally a slowpath,

and it's hard to guarantee that any exported user doesn't rely on the

full barrier here (not that they would know whether they do or not, let

alone document the fact).
If you set a bit for the purpose of opening a critical section, then

you can use this. And clear_bit_unlock to close it.
The advantages are that it is faster, and the hapless driver writer

doesn't have to butcher or forget about doing the correct

smp_mb__before_clear_bit(), or have reviewers wondering exactly WTF

that barrier is for, etc.
Basically, it is faster, harder to get wrong, and more self-docuemnting.
In general, others should not emulate it, because they should be

using our regular locking primitives instead. If they really must
2/5: "tasklet_trylock opens a critical section. tasklet_unlock closes it.

      hence, _lock bitops can be used for the bitops"
5/5: "trylock_page opens a critical section. unlock_page closes it. hence,

      _lock bitops can be used for the bitops"
5/5: "trylock_buffer opens a critical section. unlock_buffer closes it.

      hence, _lock bitops can be used for the bitops"
Are those helpful?

-

So I'd not call it self-documenting.
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

-