Unnecessary barrier in sync_page()?

[Marcelo Tosatti]

Hi Chris,

I was talking to Andrew about this memory barrier 

static inline int sync_page(struct page *page)
{
        struct address_space *mapping;
                                                                                        
        /*
         * FIXME, fercrissake.  What is this barrier here for?
         */
        smp_mb();
        mapping = page_mapping(page);
        if (mapping && mapping->a_ops && mapping->a_ops->sync_page)
                return mapping->a_ops->sync_page(page);
        return 0;
}

And does not seem to be a reason for it. The callers are:

void fastcall wait_on_page_bit(struct page *page, int bit_nr)
{
        wait_queue_head_t *waitqueue = page_waitqueue(page);
        DEFINE_PAGE_WAIT(wait, page, bit_nr);
                                                                                        
        do {
                prepare_to_wait(waitqueue, &wait.wait, TASK_UNINTERRUPTIBLE);
                if (test_bit(bit_nr, &page->flags)) {
                        sync_page(page);
                        io_schedule();
                }
        } while (test_bit(bit_nr, &page->flags));
        finish_wait(waitqueue, &wait.wait);
} 

void fastcall __lock_page(struct page *page)
{
        wait_queue_head_t *wqh = page_waitqueue(page);
        DEFINE_PAGE_WAIT_EXCLUSIVE(wait, page, PG_locked);
                                                                                        
        while (TestSetPageLocked(page)) {
                prepare_to_wait_exclusive(wqh, &wait.wait, TASK_UNINTERRUPTIBLE);
                if (PageLocked(page)) {
                        sync_page(page);
                        io_schedule();
                }
        }
        finish_wait(wqh, &wait.wait);
}

Both callers call set_bit (atomic operation which cannot be reordered) before 
sync_page(), so.. what is the barrier trying to guarantee? 

TIA

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/