From: Al Viro <viro@zeniv.linux.org.uk>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Xiaoming Ni <nixiaoming@huawei.com>,
Chen Huang <chenhuang5@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>,
Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-mm <linux-mm@kvack.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] arm64: an infinite loop in generic_perform_write()
Date: Wed, 23 Jun 2021 13:04:31 +0000 [thread overview]
Message-ID: <YNMxX0Do9GSNiXSH@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <20210623093220.GA3718@arm.com>
On Wed, Jun 23, 2021 at 10:32:21AM +0100, Catalin Marinas wrote:
> On arm64, neither memcpy() nor raw_copy_from_user() are expected to work
> on Device mappings, we have memcpy_fromio() for this but only for
> ioremap(). There's no (easy) way to distinguish in the write() syscall
> how the source buffer is mapped. generic_perform_write() does an
> iov_iter_fault_in_readable() check but that's not sufficient and it also
> breaks the cases where you can get intra-page faults (arm64 MTE or SPARC
> ADI). I think in the general case it's racy anyway (another thread doing
> an mprotect(PROT_NONE) after the readable check passed).
>
> So I think generic_perform_write() returning -EFAULT if copied == 0
> would make sense (well, unless it breaks other cases I'm not aware of).
It does break the cases of source page eviction under memory pressure.
That aside, why the hell is that memory allowed to be mmaped?
next prev parent reply other threads:[~2021-06-23 13:04 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-23 2:39 Chen Huang
2021-06-23 2:50 ` Al Viro
2021-06-23 3:24 ` Xiaoming Ni
2021-06-23 4:27 ` Al Viro
2021-06-23 9:32 ` Catalin Marinas
2021-06-23 11:51 ` Matthew Wilcox
2021-06-23 13:04 ` Al Viro [this message]
2021-06-23 13:22 ` Mark Rutland
2021-06-24 3:10 ` Chen Huang
2021-06-24 3:24 ` Matthew Wilcox
2021-06-24 3:52 ` Chen Huang
2021-06-24 7:04 ` Christoph Hellwig
2021-06-24 11:15 ` Matthew Wilcox
2021-06-24 13:22 ` Robin Murphy
2021-06-24 16:27 ` Al Viro
2021-06-24 16:38 ` Robin Murphy
2021-06-24 16:39 ` Al Viro
2021-06-24 17:24 ` Robin Murphy
2021-06-24 18:55 ` Catalin Marinas
2021-06-24 20:36 ` Robin Murphy
2021-06-25 10:39 ` Catalin Marinas
2021-06-28 16:22 ` Robin Murphy
2021-06-29 8:30 ` Catalin Marinas
2021-06-29 10:01 ` Robin Murphy
2021-07-06 17:50 ` Catalin Marinas
2021-07-06 19:15 ` Robin Murphy
2021-07-07 9:55 ` David Laight
2021-07-07 11:04 ` Robin Murphy
2021-07-07 12:50 ` Catalin Marinas
2021-06-24 15:09 ` Catalin Marinas
2021-06-24 16:17 ` Al Viro
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=YNMxX0Do9GSNiXSH@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=chenhuang5@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nixiaoming@huawei.com \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox