Re: [RFC] page lock ordering and OCFS2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Zach Brown <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux