From: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Linux-MM <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Kees Cook <keescook@chromium.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: exec error: BUG: Bad rss-counter
Date: Tue, 2 Mar 2021 23:07:36 -0800 [thread overview]
Message-ID: <CALCv0x1-zWOXNDntm8+C6BwHdM5Ykda2jxuwoChnrTX2TuOOPg@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjVWMnH2LfFNnXcf6=WuU1RyLa_cgTEOqnViHiqDrqQjg@mail.gmail.com>
On Tue, Mar 2, 2021 at 10:56 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Mon, Mar 1, 2021 at 11:59 PM Ilya Lipnitskiy
> <ilya.lipnitskiy@gmail.com> wrote:
> >
> > Good to know. Some more digging and I can say that we hit this error
> > when trying to unmap PFN 0 (is_zero_pfn(pfn) returns TRUE,
> > vm_normal_page returns NULL, zap_pte_range does not decrement
> > MM_ANONPAGES RSS counter). Is my understanding correct that PFN 0 is
> > usable, but special? Or am I totally off the mark here?
>
> PFN 0 should be usable - depending on architecture, of course - and
> shouldn't even be special in any way.
>
> is_zero_pfn(pfn) is *not* meant to test for pfn being 0 - it's meant
> to test for the pfn pointing to the special zero-filled page. The two
> _could_ be the same thing, of course, but generally are not (h8300
> seems to say "we use pfn 0 as the zero page" if I read things right).
>
> In fact, there can be many zero-filled pages - architectures with
> virtually mapped caches that want cache coloring have multiple
> contiguous zero-filled pages and then map in the right one based on
> virtual address. I'm not sure why it would matter (the zero-page is
> always mapped read-only, so any physical aliases should be a
> non-issue), but whatever..
>
> > Here is the (optimized) stack trace when the counter does not get decremented:
> > [<8015b078>] vm_normal_page+0x114/0x1a8
>
> Yes, if "is_zero_pfn()" returns true, then it won't be considered a
> normal page, and is not refcounted.
>
> But that should only trigger for pfn == zero_pfn, and zero_pfn should
> be initialized to
>
> zero_pfn = page_to_pfn(ZERO_PAGE(0));
>
> so it _sounds_ like you possibly have something odd going on with ZERO_PAGE.
Thanks for explaining this - I have figured out that zero_pfn gets set
a little late (see other response for details). Until init_zero_pfn()
is called, zero_pfn==0, after - zero_pfn==5120. Seems somewhat bad,
unless my system is breaking rules by checking zero_pfn before it was
initialized ;)
>
> Yes, one architecture does actually make pfn 0 _be_ the zero page, but
> you said MIPS, and that does do the page coloring games, and has
>
> #define ZERO_PAGE(vaddr) \
> (virt_to_page((void *)(empty_zero_page + (((unsigned
> long)(vaddr)) & zero_page_mask))))
>
> where zero_page_mask is the page colorign mask, and empty_zero_page is
> allocated in setup_zero_pages() fairly early in mem_init() (again, it
> allocates multiple pages depending on the page ordering - see that
> horrible virtual cache thing with cpu_has_vce).
>
> So PFN 0 shouldn't be an issue at all.
>
> Of course, since you said this was an embedded MIPS platform, maybe
> it's one of the broken ones with virtual caches and cpu_has_vce is
> set. I'm not sure how much testing that has gotten lately. MOST of the
> later MIPS architectures walked away from the pure virtual cache
> setups.
FWIW, here is the CPU info from my platform, and cpu_has_vce is not set:
system type : MediaTek MT7621 ver:1 eco:3
machine : Ubiquiti EdgeRouter X
processor : 0
cpu model : MIPS 1004Kc V2.15
BogoMIPS : 581.63
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc,
0x0ffc, 0x0ffb, 0x0ffb]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented : mips16 dsp mt
Options implemented : tlb 4kex 4k_cache prefetch mcheck ejtag llsc
pindexed_dcache userlocal vint perf_cntr_intr_bit cdmm perf
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VPE : 0
VCED exceptions : not available
VCEI exceptions : not available
>
> Linus
Ilya
next prev parent reply other threads:[~2021-03-04 0:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 3:28 exec error: BUG: Bad rss-counter Ilya Lipnitskiy
2021-03-01 20:43 ` Eric W. Biederman
2021-03-02 7:59 ` Ilya Lipnitskiy
2021-03-02 18:56 ` Linus Torvalds
2021-03-03 7:07 ` Ilya Lipnitskiy [this message]
2021-03-02 19:37 ` Eric W. Biederman
2021-03-03 7:01 ` Ilya Lipnitskiy
2021-03-03 15:50 ` Eric W. Biederman
2021-03-03 15:55 ` Ilya Lipnitskiy
2021-03-03 16:07 ` Eric W. Biederman
2021-03-20 15:59 ` Zhou Yanjie
2021-03-29 2:48 ` Ilya Lipnitskiy
2021-03-30 4:56 ` Zhou Yanjie
2021-03-30 16:11 ` Linus Torvalds
2021-03-30 16:36 ` Ilya Lipnitskiy
2021-03-30 16:47 ` Linus Torvalds
2021-03-29 2:46 ` Ilya Lipnitskiy
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=CALCv0x1-zWOXNDntm8+C6BwHdM5Ykda2jxuwoChnrTX2TuOOPg@mail.gmail.com \
--to=ilya.lipnitskiy@gmail.com \
--cc=ebiederm@xmission.com \
--cc=hch@lst.de \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.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 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).