[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1046860820.2872.1435237125474.JavaMail.zimbra@efficios.com>
Date: Thu, 25 Jun 2015 12:58:45 +0000 (UTC)
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [RFC PATCH] Fix: x86 unaligned __memcpy to/from virtual memory
----- On Jun 24, 2015, at 8:37 PM, Linus Torvalds torvalds@...ux-foundation.org wrote:
> On Wed, Jun 24, 2015 at 4:54 PM, Mathieu Desnoyers
> <mathieu.desnoyers@...icios.com> wrote:
>>
>> OK, see below. This time the fault occurred at an unaligned address.
>> It fails on the !pte_present(*pte_ref) check.
>
> So every time, %rcx is 0x001fb.
>
> Once, your rdx value (which is remaining bytes after the movsq) was 3,
> the other two times it's 0.
>
> What's so magical about that 4056-byte copy (+3 bytes once)? Are you
> *sure* that copy is valid?
*grumble* after another round of inspection, it appears that the cause
is a missing lock in lttng-modules metadata handling. The race never
triggered any safety net until I tried to move to vmalloc.
The updater was just pulling the carpet from under the feet of the
reader when doing the reallocation.
The fact that the OOPS disappeared with different CPU configurations
and when calling vmalloc_sync_all() after vmalloc() was just due to
timing. Sorry for the noise!
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists