From: "Bryan O'Sullivan" <bos@pathscale.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Hugh@veritas.com, rdreier@cisco.com, torvalds@osdl.org,
hch@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10 of 20] ipath - support for userspace apps using core driver
Date: Wed, 15 Mar 2006 20:58:23 -0800 [thread overview]
Message-ID: <1142485103.25297.13.camel@camp4.serpentine.com> (raw)
In-Reply-To: <20060315192813.71a5d31a.akpm@osdl.org>
On Wed, 2006-03-15 at 19:28 -0800, Andrew Morton wrote:
> It still has PG_reserved set. I'd suggest you simply not set PG_reserved
> on these pages.
I made that change; thanks to you and Linus for suggesting it.
It caused progress of a sort to occur. This time, we made it through
mmput (the earlier crash site) and tripped over our shoelaces a bit
later during process exit:
Bad page state at __free_pages_ok (in process 'mpi_hello', page ffff8100020e2f88)
flags:0x0100000000000804 mapping:0000000000000000 mapcount:0 count:0 (Not tainted)
Backtrace:
Call Trace:<ffffffff80169577>{bad_page+135} <ffffffff8016b1ae>{__free_pages_ok+128}
<ffffffff880f1c88>{:ipath_core:ipath_free_pddata+292}
<ffffffff880f7039>{:ipath_core:ipath_close+1616} <ffffffff8018afeb>{__fput+183}
<ffffffff80188612>{filp_close+91} <ffffffff8013e2a3>{put_files_struct+117}
<ffffffff8013f312>{do_exit+646} <ffffffff8013fdd1>{sys_exit_group+0}
<ffffffff80149fd9>{get_signal_to_deliver+1594} <ffffffff8010f23a>{do_signal+116}
<ffffffff80148529>{force_sig_info+158} <ffffffff8011017e>{retint_signal+61}
Here, I think we're calling dma_free_coherent, on a hunk of memory that
userspace mmapped earlier. Perhaps that got cleaned up during mmput,
and that's why dma_free_coherent is choking here.
> hm. Are these pages supposed to be owned by the userspace process? To have their
> lifetime controlled by that process?
We have two different sets of pages. Some we want to keep around for as
long as a device is plugged in, so the driver should continue to own
them after a user process exits.
Other pages should only live as long as the process that has them
mmapped, but at the moment our driver is (perhaps mistakenly?)
explicitly freeing them as part of fops->close.
I am quite unclear in my head on what mechanism to use to manage the
lifetimes of these pages. Should I use get_page on the pages that span
multiple process lifetimes, and let whatever cleans up the process's
mappings handle the pages that should go away with the process? Is it
even safe to do that, if I allocated them with dma_alloc_coherent
instead of kmalloc?
Thanks for your patience and help,
<b
next prev parent reply other threads:[~2006-03-16 4:58 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <71644dd19420ddb07a75.1141922823@localhost.localdomain>
2006-03-09 23:28 ` Roland Dreier
2006-03-09 23:55 ` Bryan O'Sullivan
2006-03-10 0:01 ` Roland Dreier
2006-03-10 0:07 ` Bryan O'Sullivan
2006-03-10 0:32 ` Roland Dreier
2006-03-10 0:36 ` Bryan O'Sullivan
2006-03-10 0:37 ` Andrew Morton
2006-03-10 0:50 ` Bryan O'Sullivan
2006-03-16 0:56 ` Bryan O'Sullivan
2006-03-16 1:51 ` Roland Dreier
2006-03-16 2:11 ` Bryan O'Sullivan
2006-03-16 2:37 ` Roland Dreier
2006-03-16 2:52 ` Bryan O'Sullivan
2006-03-16 2:56 ` Bryan O'Sullivan
2006-03-16 3:28 ` Andrew Morton
2006-03-16 4:58 ` Bryan O'Sullivan [this message]
2006-03-16 5:38 ` Andrew Morton
2006-03-16 5:54 ` Roland Dreier
2006-03-16 6:17 ` Andrew Morton
2006-03-16 6:44 ` Nick Piggin
2006-03-16 9:39 ` Andrew Morton
2006-03-16 10:00 ` Nick Piggin
2006-03-16 7:25 ` Roland Dreier
2006-03-16 16:46 ` Linus Torvalds
2006-03-16 14:57 ` Hugh Dickins
2006-03-16 6:31 ` Nick Piggin
2006-03-16 14:34 ` Hugh Dickins
2006-03-17 0:37 ` Nick Piggin
2006-03-17 1:09 ` Roland Dreier
2006-03-17 15:27 ` Hugh Dickins
2006-03-17 22:21 ` Nick Piggin
2006-03-17 16:11 ` Bryan O'Sullivan
2006-03-17 16:28 ` Linus Torvalds
2006-03-17 16:40 ` Bryan O'Sullivan
2006-03-17 22:28 ` Nick Piggin
2006-03-17 22:14 ` Nick Piggin
2006-03-16 15:12 ` Bryan O'Sullivan
2006-03-16 17:08 ` Linus Torvalds
2006-03-16 17:46 ` Hugh Dickins
2006-03-16 17:53 ` Bryan O'Sullivan
2006-03-16 14:24 ` Hugh Dickins
2006-03-16 15:33 ` Bryan O'Sullivan
2006-03-16 17:23 ` Hugh Dickins
2006-03-16 17:40 ` Bryan O'Sullivan
2006-03-16 19:52 ` Bryan O'Sullivan
2006-03-16 20:10 ` Hugh Dickins
2006-03-16 20:35 ` Linus Torvalds
2006-03-16 20:43 ` Bryan O'Sullivan
2006-03-21 20:52 ` Bryan O'Sullivan
2006-03-21 23:20 ` Hugh Dickins
2006-03-22 15:58 ` Bryan O'Sullivan
2006-03-22 16:19 ` Linus Torvalds
2006-03-22 16:43 ` Bryan O'Sullivan
2006-03-22 17:46 ` Hugh Dickins
2006-03-22 17:53 ` Bryan O'Sullivan
2006-03-16 23:37 ` Roland Dreier
2006-03-16 23:51 ` Remapping pages mapped to userspace (was: [PATCH 10 of 20] ipath - support for userspace apps using core driver) Roland Dreier
2006-03-16 23:56 ` Bryan O'Sullivan
2006-03-17 1:10 ` Remapping pages mapped to userspace Roland Dreier
2006-03-17 1:12 ` Roland Dreier
2006-03-17 1:28 ` Alan Cox
2006-03-17 2:16 ` Roland Dreier
2006-03-17 17:13 ` Remapping pages mapped to userspace (was: [PATCH 10 of 20] ipath - support for userspace apps using core driver) Hugh Dickins
2006-03-17 17:17 ` Bryan O'Sullivan
2006-03-17 17:30 ` Linus Torvalds
2006-03-17 18:20 ` Hugh Dickins
2006-03-17 22:58 ` Remapping pages mapped to userspace Roland Dreier
2006-03-16 15:08 ` [PATCH 10 of 20] ipath - support for userspace apps using core driver Bryan O'Sullivan
2006-03-16 17:27 ` Hugh Dickins
2006-03-16 17:44 ` Bryan O'Sullivan
2006-03-16 16:52 ` Bryan O'Sullivan
2006-03-16 3:58 ` Linus Torvalds
2006-03-16 4:53 ` Roland Dreier
2006-03-16 2:28 ` Linus Torvalds
2006-03-09 23:33 ` Roland Dreier
2006-03-09 23:56 ` Bryan O'Sullivan
2006-03-10 0:35 [PATCH 0 of 20] [RFC] ipath driver - another round for review Bryan O'Sullivan
2006-03-10 0:35 ` [PATCH 10 of 20] ipath - support for userspace apps using core driver Bryan O'Sullivan
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=1142485103.25297.13.camel@camp4.serpentine.com \
--to=bos@pathscale.com \
--cc=Hugh@veritas.com \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=torvalds@osdl.org \
/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
all inboxes | Powered by JetHome®