* [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
@ 2012-08-13 13:07 Jeff Liu
2012-08-20 15:31 ` Mark Tinguely
2012-08-20 23:13 ` Dave Chinner
0 siblings, 2 replies; 8+ messages in thread
From: Jeff Liu @ 2012-08-13 13:07 UTC (permalink / raw)
To: xfs
helper routine to lookup data or hole offset from page cache for unwritten extents.
Signed-off-by: Jie Liu <jeff.liu@oracle.com>
---
fs/xfs/xfs_file.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 213 insertions(+), 0 deletions(-)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 98642cf..023dc9b 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -36,6 +36,7 @@
#include <linux/dcache.h>
#include <linux/falloc.h>
+#include <linux/pagevec.h>
static const struct vm_operations_struct xfs_file_vm_ops;
@@ -966,6 +967,218 @@ xfs_vm_page_mkwrite(
return block_page_mkwrite(vma, vmf, xfs_get_blocks);
}
+/*
+ * This type is designed to indicate the type of offset we would like
+ * to search from page cache for either xfs_seek_data() or xfs_seek_hole().
+ */
+enum {
+ HOLE_OFF = 0,
+ DATA_OFF,
+};
+
+/*
+ * Lookup the desired type of offset from the given page.
+ *
+ * On success, return true and the offset argument will point to the
+ * start of the region that was found. Otherwise this function will
+ * return false and keep the offset argument unchanged.
+ */
+STATIC bool
+xfs_lookup_buffer_offset(
+ struct page *page,
+ loff_t *offset,
+ unsigned int type)
+{
+ loff_t lastoff = page_offset(page);
+ bool found = false;
+ struct buffer_head *bh, *head;
+
+ bh = head = page_buffers(page);
+ do {
+ /*
+ * Unwritten extents that have data in the page
+ * cache covering them can be identified by the
+ * BH_Unwritten state flag. Pages with multiple
+ * buffers might have a mix of holes, data and
+ * unwritten extents - any buffer with valid
+ * data in it should have BH_Uptodate flag set
+ * on it.
+ */
+ if (buffer_unwritten(bh) ||
+ buffer_uptodate(bh)) {
+ if (type == DATA_OFF)
+ found = true;
+ } else {
+ if (type == HOLE_OFF)
+ found = true;
+ }
+
+ if (found) {
+ *offset = lastoff;
+ break;
+ }
+ lastoff += bh->b_size;
+ } while ((bh = bh->b_this_page) != head);
+
+ return found;
+}
+
+/*
+ * This routine is called to find out and return a data or hole offset
+ * from the page cache for unwritten extents according to the desired
+ * type for xfs_seek_data() or xfs_seek_hole().
+ *
+ * The argument offset is used to tell where we start to search from the
+ * page cache. Map is used to figure out the end points of the range to
+ * lookup pages.
+ *
+ * Return true if the desired type of offset was found, and the argument
+ * offset is filled with that address. Otherwise, return false and keep
+ * offset unchanged.
+ */
+STATIC bool
+xfs_find_get_desired_pgoff(
+ struct inode *inode,
+ struct xfs_bmbt_irec *map,
+ unsigned int type,
+ loff_t *offset)
+{
+ struct xfs_inode *ip = XFS_I(inode);
+ struct xfs_mount *mp = ip->i_mount;
+ struct pagevec pvec;
+ pgoff_t index;
+ pgoff_t end;
+ loff_t endoff;
+ loff_t startoff = *offset;
+ loff_t lastoff = startoff;
+ bool found = false;
+
+ pagevec_init(&pvec, 0);
+
+ index = startoff >> PAGE_CACHE_SHIFT;
+ endoff = XFS_FSB_TO_B(mp, map->br_startoff + map->br_blockcount);
+ end = endoff >> PAGE_CACHE_SHIFT;
+ do {
+ int want;
+ unsigned nr_pages;
+ unsigned int i;
+
+ want = min_t(pgoff_t, end - index, (pgoff_t)PAGEVEC_SIZE);
+ nr_pages = pagevec_lookup(&pvec, inode->i_mapping, index,
+ want);
+ /*
+ * No page mapped into given range. If we are searching holes
+ * and if this is the first time we got into the loop, it means
+ * that the given offset is landed in a hole, return it.
+ *
+ * If we have already stepped through some block buffers to find
+ * holes but they all contains data. In this case, the last
+ * offset is already updated and pointed to the end of the last
+ * mapped page, if it does not reach the endpoint to search,
+ * that means there should be a hole between them.
+ */
+ if (nr_pages == 0) {
+ /* Data search found nothing */
+ if (type == DATA_OFF)
+ break;
+
+ ASSERT(type == HOLE_OFF);
+ if (lastoff == startoff || lastoff < endoff) {
+ found = true;
+ *offset = lastoff;
+ }
+ break;
+ }
+
+ /*
+ * At lease we found one page. If this is the first time we
+ * step into the loop, and if the first page index offset is
+ * greater than the given search offset, a hole was found.
+ */
+ if (type == HOLE_OFF && lastoff == startoff &&
+ lastoff < page_offset(pvec.pages[0])) {
+ found = true;
+ break;
+ }
+
+ for (i = 0; i < nr_pages; i++) {
+ struct page *page = pvec.pages[i];
+ loff_t b_offset;
+
+ /*
+ * Page index is out of range, searching done.
+ * If the current offset is not reaches the end
+ * of the specified search range, there should
+ * be a hole between them.
+ */
+ if (page->index > end) {
+ if (type == HOLE_OFF && lastoff < endoff) {
+ *offset = lastoff;
+ found = true;
+ }
+ goto out;
+ }
+
+ lock_page(page);
+ /*
+ * Page truncated or invalidated(page->mapping == NULL).
+ * We can freely skip it and proceed to check the next
+ * page.
+ */
+ if (unlikely(page->mapping != inode->i_mapping)) {
+ unlock_page(page);
+ continue;
+ }
+
+ if (!page_has_buffers(page)) {
+ unlock_page(page);
+ continue;
+ }
+
+ found = xfs_lookup_buffer_offset(page, &b_offset, type);
+ if (found) {
+ /*
+ * The found offset may be less than the start
+ * point to search if this is the first time to
+ * come here.
+ */
+ *offset = max_t(loff_t, startoff, b_offset);
+ unlock_page(page);
+ goto out;
+ }
+
+ /*
+ * We either searching data but nothing was found, or
+ * searching hole but found a data buffer. In either
+ * case, probably the next page contains the desired
+ * things, update the last offset to it so.
+ */
+ lastoff = page_offset(page) + PAGE_SIZE;
+ index = page->index + 1;
+ unlock_page(page);
+ }
+
+ /*
+ * The number of returned pages less than our desired, search
+ * done. In this case, nothing was found for searching data,
+ * but we found a hole behind the last offset.
+ */
+ if (nr_pages < want) {
+ if (type == HOLE_OFF) {
+ *offset = lastoff;
+ found = true;
+ }
+ break;
+ }
+
+ pagevec_release(&pvec);
+ } while (index <= end);
+
+out:
+ pagevec_release(&pvec);
+ return found;
+}
+
STATIC loff_t
xfs_seek_data(
struct file *file,
--
1.7.4.1
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-13 13:07 [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache Jeff Liu
@ 2012-08-20 15:31 ` Mark Tinguely
2012-08-20 23:08 ` Dave Chinner
2012-08-21 4:54 ` Jie Liu
2012-08-20 23:13 ` Dave Chinner
1 sibling, 2 replies; 8+ messages in thread
From: Mark Tinguely @ 2012-08-20 15:31 UTC (permalink / raw)
To: jeff.liu; +Cc: xfs
On 08/13/12 08:07, Jeff Liu wrote:
> helper routine to lookup data or hole offset from page cache for unwritten extents.
>
> Signed-off-by: Jie Liu<jeff.liu@oracle.com>
>
> ---
> fs/xfs/xfs_file.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 213 insertions(+), 0 deletions(-)
> +STATIC bool
> +xfs_find_get_desired_pgoff(
> + struct inode *inode,
> + struct xfs_bmbt_irec *map,
> + unsigned int type,
> + loff_t *offset)
> +{
...
> + for (i = 0; i< nr_pages; i++) {
> + struct page *page = pvec.pages[i];
> + loff_t b_offset;
> +
> + /*
> + * Page index is out of range, searching done.
> + * If the current offset is not reaches the end
> + * of the specified search range, there should
> + * be a hole between them.
> + */
> + if (page->index> end) {
Shouldn't this sample of the index also be locked?
> + if (type == HOLE_OFF&& lastoff< endoff) {
> + *offset = lastoff;
> + found = true;
> + }
> + goto out;
> + }
> +
> + lock_page(page);
--Mark.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-20 15:31 ` Mark Tinguely
@ 2012-08-20 23:08 ` Dave Chinner
2012-08-21 4:54 ` Jie Liu
1 sibling, 0 replies; 8+ messages in thread
From: Dave Chinner @ 2012-08-20 23:08 UTC (permalink / raw)
To: Mark Tinguely; +Cc: jeff.liu, xfs
On Mon, Aug 20, 2012 at 10:31:11AM -0500, Mark Tinguely wrote:
> On 08/13/12 08:07, Jeff Liu wrote:
> >helper routine to lookup data or hole offset from page cache for unwritten extents.
> >
> >Signed-off-by: Jie Liu<jeff.liu@oracle.com>
> >
> >---
> > fs/xfs/xfs_file.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 213 insertions(+), 0 deletions(-)
> >+STATIC bool
> >+xfs_find_get_desired_pgoff(
> >+ struct inode *inode,
> >+ struct xfs_bmbt_irec *map,
> >+ unsigned int type,
> >+ loff_t *offset)
> >+{
>
> ...
>
> >+ for (i = 0; i< nr_pages; i++) {
> >+ struct page *page = pvec.pages[i];
> >+ loff_t b_offset;
> >+
> >+ /*
> >+ * Page index is out of range, searching done.
> >+ * If the current offset is not reaches the end
> >+ * of the specified search range, there should
> >+ * be a hole between them.
> >+ */
> >+ if (page->index> end) {
>
> Shouldn't this sample of the index also be locked?
You can check it before the page is locked for being beyond EOF, but
it still needs to be checked again after the page is locked as it
can change between this check and the page being locked.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-13 13:07 [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache Jeff Liu
2012-08-20 15:31 ` Mark Tinguely
@ 2012-08-20 23:13 ` Dave Chinner
2012-08-21 5:04 ` Jie Liu
1 sibling, 1 reply; 8+ messages in thread
From: Dave Chinner @ 2012-08-20 23:13 UTC (permalink / raw)
To: Jeff Liu; +Cc: xfs
On Mon, Aug 13, 2012 at 09:07:58PM +0800, Jeff Liu wrote:
> helper routine to lookup data or hole offset from page cache for unwritten extents.
>
> Signed-off-by: Jie Liu <jeff.liu@oracle.com>
....
> + unsigned int i;
> +
> + want = min_t(pgoff_t, end - index, (pgoff_t)PAGEVEC_SIZE);
No need for the cast to (pgoff_t) here. That's what the min_t()
macro does for you.
> + for (i = 0; i < nr_pages; i++) {
> + struct page *page = pvec.pages[i];
> + loff_t b_offset;
> +
> + /*
> + * Page index is out of range, searching done.
> + * If the current offset is not reaches the end
> + * of the specified search range, there should
> + * be a hole between them.
> + */
> + if (page->index > end) {
> + if (type == HOLE_OFF && lastoff < endoff) {
> + *offset = lastoff;
> + found = true;
> + }
> + goto out;
> + }
> +
> + lock_page(page);
> + /*
> + * Page truncated or invalidated(page->mapping == NULL).
> + * We can freely skip it and proceed to check the next
> + * page.
> + */
> + if (unlikely(page->mapping != inode->i_mapping)) {
> + unlock_page(page);
> + continue;
> + }
Still need to check page->index again after locking the page. As
this isn't performance critical, I don't think you need the check
before the page is locked, anyway....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-20 15:31 ` Mark Tinguely
2012-08-20 23:08 ` Dave Chinner
@ 2012-08-21 4:54 ` Jie Liu
2012-08-21 5:25 ` Dave Chinner
1 sibling, 1 reply; 8+ messages in thread
From: Jie Liu @ 2012-08-21 4:54 UTC (permalink / raw)
To: Mark Tinguely; +Cc: xfs
On 08/20/12 23:31, Mark Tinguely wrote:
> On 08/13/12 08:07, Jeff Liu wrote:
>> helper routine to lookup data or hole offset from page cache for
>> unwritten extents.
>>
>> Signed-off-by: Jie Liu<jeff.liu@oracle.com>
>>
>> ---
>> fs/xfs/xfs_file.c | 213
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 213 insertions(+), 0 deletions(-)
>> +STATIC bool
>> +xfs_find_get_desired_pgoff(
>> + struct inode *inode,
>> + struct xfs_bmbt_irec *map,
>> + unsigned int type,
>> + loff_t *offset)
>> +{
>
> ...
>
>> + for (i = 0; i< nr_pages; i++) {
>> + struct page *page = pvec.pages[i];
>> + loff_t b_offset;
>> +
>> + /*
>> + * Page index is out of range, searching done.
>> + * If the current offset is not reaches the end
>> + * of the specified search range, there should
>> + * be a hole between them.
>> + */
>> + if (page->index> end) {
>
> Shouldn't this sample of the index also be locked?
Thanks for the review. Yes, it should be locked in concert with the
sample of index below.
However, as I have mentioned at v6,
http://oss.sgi.com/archives/xfs/2012-08/msg00028.html
I really don't understand why page->index will be changed as those pages
returned from pagevec_lookup() should
have refcount > 0. Hence, those pages can not be removed out of VM
cache upon memory reclaim IMHO.
If so, both sample of index could be performed without page lock.
Thanks,
-Jeff
>
>> + if (type == HOLE_OFF&& lastoff< endoff) {
>> + *offset = lastoff;
>> + found = true;
>> + }
>> + goto out;
>> + }
>> +
>> + lock_page(page);
>
> --Mark.
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-20 23:13 ` Dave Chinner
@ 2012-08-21 5:04 ` Jie Liu
0 siblings, 0 replies; 8+ messages in thread
From: Jie Liu @ 2012-08-21 5:04 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On 08/21/12 07:13, Dave Chinner wrote:
> On Mon, Aug 13, 2012 at 09:07:58PM +0800, Jeff Liu wrote:
>> helper routine to lookup data or hole offset from page cache for unwritten extents.
>>
>> Signed-off-by: Jie Liu <jeff.liu@oracle.com>
> ....
>> + unsigned int i;
>> +
>> + want = min_t(pgoff_t, end - index, (pgoff_t)PAGEVEC_SIZE);
> No need for the cast to (pgoff_t) here. That's what the min_t()
> macro does for you.
Thanks for pointing this out.
>
>> + for (i = 0; i < nr_pages; i++) {
>> + struct page *page = pvec.pages[i];
>> + loff_t b_offset;
>> +
>> + /*
>> + * Page index is out of range, searching done.
>> + * If the current offset is not reaches the end
>> + * of the specified search range, there should
>> + * be a hole between them.
>> + */
>> + if (page->index > end) {
>> + if (type == HOLE_OFF && lastoff < endoff) {
>> + *offset = lastoff;
>> + found = true;
>> + }
>> + goto out;
>> + }
>> +
>> + lock_page(page);
>> + /*
>> + * Page truncated or invalidated(page->mapping == NULL).
>> + * We can freely skip it and proceed to check the next
>> + * page.
>> + */
>> + if (unlikely(page->mapping != inode->i_mapping)) {
>> + unlock_page(page);
>> + continue;
>> + }
> Still need to check page->index again after locking the page. As
> this isn't performance critical, I don't think you need the check
> before the page is locked, anyway....
I understand that we have to check page->mapping with page locked
because race against inode truncation.
But could you teaching me why page->index will be changed in either
memory reclaim or truncates even if
the page returned with refcount > 0?
Thanks,
-Jeff
>
> Cheers,
>
> Dave.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-21 4:54 ` Jie Liu
@ 2012-08-21 5:25 ` Dave Chinner
2012-08-21 6:41 ` Jie Liu
0 siblings, 1 reply; 8+ messages in thread
From: Dave Chinner @ 2012-08-21 5:25 UTC (permalink / raw)
To: Jie Liu; +Cc: Mark Tinguely, xfs
On Tue, Aug 21, 2012 at 12:54:52PM +0800, Jie Liu wrote:
> On 08/20/12 23:31, Mark Tinguely wrote:
> > On 08/13/12 08:07, Jeff Liu wrote:
> >> helper routine to lookup data or hole offset from page cache for
> >> unwritten extents.
> >>
> >> Signed-off-by: Jie Liu<jeff.liu@oracle.com>
> >>
> >> ---
> >> fs/xfs/xfs_file.c | 213
> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++
> >> 1 files changed, 213 insertions(+), 0 deletions(-)
> >> +STATIC bool
> >> +xfs_find_get_desired_pgoff(
> >> + struct inode *inode,
> >> + struct xfs_bmbt_irec *map,
> >> + unsigned int type,
> >> + loff_t *offset)
> >> +{
> >
> > ...
> >
> >> + for (i = 0; i< nr_pages; i++) {
> >> + struct page *page = pvec.pages[i];
> >> + loff_t b_offset;
> >> +
> >> + /*
> >> + * Page index is out of range, searching done.
> >> + * If the current offset is not reaches the end
> >> + * of the specified search range, there should
> >> + * be a hole between them.
> >> + */
> >> + if (page->index> end) {
> >
> > Shouldn't this sample of the index also be locked?
> Thanks for the review. Yes, it should be locked in concert with the
> sample of index below.
>
> However, as I have mentioned at v6,
> http://oss.sgi.com/archives/xfs/2012-08/msg00028.html
> I really don't understand why page->index will be changed as those pages
> returned from pagevec_lookup() should
> have refcount > 0. Hence, those pages can not be removed out of VM
> cache upon memory reclaim IMHO.
Ah, true, you are right. It's been a while since I looked at the
reference count vs truncate vs page locks in detail, and I have
always tended to err on the side of caution. I'd suggest you need to
copy the comment from write_cache_pages() here to remind us why it
is safe to do the check unlocked, otherwise in a couple of years
time someone will be asking themselves why this is safe... :/
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache
2012-08-21 5:25 ` Dave Chinner
@ 2012-08-21 6:41 ` Jie Liu
0 siblings, 0 replies; 8+ messages in thread
From: Jie Liu @ 2012-08-21 6:41 UTC (permalink / raw)
To: Dave Chinner; +Cc: Mark Tinguely, xfs
On 08/21/12 13:25, Dave Chinner wrote:
> On Tue, Aug 21, 2012 at 12:54:52PM +0800, Jie Liu wrote:
>> On 08/20/12 23:31, Mark Tinguely wrote:
>>> On 08/13/12 08:07, Jeff Liu wrote:
>>>> helper routine to lookup data or hole offset from page cache for
>>>> unwritten extents.
>>>>
>>>> Signed-off-by: Jie Liu<jeff.liu@oracle.com>
>>>>
>>>> ---
>>>> fs/xfs/xfs_file.c | 213
>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 files changed, 213 insertions(+), 0 deletions(-)
>>>> +STATIC bool
>>>> +xfs_find_get_desired_pgoff(
>>>> + struct inode *inode,
>>>> + struct xfs_bmbt_irec *map,
>>>> + unsigned int type,
>>>> + loff_t *offset)
>>>> +{
>>> ...
>>>
>>>> + for (i = 0; i< nr_pages; i++) {
>>>> + struct page *page = pvec.pages[i];
>>>> + loff_t b_offset;
>>>> +
>>>> + /*
>>>> + * Page index is out of range, searching done.
>>>> + * If the current offset is not reaches the end
>>>> + * of the specified search range, there should
>>>> + * be a hole between them.
>>>> + */
>>>> + if (page->index> end) {
>>> Shouldn't this sample of the index also be locked?
>> Thanks for the review. Yes, it should be locked in concert with the
>> sample of index below.
>>
>> However, as I have mentioned at v6,
>> http://oss.sgi.com/archives/xfs/2012-08/msg00028.html
>> I really don't understand why page->index will be changed as those pages
>> returned from pagevec_lookup() should
>> have refcount > 0. Hence, those pages can not be removed out of VM
>> cache upon memory reclaim IMHO.
> Ah, true, you are right. It's been a while since I looked at the
> reference count vs truncate vs page locks in detail, and I have
> always tended to err on the side of caution. I'd suggest you need to
> copy the comment from write_cache_pages() here to remind us why it
> is safe to do the check unlocked, otherwise in a couple of years
> time someone will be asking themselves why this is safe... :/
Thanks for your quick response and confirmation, I'll copy the comments so.
Thanks,
-Jeff
>
> Cheers,
>
> Dave.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-08-21 6:42 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-13 13:07 [PATCH v7 2/4] xfs: Introduce a helper routine to probe data or hole offset from page cache Jeff Liu
2012-08-20 15:31 ` Mark Tinguely
2012-08-20 23:08 ` Dave Chinner
2012-08-21 4:54 ` Jie Liu
2012-08-21 5:25 ` Dave Chinner
2012-08-21 6:41 ` Jie Liu
2012-08-20 23:13 ` Dave Chinner
2012-08-21 5:04 ` Jie Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox