Linux PARISC architecture development
 help / color / mirror / Atom feed
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


  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