On Wed, Apr 1, 2015 at 1:15 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> Umm... Tangentially related question - do we have any IO codepaths where
> a pointer to page might stick around indefinitely?
Well, the one obvious case is "splice()", where things might sit
around forever in the pipe buffer. But that is fairly explicit, and
splice does have the "release" callback to notify you when it finally
does drop.
For something like regular read/write (or, aio_read with waiting for
completion), I don't see how anybody could really ever keep a
reference around to after the completion unless it has some odd
RCU-like freeing.
And for regular vmalloc'ed pages, I actually think that the page
refcounting *should* work fine. I'd still prefer to never see code
that doesn't directly own the area do it, because I could certainly
_imagine_ people playing games with vmap_page_range() (eg doing
things like mapping in partial hugepages or something odd like that).
Put another way: I think that it's fine if somebody does "vmalloc()"
and then does "vmalloc_to_page()" to look up the pages it just
allocated.
I'm *not* nearly as happy with code that does
if (is_vmalloc(addr)) vmalloc_to_page()
because that basically says "I don't know what this allocation is, but
if somebody plays around in vmalloc space, I'll just look up the
pages".
And yeah, it probably works fine. It just makes me really really
nervous. We use that vmalloc space for some mmio mappings too, don't
we? Worry9ing about things like that just make me go "auugh".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
