From: Florian Fainelli <f.fainelli@gmail.com>
To: Stefan Agner <stefan@agner.ch>,
Andrew Morton <akpm@linux-foundation.org>
Cc: minchan@kernel.org, ngupta@vflare.org,
sergey.senozhatsky.work@gmail.com, sjenning@linux.vnet.ibm.com,
gregkh@linuxfoundation.org, arnd@arndb.de, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS
Date: Sat, 7 Nov 2020 20:54:13 -0800 [thread overview]
Message-ID: <29cb13a4-e10d-a394-3c00-1d7721a2dc0a@gmail.com> (raw)
In-Reply-To: <fb776accd14ddb5ec1251a6147a2ff45@agner.ch>
On 11/7/2020 5:16 PM, Stefan Agner wrote:
> On 2020-11-08 01:56, Andrew Morton wrote:
>> On Sat, 7 Nov 2020 16:22:06 +0100 Stefan Agner <stefan@agner.ch> wrote:
>>
>>> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
>>> include it in asm/pgtable.h. Include asm/sparsemem.h directly to get
>>> the MAX_PHYSMEM_BITS define on all architectures.
>>>
>>> This fixes a crash when accessing zram on 32-bit ARM platform with LPAE and
>>> more than 4GB of memory:
>>> Unable to handle kernel NULL pointer dereference at virtual address 00000000
>>
>> Mysterious. Presumably without this include, some compilation unit is
>> picking up the wrong value of MAX_PHYSMEM_BITS? But I couldn't
>> actually see where/how this occurs. Can you please explain further?
>
> Not sure if I got that right, but from what I understand if
> MAX_PHYSMEM_BITS is not set in mm/zsmalloc.c it will set
> MAX_PHYSMEM_BITS to BITS_PER_LONG. And this is 32-bit, too short when
> LPAE is in use...
You should probably include this in your commit message since that is
describing the bug and then your fix makes complete sense.
--
Florian
next prev parent reply other threads:[~2020-11-08 5:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-07 15:22 [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS Stefan Agner
2020-11-08 0:56 ` Andrew Morton
2020-11-08 1:16 ` Stefan Agner
2020-11-08 4:54 ` Florian Fainelli [this message]
2020-11-09 17:04 ` Minchan Kim
2020-11-08 6:46 ` Mike Rapoport
2020-11-10 9:29 ` Stefan Agner
2020-11-10 9:58 ` Mike Rapoport
2020-11-10 11:21 ` Arnd Bergmann
2020-11-10 11:21 ` Arnd Bergmann
2020-11-10 12:22 ` Stefan Agner
2020-11-10 15:19 ` Arnd Bergmann
2020-11-10 15:19 ` Arnd Bergmann
2020-11-10 16:21 ` Mike Rapoport
2020-11-10 23:36 ` Minchan Kim
2020-11-11 6:52 ` Mike Rapoport
2020-11-12 19:49 ` Minchan Kim
2020-11-11 9:33 ` Arnd Bergmann
2020-11-11 9:33 ` Arnd Bergmann
2020-11-11 10:26 ` Mike Rapoport
2020-11-11 10:57 ` Arnd Bergmann
2020-11-11 10:57 ` Arnd Bergmann
2020-11-11 11:04 ` Mike Rapoport
2020-11-11 13:39 ` Thomas Bogendoerfer
2020-11-11 14:33 ` Arnd Bergmann
2020-11-11 14:33 ` Arnd Bergmann
2020-11-12 19:50 ` Minchan Kim
2020-11-12 23:46 ` Florian Fainelli
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=29cb13a4-e10d-a394-3c00-1d7721a2dc0a@gmail.com \
--to=f.fainelli@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sjenning@linux.vnet.ibm.com \
--cc=stefan@agner.ch \
/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.