From: Guenter Roeck <linux@roeck-us.net>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>,
Naresh Kamboju <naresh.kamboju@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, patches@lists.linux.dev,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
shuah@kernel.org, patches@kernelci.org,
lkft-triage@lists.linaro.org, pavel@denx.de,
jonathanh@nvidia.com, f.fainelli@gmail.com,
sudipm.mukherjee@gmail.com, srw@sladewatkins.net, rwarsow@gmx.de,
conor@kernel.org, linux-parisc <linux-parisc@vger.kernel.org>,
sparclinux@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>,
Helge Deller <deller@gmx.de>, Jason Wang <wangborong@cdjrlc.com>
Subject: Re: [PATCH 6.4 00/28] 6.4.1-rc1 review
Date: Fri, 30 Jun 2023 19:49:40 -0700 [thread overview]
Message-ID: <e4dd115b-1a41-4859-bbeb-b3a6a75bf664@roeck-us.net> (raw)
In-Reply-To: <CAHk-=whh_aUHYF6LCV36K9NYHR4ofEZ0gwcg0RY5hj=B7AT4YQ@mail.gmail.com>
On Fri, Jun 30, 2023 at 06:24:49PM -0700, Linus Torvalds wrote:
> On Fri, 30 Jun 2023 at 15:51, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > There is one more, unfortunately.
> >
> > Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... failed
>
> Heh. I didn't even realize that anybody would ever do
> lock_mm_and_find_vma() code on a nommu platform.
>
> With nommu, handle_mm_fault() will just BUG(), so it's kind of
> pointless to do any of this at all, and I didn't expect anybody to
> have this page faulting path that just causes that BUG() for any
> faults.
>
> But it turns out xtensa has a notion of protection faults even for
> NOMMU configs:
>
> config PFAULT
> bool "Handle protection faults" if EXPERT && !MMU
> default y
> help
> Handle protection faults. MMU configurations must enable it.
> noMMU configurations may disable it if used memory map never
> generates protection faults or faults are always fatal.
>
> If unsure, say Y.
>
> which is why it violated my expectations so badly.
>
> I'm not sure if that protection fault handling really ever gets quite
> this far (it certainly should *not* make it to the BUG() in
> handle_mm_fault()), but I think the attached patch is likely the right
> thing to do.
>
> Can you check if it fixes that xtensa case? It looks
> ObviouslyCorrect(tm) to me, but considering that I clearly missed this
> case existing AT ALL, it might be best to double-check.
>
> Linus
Yes, the patch below fixes the problem.
Building xtensa:de212:kc705-nommu:nommu_kc705_defconfig ... running ......... passed
Thanks,
Guenter
> include/linux/mm.h | 5 +++--
> mm/nommu.c | 11 +++++++++++
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 39aa409e84d5..4f2c33c273eb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2323,6 +2323,9 @@ void pagecache_isize_extended(struct inode *inode, loff_t from, loff_t to);
> void truncate_pagecache_range(struct inode *inode, loff_t offset, loff_t end);
> int generic_error_remove_page(struct address_space *mapping, struct page *page);
>
> +struct vm_area_struct *lock_mm_and_find_vma(struct mm_struct *mm,
> + unsigned long address, struct pt_regs *regs);
> +
> #ifdef CONFIG_MMU
> extern vm_fault_t handle_mm_fault(struct vm_area_struct *vma,
> unsigned long address, unsigned int flags,
> @@ -2334,8 +2337,6 @@ void unmap_mapping_pages(struct address_space *mapping,
> pgoff_t start, pgoff_t nr, bool even_cows);
> void unmap_mapping_range(struct address_space *mapping,
> loff_t const holebegin, loff_t const holelen, int even_cows);
> -struct vm_area_struct *lock_mm_and_find_vma(struct mm_struct *mm,
> - unsigned long address, struct pt_regs *regs);
> #else
> static inline vm_fault_t handle_mm_fault(struct vm_area_struct *vma,
> unsigned long address, unsigned int flags,
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 37d0b03143f1..fdc392735ec6 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -630,6 +630,17 @@ struct vm_area_struct *find_vma(struct mm_struct *mm, unsigned long addr)
> }
> EXPORT_SYMBOL(find_vma);
>
> +/*
> + * At least xtensa ends up having protection faults even with no
> + * MMU.. No stack expansion, at least.
> + */
> +struct vm_area_struct *lock_mm_and_find_vma(struct mm_struct *mm,
> + unsigned long addr, struct pt_regs *regs)
> +{
> + mmap_read_lock(mm);
> + return vma_lookup(mm, addr);
> +}
> +
> /*
> * expand a stack to a given address
> * - not supported under NOMMU conditions
next prev parent reply other threads:[~2023-07-01 3:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230629184151.888604958@linuxfoundation.org>
2023-06-30 5:30 ` [PATCH 6.4 00/28] 6.4.1-rc1 review Naresh Kamboju
2023-06-30 5:52 ` Greg Kroah-Hartman
2023-06-30 6:16 ` Linus Torvalds
2023-06-30 6:29 ` Greg Kroah-Hartman
2023-06-30 6:56 ` Helge Deller
2023-07-02 21:33 ` [PATCH 6.4 00/28] 6.4.1-rc1 review - hppa argument list too long Helge Deller
2023-07-02 22:45 ` Linus Torvalds
2023-07-02 23:30 ` Linus Torvalds
2023-07-03 3:23 ` Guenter Roeck
2023-07-03 4:22 ` Linus Torvalds
2023-07-03 4:46 ` Guenter Roeck
2023-07-03 4:49 ` Linus Torvalds
2023-07-03 5:33 ` Guenter Roeck
2023-07-03 6:20 ` Linus Torvalds
2023-07-03 7:08 ` Helge Deller
2023-07-03 16:49 ` Linus Torvalds
2023-07-03 17:19 ` Guenter Roeck
2023-07-03 17:30 ` Linus Torvalds
2023-07-03 19:24 ` Helge Deller
2023-07-03 19:31 ` Sam James
2023-07-03 19:36 ` Sam James
2023-07-03 12:59 ` Guenter Roeck
2023-07-03 13:06 ` Guenter Roeck
2023-06-30 6:29 ` [PATCH 6.4 00/28] 6.4.1-rc1 review Guenter Roeck
2023-06-30 6:33 ` Guenter Roeck
2023-06-30 6:33 ` Linus Torvalds
2023-06-30 6:47 ` Linus Torvalds
2023-06-30 22:51 ` Guenter Roeck
2023-07-01 1:24 ` Linus Torvalds
2023-07-01 2:49 ` Guenter Roeck [this message]
2023-07-01 4:22 ` Linus Torvalds
2023-07-01 9:57 ` Greg Kroah-Hartman
2023-07-01 10:32 ` Max Filippov
2023-07-01 15:01 ` Linus Torvalds
2023-06-30 6:51 ` Greg Kroah-Hartman
2023-06-30 6:28 ` Greg Kroah-Hartman
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=e4dd115b-1a41-4859-bbeb-b3a6a75bf664@roeck-us.net \
--to=linux@roeck-us.net \
--cc=akpm@linux-foundation.org \
--cc=chris@zankel.net \
--cc=conor@kernel.org \
--cc=deller@gmx.de \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jcmvbkbc@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=lkft-triage@lists.linaro.org \
--cc=naresh.kamboju@linaro.org \
--cc=patches@kernelci.org \
--cc=patches@lists.linux.dev \
--cc=pavel@denx.de \
--cc=rwarsow@gmx.de \
--cc=sfr@canb.auug.org.au \
--cc=shuah@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=srw@sladewatkins.net \
--cc=stable@vger.kernel.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=wangborong@cdjrlc.com \
/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