From: Minchan Kim <minchan@kernel.org>
To: Stefan Agner <stefan@agner.ch>
Cc: Andrew Morton <akpm@linux-foundation.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: Mon, 9 Nov 2020 09:04:06 -0800 [thread overview]
Message-ID: <20201109170406.GC449970@google.com> (raw)
In-Reply-To: <fb776accd14ddb5ec1251a6147a2ff45@agner.ch>
On Sun, Nov 08, 2020 at 02:16:37AM +0100, 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...
True. It's headache in the zsmalloc.
Somedays I'd really like to fix it via redesigning of metadata
management.
Thanks for the fixing the ancient bug, Stefan.
next prev parent reply other threads:[~2020-11-09 17:04 UTC|newest]
Thread overview: 23+ 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
2020-11-09 17:04 ` Minchan Kim [this message]
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 12:22 ` Stefan Agner
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 10:26 ` Mike Rapoport
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-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=20201109170406.GC449970@google.com \
--to=minchan@kernel.org \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).