All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laura Abbott <labbott@redhat.com>
To: Matthew Wilcox <willy@infradead.org>,
	Kai Heng Feng <kai.heng.feng@canonical.com>
Cc: Michal Hocko <mhocko@suse.com>,
	linux-mm@kvack.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly")
Date: Thu, 8 Feb 2018 09:56:42 -0800	[thread overview]
Message-ID: <f8be3fc9-a96d-bf37-4da0-43220014caed@redhat.com> (raw)
In-Reply-To: <20180208130649.GA15846@bombadil.infradead.org>

On 02/08/2018 05:06 AM, Matthew Wilcox wrote:
> On Thu, Feb 08, 2018 at 02:29:57PM +0800, Kai Heng Feng wrote:
>> A user with i386 instead of AMD64 machine reports [1] that commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”) causes a regression.
>> BUG_ON(PageHighMem(pg)) in drivers/media/common/saa7146/saa7146_core.c always gets triggered after that commit.
> 
> Well, the BUG_ON is wrong.  You can absolutely have pages which are both
> HighMem and under the 4GB boundary.  Only the first 896MB (iirc) are LowMem,
> and the next 3GB of pages are available to vmalloc_32().
> 
>> Also there are other BUG_ON(PageHighMem()) in drivers/media, I think they will get hit by same regression in 32bit machine too.
> 
> I fixed one of them.  I think the other three are also bogus, but it's
> hard to say; the comments say "DMA to HighMem might not work", and they
> probably mean "above the 4GB boundary", but I really don't know.
> 
> (since two drivers now have this code, maybe it should be part of the core
> MM API?  Or maybe there's already something better they should be using?)
> 

The comment at the top said the function was copied from videobuf-dma-sg.c
so might be worth making it common.

> diff --git a/drivers/media/common/saa7146/saa7146_core.c b/drivers/media/common/saa7146/saa7146_core.c
> index 9f7c5b0a6b45..329fd43228ff 100644
> --- a/drivers/media/common/saa7146/saa7146_core.c
> +++ b/drivers/media/common/saa7146/saa7146_core.c
> @@ -160,7 +160,7 @@ static struct scatterlist* vmalloc_to_sg(unsigned char *virt, int nr_pages)
>   		pg = vmalloc_to_page(virt);
>   		if (NULL == pg)
>   			goto err;
> -		BUG_ON(PageHighMem(pg));
> +		BUG_ON(page_to_pfn(pg) >= (1 << (32 - PAGE_SHIFT)));
>   		sg_set_page(&sglist[i], pg, PAGE_SIZE, 0);
>   	}
>   	return sglist;
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index f412429cf5ba..b5ec74b9c867 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -77,7 +77,7 @@ static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char *virt,
>   		pg = vmalloc_to_page(virt);
>   		if (NULL == pg)
>   			goto err;
> -		BUG_ON(PageHighMem(pg));
> +		BUG_ON(page_to_pfn(pg) >= (1 << (32 - PAGE_SHIFT)));
>   		sg_set_page(&sglist[i], pg, PAGE_SIZE, 0);
>   	}
>   	return sglist;
> 

the vzalloc in this function needs to be switched to vmalloc32 if it
actually wants to guarantee 32-bit memory.

Thanks,
Laura

WARNING: multiple messages have this Message-ID (diff)
From: Laura Abbott <labbott@redhat.com>
To: Matthew Wilcox <willy@infradead.org>,
	Kai Heng Feng <kai.heng.feng@canonical.com>
Cc: Michal Hocko <mhocko@suse.com>,
	linux-mm@kvack.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly")
Date: Thu, 8 Feb 2018 09:56:42 -0800	[thread overview]
Message-ID: <f8be3fc9-a96d-bf37-4da0-43220014caed@redhat.com> (raw)
In-Reply-To: <20180208130649.GA15846@bombadil.infradead.org>

