linux-ext4 - sct@...hat.com

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: <7fbb0ada0611110305r83d763ch78323a617b12840b@mail.gmail.com>
Date:	Sat, 11 Nov 2006 16:35:54 +0530
From:	"Ratna Manoj" <manoj.br@...il.com>
To:	linux-ext4@...r.kernel.org
Subject: sct@...hat.com

Hi,


int journal_dirty_data(handle_t *handle, struct buffer_head *bh)
{
                        ..................
                        ..................

                         /*
                         * This buffer may be undergoing writeout in commit.  We
                         * can't return from here and let the caller dirty it
                         * again because that can cause the write-out loop in
                         * commit to never terminate.
                         */
                         if (buffer_dirty(bh)) {
                                 get_bh(bh);
                                 spin_unlock(&journal->j_list_lock);
                                 jbd_unlock_bh_state(bh);
                                 need_brelse = 1;
                                 sync_dirty_buffer(bh);
                                 jbd_lock_bh_state(bh);
                                 spin_lock(&journal->j_list_lock);
                                 /* The buffer may become locked again at any
                                    time if it is redirtied */
                         }
                         ..............................
                         ..............................
}


Can any body please explain how returning from the above function
cause write-out loop in commit to never terminate ?

If the current buffer is in the data_sync list of previous commiting
transaction, after returning from the journal_dirty_data,
generic_commit_write will redirty the buffer even though previous
commiting transaction commits the buffer to disk. Correct ?


-Ratna.
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html