From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751927AbbFYM7E (ORCPT ); Thu, 25 Jun 2015 08:59:04 -0400 Received: from mail.efficios.com ([78.47.125.74]:41989 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751197AbbFYM6z (ORCPT ); Thu, 25 Jun 2015 08:58:55 -0400 Date: Thu, 25 Jun 2015 12:58:45 +0000 (UTC) From: Mathieu Desnoyers To: Linus Torvalds Cc: Thomas Gleixner , Linux Kernel Mailing List , Ingo Molnar , "H. Peter Anvin" , the arch/x86 maintainers Message-ID: <1046860820.2872.1435237125474.JavaMail.zimbra@efficios.com> In-Reply-To: References: <1435162498-23082-1-git-send-email-mathieu.desnoyers@efficios.com> <609198255.2568.1435171747039.JavaMail.zimbra@efficios.com> <1022548323.2631.1435190096462.JavaMail.zimbra@efficios.com> Subject: Re: [RFC PATCH] Fix: x86 unaligned __memcpy to/from virtual memory MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - FF38 (Linux)/8.6.0_GA_1153) Thread-Topic: x86 unaligned __memcpy to/from virtual memory Thread-Index: /FDie0c5w7UQcZaeKUM+Gz/+H1ieFA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 24, 2015, at 8:37 PM, Linus Torvalds torvalds@linux-foundation.org wrote: > On Wed, Jun 24, 2015 at 4:54 PM, Mathieu Desnoyers > 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