Hi
I have reconstructed the stack trace on the 3.14 kernel where we caught
the problem.
The call path was __do_fault() -> set_pte_at(). In later kernels it
corresponds to the do_set_pte().
You are right that there are calls to flush_icache_page(). I did not dig
into the code enough to check if p
Lars,
On 12/05/2014 01:32 AM, Lars Persson wrote:
Hi
Our setup includes both a non-DMA block device and a compressing
file-system (UBIFS). A flush_dcache_page() is issued by UBIFS so your
patch fixes another problem that we do not hit.
The stack trace is not available now. Do we need it for an
Hi
Our setup includes both a non-DMA block device and a compressing
file-system (UBIFS). A flush_dcache_page() is issued by UBIFS so your
patch fixes another problem that we do not hit.
The stack trace is not available now. Do we need it for any further
analysis ? I think the mechanism of the rac
(repeat mesg, first one went to wrong place)
Lars,
Do you have a stack trace or so then you found the second VPE between
set_pte_at and update_mmu_cache?
It would be interesting how it happens - generally, to get a consistent
SIGILL in applications due to misbehaviour of memory subsystem, the
Lars,
Do you have a stack trace or so then you found the second VPE between
set_pte_at and update_mmu_cache?
It would be interesting how it happens - generally, to get a consistent
SIGILL in applications due to misbehaviour of memory subsystem, the bug
in FS is not enough.
Hold on - do you u
Ralf
I remember now that we have applied to our tree the proposed patch
titled "MIPS HIGHMEM fixes for cache aliasing and non-DMA I/O".
This patch changes the semantics of flush_dcache_page() by using
page_mapped() instead of mapping_mapped() to decide if the flush should
be lazy. Is it this chan
Lars,
normally set_pte_at() is invoked in a
cache_flush_*()
set_pte_at()
tlb_flush_*()
sequence. So I'm wondering if you're trying to fix something in set_pte_at
that actually ought to be fixed in the cache_flush_*() function.
I'm wondering, have you identified which cache flush functio
It is the flush_dcache_page() that was called from the file-system
reading the page contents into memory.
- Lars
On Wed, 2014-12-03 at 14:42 +0100, Ralf Baechle wrote:
> Lars,
>
> normally set_pte_at() is invoked in a
>
> cache_flush_*()
> set_pte_at()
> tlb_flush_*()
>
> sequence. So
On Wed, Dec 03, 2014 at 10:31:44AM +0100, Lars Persson wrote:
> Hi Leonid
>
> First let me describe the mechanism of this race condition, which was a
> fault in the kernel's MIPS architecture code. Specifically in its
> implementation of lazy dcache flushing. AFAIK, it would only hit on
> systems
Hi Leonid
First let me describe the mechanism of this race condition, which was a
fault in the kernel's MIPS architecture code. Specifically in its
implementation of lazy dcache flushing. AFAIK, it would only hit on
systems where the pagein code path writes to the page from the CPU.
The order of
10 matches
Mail list logo
