linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guo Ren <guoren@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: Linux 5.0-rc1 (test results)
Date: Tue, 8 Jan 2019 17:51:07 +0800	[thread overview]
Message-ID: <20190108095107.GA25409@guoren-Inspiron-7460> (raw)
In-Reply-To: <CAHk-=wjt6oKtYuJ-EOGSO1m8vBdPa+g2_6WZ6MKCwfu4afoSrw@mail.gmail.com>

Hi Linus,
On Mon, Jan 07, 2019 at 03:21:45PM -0800, Linus Torvalds wrote:
> On Mon, Jan 7, 2019 at 11:26 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Bisect points to commit 4cf58924951ef ("mm: treewide: remove unused address
> > argument from pte_alloc functions"). Interesting - wasn't that supposed
> > to be automatic ?
> >
> > csky does use the the removed address argument, so I won't even try to
> > provide a patch. Copying csky maintainer instead.
> 
> Hmm. Interesting. The csky code seems to have some odd "poison pte
> contents with ones if the address has the high bit set".
PTE contents is the only _PAGE_GLOBAL bit which could let mmu ignore the
ASID. One tlb entry is composed of 2 pfns and there is one GLOBAL bit in
the tlb entry. When C-SKY MMU hard-refill a tlb entry into the TLB buffer,
it will get pfn0-GLOBAL & pfn1-GLOBAL from the memory and put the result
into the TLB buffer.

If pfn0 is valid & pfn1 is invalid, we also must keep invalid pte_t with GLOBAL
bit set for C-SKY MMU.

Also see pte_clear() and pte_none() in pgtable.h.

> 
> Which makes little or no sense. The "high bit set" case is for kernel
> page tables, but that's exactly the "pte_alloc_one()" vs
> "pte_alloc_one_kernel()" distinction.
> 
> So testing the address seems entirely wrong.
Yes, testing address is no necessary, I'll remove it.

> 
> But there's other strangeness in there too. For example,
> pte_alloc_one_kernel() will just write directly to the page. And
> pte_alloc_one() will do a "kmap_atomic()" on the page it allocates,
> except since it uses GFP_KERNEL, that's entirely pointless.
> 
> Is the alloc_pages() in pte_alloc_one() perhaps meant to use
> GFP_HIGHUSER instead?
No GFP_HIGHUSER, kmap_atomic should be removed and I'll use __GFP_ZERO
instead.

> Is this perhaps some copy-paste issue?
:P

> 
> So I *think* the removal of the 'address' use in csky should be
> simple, but yes, this needs a csky maintainer to look at.
> 
Here is my new implementation:

static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm)
{
	pte_t *pte;
	unsigned long i;

	pte = (pte_t *) __get_free_page(GFP_KERNEL | __GFP_RETRY_MAYFAIL);
						     ^^^^^^^^^^^^^^^^^^^
						     It's necessary ?
						     x86 & arm don't use
						     it.
	if (!pte)
		return NULL;

	for (i = 0; i < PAGE_SIZE/sizeof(pte_t); i++)
		(pte + i)->pte_low = _PAGE_GLOBAL;

	return pte;
}

static inline struct page *pte_alloc_one(struct mm_struct *mm)
{
	struct page *pte;

	pte = alloc_pages(GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_ZERO, 0);
	if (!pte)
		return NULL;

	if (!pgtable_page_ctor(pte)) {
		__free_page(pte);
		return NULL;
	}

	return pte;
}

Best Regards
 Guo Ren

  reply	other threads:[~2019-01-08  9:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-07  2:14 Linux 5.0-rc1 Linus Torvalds
2019-01-07  5:07 ` linux-next: stats (was: Linux 5.0-rc1) Stephen Rothwell
2019-01-07 19:26 ` Linux 5.0-rc1 (test results) Guenter Roeck
2019-01-07 23:21   ` Linus Torvalds
2019-01-08  9:51     ` Guo Ren [this message]
2019-01-08 15:40       ` Michal Hocko
2019-01-08 16:16         ` Guo Ren
2019-01-08 17:29           ` Michal Hocko
2019-02-09 19:42 ` Linux 5.0-rc1 Paul Bolle
2019-02-11  0:01   ` isdn

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=20190108095107.GA25409@guoren-Inspiron-7460 \
    --to=guoren@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --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).