From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: akpm@linux-foundation.org, jgg@ziepe.ca, longpeng2@huawei.com,
mm-commits@vger.kernel.org, stable@vger.kernel.org,
willy@infradead.org, Naresh Kamboju <naresh.kamboju@linaro.org>
Subject: Re: + mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch added to -mm tree
Date: Mon, 30 Mar 2020 21:44:08 -0700 [thread overview]
Message-ID: <20200331044408.GW24988@linux.intel.com> (raw)
In-Reply-To: <eea7c1f8-a2e4-5af1-acc4-3eb21a076d37@oracle.com>
On Mon, Mar 30, 2020 at 08:35:29PM -0700, Mike Kravetz wrote:
> On 3/28/20 3:10 PM, akpm@linux-foundation.org wrote:
> > The patch titled
> > Subject: mm/hugetlb: fix a addressing exception caused by huge_pte_offset
> > has been added to the -mm tree. Its filename is
> > mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch
> >
> > This patch should soon appear at
> > http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch
> > and later at
> > http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch
> >
> > Before you just go and hit "reply", please:
> > a) Consider who else should be cc'ed
> > b) Prefer to cc a suitable mailing list as well
> > c) Ideally: find the original patch on the mailing list and do a
> > reply-to-all to that, adding suitable additional cc's
> >
> > *** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
> >
> > The -mm tree is included into linux-next and is updated
> > there every 3-4 working days
> >
> > ------------------------------------------------------
> > From: Longpeng <longpeng2@huawei.com>
> > Subject: mm/hugetlb: fix a addressing exception caused by huge_pte_offset
>
> This patch is what caused the BUG reported on i386 non-PAE kernel here:
>
> https://lore.kernel.org/linux-mm/CA+G9fYsJgZhhWLMzUxu_ZQ+THdCcJmFbHQ2ETA_YPP8M6yxOYA@mail.gmail.com/
>
> As a clue, when building in this environment I get:
>
> CC mm/hugetlb.o
> mm/hugetlb.c: In function ‘huge_pte_offset’:
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5361:14: note: declared here
> pud_t *pud, pud_entry;
> ^~~~~~~~~
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5361:14: note: declared here
> cc1: warning: function may return address of local variable [-Wreturn-local-addr]
> mm/hugetlb.c:5360:14: note: declared here
> p4d_t *p4d, p4d_entry;
> ^~~~~~~~~
>
> I'm shutting down for the night and will look into it more tomorrow if
> someone else does not beat me to it.
Non-PAE uses ModeB / PSE paging, which only has 2-level page tables. The
non-existent levels get folded in and pmd_offset/pud_offset() return the
passed in pointer instead of accessing a table, e.g.:
static inline pmd_t * pmd_offset(pud_t * pud, unsigned long address)
{
return (pmd_t *)pud;
}
The bug probably only manifests with PSE paging because it can have huge
pages in the top-level table, i.e. is the only mode that can get a false
positive.
This is arguably a bug in pmd_huge/pud_hug(), seems like they should
unconditionally return false if the relevant level doesn't exist.
next prev parent reply other threads:[~2020-03-31 4:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-28 22:10 + mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch added to -mm tree akpm
2020-03-31 3:35 ` Mike Kravetz
2020-03-31 4:44 ` Sean Christopherson [this message]
2020-03-31 14:08 ` Jason Gunthorpe
2020-03-31 21:58 ` Mike Kravetz
-- strict thread matches above, loose matches on Subject: below --
2020-04-12 7:41 incoming Andrew Morton
2020-04-13 20:51 ` + mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch added to -mm tree Andrew Morton
2020-02-04 1:33 incoming Andrew Morton
2020-02-24 3:29 ` + mm-hugetlb-fix-a-addressing-exception-caused-by-huge_pte_offset.patch added to -mm tree Andrew Morton
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=20200331044408.GW24988@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=akpm@linux-foundation.org \
--cc=jgg@ziepe.ca \
--cc=longpeng2@huawei.com \
--cc=mike.kravetz@oracle.com \
--cc=mm-commits@vger.kernel.org \
--cc=naresh.kamboju@linaro.org \
--cc=stable@vger.kernel.org \
--cc=willy@infradead.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 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.