lkml.org 
[lkml]   [2005]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] page lock ordering and OCFS2
    Zach Brown <zach.brown@oracle.com> wrote:
    >
    > The specific exports it needs from 2.6.14-rc4-mm1 are:
    >
    > $ grep '+EXPORT' patches/*.patch
    > patches/add-wake_up_page_all.patch:+EXPORT_SYMBOL(__wake_up_bit_all);
    > patches/add-wake_up_page_all.patch:+EXPORT_SYMBOL(wake_up_page_all);
    > patches/export-pagevec-helpers.patch:+EXPORT_SYMBOL_GPL(pagevec_lookup);
    > patches/export-page_waitqueue.patch:+EXPORT_SYMBOL_GPL(page_waitqueue);
    > patches/export-truncate_complete_pate.patch:+EXPORT_SYMBOL(truncate_complete_page);
    > patches/export-wake_up_page.patch:+EXPORT_SYMBOL(wake_up_page);

    Exporting page_waitqueue seems wrong. Might be better to add a core
    function to do the wait_event(*page_waitqueue(page), PageFsMisc(page)); and
    export that.

    How did you come up with this mix of GPL and non-GPL?

    > that wake_up_page_all() is just a variant that provides 0 nr_exclusive to
    > __wake_up_bit():
    >
    > -void fastcall __wake_up_bit(wait_queue_head_t *wq, void *word, int bit)
    > +static inline int __wake_up_bit_nr(wait_queue_head_t *wq, void *word, int bit,
    > + int nr_exclusive)
    > {
    > struct wait_bit_key key = __WAIT_BIT_KEY_INITIALIZER(word, bit);
    > if (waitqueue_active(wq))
    > - __wake_up(wq, TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE, 1, &key);
    > + __wake_up(wq, TASK_INTERRUPTIBLE|TASK_UNINTERRUPTIBLE,
    > + nr_exclusive, &key);
    > +}
    > +
    > +void fastcall __wake_up_bit(wait_queue_head_t *wq, void *word, int bit)
    > +{
    > + __wake_up_bit_nr(wq, word, bit, 1);
    > }
    > EXPORT_SYMBOL(__wake_up_bit);
    >
    > +void fastcall __wake_up_bit_all(wait_queue_head_t *wq, void *word, int bit)
    > +{
    > + __wake_up_bit_nr(wq, word, bit, 0);
    > +}
    > +EXPORT_SYMBOL(__wake_up_bit_all);
    >
    > Is this preferable to the core changes and is it something that's mergeable?
    > We'd love to come to a solution that won't be a barrier to merging so we can
    > get on with it. I can send that exporting series if we decide this is the
    > right thing.

    The above looks sane enough. Please run it by Bill?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-10-21 20:06    [W:4.249 / U:0.300 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site