LKML Archive on
 help / color / Atom feed
From: Rafael David Tinoco <>
To: Sergey Senozhatsky <>
Cc: Rafael David Tinoco <>,,,,
	Russell King <>,
	Mark Brown <>, Nitin Gupta <>,
	Minchan Kim <>,
	Andrew Morton <>
Subject: Re: [PATCH 1/2] mm/zsmalloc.c: check encoded object value overflow for PAE
Date: Thu, 25 Oct 2018 08:03:47 -0300
Message-ID: <> (raw)
In-Reply-To: <20181025052901.GA17799@jagdpanzerIV>

On Thu, Oct 25, 2018 at 2:29 AM, Sergey Senozhatsky
<> wrote:
> On (10/24/18 22:27), Rafael David Tinoco wrote:
>>  static unsigned long location_to_obj(struct page *page, unsigned int obj_idx)
>>  {
>> -     unsigned long obj;
>> +     unsigned long obj, pfn;
>> +
>> +     pfn = page_to_pfn(page);
>> +
>> +     if (unlikely(OBJ_OVERFLOW(pfn)))
>> +             BUG();
> The trend these days is to have less BUG/BUG_ON-s in the kernel.
>         -ss

For this case, IMHO, it is worth.

It will avoid a investigation like: and and #c8, where I
had to poison slab allocation - to force both zs_handle and zspage
slabs not to be merged - and to make sure the zspage slab had a good
magic number AND to identify why the bad paging request happened.

If this happens again, for any other arch supporting PAE that does not
the kernel will panic, no matter what, by the time it reaches
obj_to_location(). Things can be more complicated about declarations
for PAE if we consider ARM can declare MAX_PHYSMEM_BITS differently in
arch/arm/mach-XXX and/or, for this case, when having, or not SPARSEMEM
set (if I had SPARSEMEM set I would not face this, for example).

If this occurs, the kernel will panic, no matter what, by the time it
reaches obj_to_location()... so why not to BUG() here and let user to
know exactly where it panic-ed and why ? Other option would be to
WARN() here and let it panic naturally because of bad paging request
in a very near future... please advise.

Best Rgds

  reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-25  1:27 Rafael David Tinoco
2018-10-25  1:27 ` [PATCH 2/2] mm/zsmalloc.c: fix zsmalloc ARM LPAE support Rafael David Tinoco
2018-10-25  5:29 ` [PATCH 1/2] mm/zsmalloc.c: check encoded object value overflow for PAE Sergey Senozhatsky
2018-10-25 11:03   ` Rafael David Tinoco [this message]
2018-10-25 12:00 ` Russell King - ARM Linux
2018-10-25 12:37   ` Rafael David Tinoco
2018-10-25 13:43     ` Russell King - ARM Linux
2018-11-21  0:11       ` [PATCH v2] mm/zsmalloc.c: Fix zsmalloc 32-bit PAE support Rafael David Tinoco
2018-11-21  0:18         ` Rafael David Tinoco
2018-11-27 20:33           ` Rafael David Tinoco
2018-11-29  2:53             ` Sergey Senozhatsky
2018-10-25 12:42 ` [PATCH 1/2] mm/zsmalloc.c: check encoded object value overflow for PAE kbuild test robot

Reply instructions:

You may reply publically 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox