From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: Kernel related (?) user space crash at ARM11 MPCore
Date: Mon, 21 Sep 2009 23:34:53 +0100 [thread overview]
Message-ID: <4AB7FF8D.6040404@arm.com> (raw)
In-Reply-To: <20090921221229.GF14700@shareable.org>
Jamie Lokier wrote:
> Catalin Marinas wrote:
>> A possible scenario (though more code analysis is needed to be entirely
>> sure) with writing instructions and not calling sys_cacheflush():
>>
>> - application mmap's a file (shared mapping, otherwise the data written
>> to private mappings is lost when unmapping)
>> - app writes some instructions to text pages. We don't get CoW because
>> of the shared mapping but we don't get D-cache cleaning either
>> - app unmap's the page but the kernel keeps the physical page in its
>> page cache. The flush_cache_page() on non-aliasing VIPT doesn't do
>> anything on ARM
>> - app mmap's the page with PROT_READ|PROT_EXEC
>> - app executes from the page generating a prefetch abort. The kernel
>> finds the page in its page cache and maps it into user space, calling
>> update_mmu_cache(). However, the dirty bit isn't set (since the kernel
>> hasn't touched the page) and the lazy D-cache flushing in
>> update_mmu_cache isn't triggered, leaving the I-cache with old entries
>> directly from RAM.
>
> Why isn't the dirty bit set by the last step?
By dirty here I mean the PG_arch_1 bit set by flush_dcache_page() which
won't happen at step 2.
> The dirty bit must be set by the writes in the second step, otherwise
> how does the kernel know not to discard those writes under memory
> pressure?
That's another dirty bit (I think PG_dirty) but it isn't taken into
account by update_mmu_cache(). As I said, more in-depth code analysis
here is needed to be entirely sure.
> Btw, regarding "non-aliasing", it's pretty clear that it does alias
> the I-cache ;-),
We just refer to D-cache aliasing here.
> in much the same way as different addresses alias in
> the D-cache with an "aliasing" cache. That may well be a clue as to
> clean, systematic and sane way of ensuring all the cache ops are in
> all the right places.
We should indeed favour correctness but there may be some corner cases
which aren't used anyway, so we shouldn't penalise normal usage.
--
Catalin
next prev parent reply other threads:[~2009-09-21 22:34 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A7AEEB6.5060903@googlemail.com>
[not found] ` <1250184014.14019.40.camel@pc1117.cambridge.arm.com>
[not found] ` <1250501311.9858.24.camel@pc1117.cambridge.arm.com>
[not found] ` <20090817140422.GA10764@n2100.arm.linux.org.uk>
2009-08-29 12:27 ` Kernel related (?) user space crash at ARM11 MPCore Catalin Marinas
2009-08-31 8:30 ` Catalin Marinas
2009-09-07 15:29 ` Catalin Marinas
2009-09-07 15:56 ` Dirk Behme
2009-09-07 16:43 ` Catalin Marinas
2009-09-07 17:31 ` Mikael Pettersson
2009-09-07 21:40 ` Catalin Marinas
2009-09-03 11:58 ` Dirk Behme
[not found] ` <1250529916.11185.80.camel@pc1117.cambridge.arm.com>
[not found] ` <20090919224022.GA738@n2100.arm.linux.org.uk>
[not found] ` <1253435940.498.15.camel@pc1117.cambridge.arm.com>
2009-09-20 9:31 ` Russell King - ARM Linux
2009-09-20 19:02 ` Russell King - ARM Linux
2009-09-20 22:46 ` Catalin Marinas
2009-09-21 8:31 ` Jamie Lokier
2009-09-21 8:41 ` Russell King - ARM Linux
2009-09-21 9:41 ` Jamie Lokier
2009-09-21 10:08 ` Catalin Marinas
2009-09-21 8:49 ` Catalin Marinas
2009-09-21 8:54 ` Russell King - ARM Linux
2009-09-21 9:44 ` Catalin Marinas
2009-09-21 10:07 ` Russell King - ARM Linux
2009-09-21 10:42 ` Catalin Marinas
2009-09-21 20:10 ` Jamie Lokier
2009-09-21 21:26 ` Russell King - ARM Linux
2009-09-21 22:14 ` Catalin Marinas
2009-09-21 22:25 ` Jamie Lokier
2009-09-22 8:43 ` Catalin Marinas
2009-09-21 21:58 ` Catalin Marinas
2009-09-21 22:12 ` Jamie Lokier
2009-09-21 22:31 ` Russell King - ARM Linux
2009-09-21 22:34 ` Catalin Marinas [this message]
2009-09-21 21:38 ` Russell King - ARM Linux
2009-09-21 22:28 ` Catalin Marinas
2009-09-21 22:37 ` Jamie Lokier
2009-09-21 22:33 ` Jamie Lokier
2009-09-22 9:21 ` Catalin Marinas
2009-09-22 10:19 ` Catalin Marinas
2009-09-22 17:17 ` Catalin Marinas
2009-09-23 6:03 ` Dirk Behme
2009-09-23 9:13 ` Catalin Marinas
2009-09-23 10:38 ` Catalin Marinas
2009-09-23 12:12 ` Mikael Pettersson
2009-09-23 12:42 ` Russell King - ARM Linux
2009-09-23 12:51 ` Catalin Marinas
2009-09-23 12:55 ` Catalin Marinas
2009-10-15 14:57 ` Russell King - ARM Linux
2009-10-15 15:20 ` Catalin Marinas
2009-10-15 15:28 ` Russell King - ARM Linux
2009-10-15 15:56 ` Catalin Marinas
2009-10-20 11:39 ` Catalin Marinas
2009-10-25 13:39 ` Russell King - ARM Linux
2009-10-26 18:40 ` Catalin Marinas
2009-10-25 14:48 ` Russell King - ARM Linux
2009-10-26 18:45 ` Catalin Marinas
2009-10-26 19:17 ` Russell King - ARM Linux
2009-10-15 15:48 ` Dirk Behme
2009-10-15 15:53 ` Catalin Marinas
2009-10-25 13:04 ` Russell King - ARM Linux
2009-10-26 18:18 ` Catalin Marinas
2009-09-20 22:02 ` Catalin Marinas
2009-09-22 5:44 ` Shilimkar, Santosh
2009-09-22 9:01 ` Catalin Marinas
2009-09-22 9:34 ` Shilimkar, Santosh
[not found] ` <1249981883.27150.14.camel@pc1117.cambridge.arm.com>
[not found] ` <4A818CBC.8040000@googlemail.com>
[not found] ` <1250006770.30628.1.camel@pc1117.cambridge.arm.com>
[not found] ` <4A819C54.3080606@googlemail.com>
[not found] ` <1250009043.30628.9.camel@pc1117.cambridge.arm.com>
[not found] ` <87ab25vazg.fsf@brigitte.kvy.fi>
[not found] ` <1250080338.20332.32.camel@pc1117.cambridge.arm.com>
[not found] ` <87k518yc8a.fsf@brigitte.kvy.fi>
2009-09-11 9:21 ` smsc911x.c driver and SMP (was Re: Kernel related (?) user space crash at ARM11 MPCore) Catalin Marinas
2009-09-11 12:55 ` Bill Gatliff
2009-09-11 13:00 ` Catalin Marinas
2009-09-11 15:20 ` Bill Gatliff
2009-09-11 16:06 ` Catalin Marinas
2009-10-06 6:12 ` smsc911x.c driver and SMP Antti P Miettinen
2010-08-31 0:07 ` Shinya Kuribayashi
2010-08-31 6:22 ` Antti P Miettinen
2010-08-31 9:10 ` Shinya Kuribayashi
2010-08-31 8:33 ` Catalin Marinas
2010-08-31 8:42 ` Shinya Kuribayashi
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=4AB7FF8D.6040404@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.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;
as well as URLs for NNTP newsgroup(s).