On Tue, Sep 12, 2017 at 04:05:22PM +0800, Yisheng Xie wrote:
>
>
> On 2017/9/12 0:03, Juerg Haefliger wrote:
> >
> >
> > On 09/11/2017 04:50 PM, Tycho Andersen wrote:
> >> Hi Yisheng,
> >>
> >> On Mon, Sep 11, 2017 at 03:24:09PM +0800, Yisheng Xie wrote:
> >>>> +void xpfo_alloc_pages(struct page *page, int order, gfp_t gfp)
> >>>> +{
> >>>> + int i, flush_tlb = 0;
> >>>> + struct xpfo *xpfo;
> >>>> +
> >>>> + if (!static_branch_unlikely(&xpfo_inited))
> >>>> + return;
> >>>> +
> >>>> + for (i = 0; i < (1 << order); i++) {
> >>>> + xpfo = lookup_xpfo(page + i);
> >>>> + if (!xpfo)
> >>>> + continue;
> >>>> +
> >>>> + WARN(test_bit(XPFO_PAGE_UNMAPPED, &xpfo->flags),
> >>>> + "xpfo: unmapped page being allocated\n");
> >>>> +
> >>>> + /* Initialize the map lock and map counter */
> >>>> + if (unlikely(!xpfo->inited)) {
> >>>> + spin_lock_init(&xpfo->maplock);
> >>>> + atomic_set(&xpfo->mapcount, 0);
> >>>> + xpfo->inited = true;
> >>>> + }
> >>>> + WARN(atomic_read(&xpfo->mapcount),
> >>>> + "xpfo: already mapped page being allocated\n");
> >>>> +
> >>>> + if ((gfp & GFP_HIGHUSER) == GFP_HIGHUSER) {
> >>>> + /*
> >>>> + * Tag the page as a user page and flush the TLB if it
> >>>> + * was previously allocated to the kernel.
> >>>> + */
> >>>> + if (!test_and_set_bit(XPFO_PAGE_USER, &xpfo->flags))
> >>>> + flush_tlb = 1;
> >>>
> >>> I'm not sure whether I am miss anything, however, when the page was previously allocated
> >>> to kernel, should we unmap the physmap (the kernel's page table) here? For we allocate
> >>> the page to user now
> >>>
> >> Yes, I think you're right. Oddly, the XPFO_READ_USER test works
>
> Hi Tycho,
> Could you share this test? I'd like to know how it works.
See the last patch in the series.
> >> correctly for me, but I think (?) should not because of this bug...
> >
> > IIRC, this is an optimization carried forward from the initial
> > implementation.
> Hi Juerg,
>
> hmm.. If below is the first version, then it seems this exist from the first version:
> https://patchwork.kernel.org/patch/8437451/
>
> > The assumption is that the kernel will map the user
> > buffer so it's not unmapped on allocation but only on the first (and
> > subsequent) call of kunmap.
>
> IMO, before a page is allocated, it is in buddy system, which means it is free
> and no other 'map' on the page except direct map. Then if the page is allocated
> to user, XPFO should unmap the direct map. otherwise the ret2dir may works at
> this window before it is freed. Or maybe I'm still missing anything.
I agree that it seems broken. I'm just not sure why the test doesn't
fail. It's certainly worth understanding.
Tycho
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