On 02/08/2018 05:06 AM, Matthew Wilcox wrote:
> On Thu, Feb 08, 2018 at 02:29:57PM +0800, Kai Heng Feng wrote:
>> A user with i386 instead of AMD64 machine reports [1] that commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitlya??) causes a regression.
>> BUG_ON(PageHighMem(pg)) in drivers/media/common/saa7146/saa7146_core.c always gets triggered after that commit.
> 
> Well, the BUG_ON is wrong.  You can absolutely have pages which are both
> HighMem and under the 4GB boundary.  Only the first 896MB (iirc) are LowMem,
> and the next 3GB of pages are available to vmalloc_32().
> 
>> Also there are other BUG_ON(PageHighMem()) in drivers/media, I think they will get hit by same regression in 32bit machine too.
> 
> I fixed one of them.  I think the other three are also bogus, but it's
> hard to say; the comments say "DMA to HighMem might not work", and they
> probably mean "above the 4GB boundary", but I really don't know.
> 
> (since two drivers now have this code, maybe it should be part of the core
> MM API?  Or maybe there's already something better they should be using?)
> 

The comment at the top said the function was copied from videobuf-dma-sg.c
so might be worth making it common.

> diff --git a/drivers/media/common/saa7146/saa7146_core.c b/drivers/media/common/saa7146/saa7146_core.c
> index 9f7c5b0a6b45..329fd43228ff 100644
> --- a/drivers/media/common/saa7146/saa7146_core.c
> +++ b/drivers/media/common/saa7146/saa7146_core.c
> @@ -160,7 +160,7 @@ static struct scatterlist* vmalloc_to_sg(unsigned char *virt, int nr_pages)
>   		pg = vmalloc_to_page(virt);
>   		if (NULL == pg)
>   			goto err;
> -		BUG_ON(PageHighMem(pg));
> +		BUG_ON(page_to_pfn(pg) >= (1 << (32 - PAGE_SHIFT)));
>   		sg_set_page(&sglist[i], pg, PAGE_SIZE, 0);
>   	}
>   	return sglist;
> diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c b/drivers/media/v4l2-core/videobuf-dma-sg.c
> index f412429cf5ba..b5ec74b9c867 100644
> --- a/drivers/media/v4l2-core/videobuf-dma-sg.c
> +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
> @@ -77,7 +77,7 @@ static struct scatterlist *videobuf_vmalloc_to_sg(unsigned char *virt,
>   		pg = vmalloc_to_page(virt);
>   		if (NULL == pg)
>   			goto err;
> -		BUG_ON(PageHighMem(pg));
> +		BUG_ON(page_to_pfn(pg) >= (1 << (32 - PAGE_SHIFT)));
>   		sg_set_page(&sglist[i], pg, PAGE_SIZE, 0);
>   	}
>   	return sglist;
> 

the vzalloc in this function needs to be switched to vmalloc32 if it
actually wants to guarantee 32-bit memory.

Thanks,
Laura

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2018-02-08 17:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-08  6:29 Regression after commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly") Kai Heng Feng
2018-02-08  6:29 ` Kai Heng Feng
2018-02-08 13:06 ` Matthew Wilcox
2018-02-08 13:06   ` Matthew Wilcox
2018-02-08 17:56   ` Laura Abbott [this message]
2018-02-08 17:56     ` Laura Abbott
2018-02-08 18:18     ` Matthew Wilcox
2018-02-08 18:18       ` Matthew Wilcox
2018-02-08 18:34       ` Laura Abbott
2018-02-08 18:34         ` Laura Abbott
2018-02-08 23:20   ` Matthew Wilcox
2018-02-08 23:20     ` Matthew Wilcox
2018-02-09  4:08     ` Matthew Wilcox
2018-02-09  4:08       ` Matthew Wilcox
2018-02-09  9:12       ` Kai Heng Feng
2018-02-09  9:12         ` Kai Heng Feng
2018-02-09 14:07         ` Matthew Wilcox
2018-02-09 14:07           ` Matthew Wilcox
2018-02-11  9:26     ` Michal Hocko
2018-02-11  9:26       ` Michal Hocko
2018-02-11 11:28       ` Matthew Wilcox
2018-02-11 11:28         ` Matthew Wilcox
2018-02-11 12:05         ` Matthew Wilcox
2018-02-11 12:05           ` Matthew Wilcox
2018-02-11 23:51           ` Matthew Wilcox
2018-02-11 23:51             ` Matthew Wilcox
2018-02-14 14:04             ` Michal Hocko
2018-02-14 14:04               ` Michal Hocko
2018-02-12  9:50         ` Michal Hocko
2018-02-12  9:50           ` Michal Hocko

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=f8be3fc9-a96d-bf37-4da0-43220014caed@redhat.com \
    --to=labbott@redhat.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=willy@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.