[PATCH] hugetlb: Fix clear_user_highpage arguments - Kernel

This is a discussion on [PATCH] hugetlb: Fix clear_user_highpage arguments - Kernel ; The virtual address space argument of clear_user_highpage is supposed to be the virtual address where the page being cleared will eventually be mapped. This allows architectures with virtually indexed caches a few clever tricks. That sort of trick falls over ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: [PATCH] hugetlb: Fix clear_user_highpage arguments

  1. [PATCH] hugetlb: Fix clear_user_highpage arguments

    The virtual address space argument of clear_user_highpage is supposed to
    be the virtual address where the page being cleared will eventually be
    mapped. This allows architectures with virtually indexed caches a few
    clever tricks. That sort of trick falls over in painful ways if the
    virtual address argument is wrong.

    Signed-off-by: Ralf Baechle

    diff --git a/mm/hugetlb.c b/mm/hugetlb.c
    index 84c795e..eab8c42 100644
    --- a/mm/hugetlb.c
    +++ b/mm/hugetlb.c
    @@ -42,7 +42,7 @@ static void clear_huge_page(struct page *page, unsigned long addr)
    might_sleep();
    for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); i++) {
    cond_resched();
    - clear_user_highpage(page + i, addr);
    + clear_user_highpage(page + i, addr + i * PAGE_SIZE);
    }
    }

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] hugetlb: Fix clear_user_highpage arguments

    On Fri, 28 Sep 2007 17:35:45 +0100 Ralf Baechle wrote:

    > The virtual address space argument of clear_user_highpage is supposed to
    > be the virtual address where the page being cleared will eventually be
    > mapped. This allows architectures with virtually indexed caches a few
    > clever tricks. That sort of trick falls over in painful ways if the
    > virtual address argument is wrong.


    yeah, but only if you're using a weird CPU architecture

    > Signed-off-by: Ralf Baechle
    >
    > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
    > index 84c795e..eab8c42 100644
    > --- a/mm/hugetlb.c
    > +++ b/mm/hugetlb.c
    > @@ -42,7 +42,7 @@ static void clear_huge_page(struct page *page, unsigned long addr)
    > might_sleep();
    > for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); i++) {
    > cond_resched();
    > - clear_user_highpage(page + i, addr);
    > + clear_user_highpage(page + i, addr + i * PAGE_SIZE);
    > }
    > }
    >


    I'll add this to the 2.6.23 queue. Is it needed in 2.6.22.x?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] hugetlb: Fix clear_user_highpage arguments

    On Fri, Sep 28, 2007 at 11:45:26AM -0700, Andrew Morton wrote:

    >
    > > The virtual address space argument of clear_user_highpage is supposed to
    > > be the virtual address where the page being cleared will eventually be
    > > mapped. This allows architectures with virtually indexed caches a few
    > > clever tricks. That sort of trick falls over in painful ways if the
    > > virtual address argument is wrong.

    >
    > yeah, but only if you're using a weird CPU architecture


    I guess once I convinced your employer that weird CPU architectures
    deliver more punch for the watt they stop being so weird ;-)

    > >
    > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
    > > index 84c795e..eab8c42 100644
    > > --- a/mm/hugetlb.c
    > > +++ b/mm/hugetlb.c
    > > @@ -42,7 +42,7 @@ static void clear_huge_page(struct page *page, unsigned long addr)
    > > might_sleep();
    > > for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); i++) {
    > > cond_resched();
    > > - clear_user_highpage(page + i, addr);
    > > + clear_user_highpage(page + i, addr + i * PAGE_SIZE);
    > > }
    > > }
    > >

    >
    > I'll add this to the 2.6.23 queue. Is it needed in 2.6.22.x?


    It's totally theoretical atm, MIPS doesn't support hugetlb and I'm not
    even working on it. I just happened to spot the issue.

    Ralf
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] hugetlb: Fix clear_user_highpage arguments

    On Fri, 28 Sep 2007 19:53:35 +0100 Ralf Baechle wrote:

    > On Fri, Sep 28, 2007 at 11:45:26AM -0700, Andrew Morton wrote:
    >
    > >
    > > > The virtual address space argument of clear_user_highpage is supposed to
    > > > be the virtual address where the page being cleared will eventually be
    > > > mapped. This allows architectures with virtually indexed caches a few
    > > > clever tricks. That sort of trick falls over in painful ways if the
    > > > virtual address argument is wrong.

    > >
    > > yeah, but only if you're using a weird CPU architecture

    >
    > I guess once I convinced your employer that weird CPU architectures
    > deliver more punch for the watt they stop being so weird ;-)




    > > >
    > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
    > > > index 84c795e..eab8c42 100644
    > > > --- a/mm/hugetlb.c
    > > > +++ b/mm/hugetlb.c
    > > > @@ -42,7 +42,7 @@ static void clear_huge_page(struct page *page, unsigned long addr)
    > > > might_sleep();
    > > > for (i = 0; i < (HPAGE_SIZE/PAGE_SIZE); i++) {
    > > > cond_resched();
    > > > - clear_user_highpage(page + i, addr);
    > > > + clear_user_highpage(page + i, addr + i * PAGE_SIZE);
    > > > }
    > > > }
    > > >

    > >
    > > I'll add this to the 2.6.23 queue. Is it needed in 2.6.22.x?

    >
    > It's totally theoretical atm, MIPS doesn't support hugetlb and I'm not
    > even working on it. I just happened to spot the issue.


    sparc64 might care about this bug.

    Anyway, I'll plop it in 2.6.23.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread