jbd: update locking coments

 *			need do nothing.

 * RevokeValid set, Revoked set:

 *			buffer has been revoked.

 *

 * Locking rules:

 * We keep two hash tables of revoke records. One hashtable belongs to the

 * running transaction (is pointed to by journal->j_revoke), the other one

 * belongs to the committing transaction. Accesses to the second hash table

 * happen only from the kjournald and no other thread touches this table.  Also

 * journal_switch_revoke_table() which switches which hashtable belongs to the

 * running and which to the committing transaction is called only from

 * kjournald. Therefore we need no locks when accessing the hashtable belonging

 * to the committing transaction.

 *

 * All users operating on the hash table belonging to the running transaction

 * have a handle to the transaction. Therefore they are safe from kjournald

 * switching hash tables under them. For operations on the lists of entries in

 * the hash table j_revoke_lock is used.

 *

 * Finally, also replay code uses the hash tables but at this moment noone else

 * can touch them (filesystem isn't mounted yet) and hence no locking is

 * needed.

 */

#ifndef __KERNEL__

 * the second time we would still have a pending revoke to cancel.  So,

 * do not trust the Revoked bit on buffers unless RevokeValid is also

 * set.

 *

 * The caller must have the journal locked.

 */

int journal_cancel_revoke(handle_t *handle, struct journal_head *jh)

{

/*

 * Write revoke records to the journal for all entries in the current

 * revoke hash, deleting the entries as we go.

 *

 * Called with the journal lock held.

 */

void journal_write_revoke_records(journal_t *journal,

				  transaction_t *transaction)

{