From: Andrew Morton <akpm@osdl.org>
To: Zach Brown <zach.brown@oracle.com>
Cc: linux-kernel@vger.kernel.org, hch@infradead.org, adilger@clusterfs.com
Subject: Re: [RFC] page lock ordering and OCFS2
Date: Fri, 21 Oct 2005 10:58:11 -0700 [thread overview]
Message-ID: <20051021105811.2de09059.akpm@osdl.org> (raw)
In-Reply-To: <435928BC.5000509@oracle.com>
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?
next prev parent reply other threads:[~2005-10-21 18:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-17 22:20 [RFC] page lock ordering and OCFS2 Zach Brown
2005-10-17 23:17 ` Andrew Morton
2005-10-18 0:40 ` Zach Brown
2005-10-18 1:24 ` Andrew Morton
2005-10-18 8:23 ` Anton Altaparmakov
2005-10-18 17:25 ` Zach Brown
2005-10-18 17:14 ` Zach Brown
2005-10-21 17:43 ` Zach Brown
2005-10-21 17:57 ` Christoph Hellwig
2005-10-21 20:36 ` Zach Brown
2005-10-21 20:59 ` Andrew Morton
2005-10-21 21:57 ` Zach Brown
2005-10-25 0:03 ` Zach Brown
2005-10-21 17:58 ` Andrew Morton [this message]
2005-10-21 20:32 ` Zach Brown
2005-10-17 23:37 ` Badari Pulavarty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051021105811.2de09059.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=adilger@clusterfs.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zach.brown@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox