Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp683733ybz; Wed, 29 Apr 2020 07:36:29 -0700 (PDT) X-Google-Smtp-Source: APiQypIX0WTDPURrBHkirNUxKHXDTrdbeeaCqs7NZnTZioLNB+jcuWip8Ws99hFczp0fGz96flQO X-Received: by 2002:aa7:d143:: with SMTP id r3mr2589056edo.147.1588170989046; Wed, 29 Apr 2020 07:36:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588170989; cv=none; d=google.com; s=arc-20160816; b=uVgk3cjM/k4fZjE07YXVMXlHx/vVFpZ5DSUCMy8+ARTANcpgxGfndvcym3mhQDwl4N Oxp37jlLi0UlTP4gwx5QG+CHeHjI8qfPyQIOqFaoc3DF4X0F7nVE7IQxYwb7Es9cgtxi 96VIeUKsm1Zks3Ffb9DTfHXpprlYn7ySCWqQydPqOIR1pM+KrLmb1pBjB8aVNBkNBYJ1 XXGGlpf4bTlMWzhMIG2whRcHPz5orumhlD5kTIHb2beJ/eqmBN/xBZ6MHECOebGULvOH u6WF4y8lpnqrj8Gs5l5nrIZ4sAv5/dxhuAe6VdgQVlrxbqbf3VFO1t5e886UAYsy+Wex /qbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Y3gWUCSyJTka+jpPIRnmntc9+jsK9ljoCRrpjBuu91w=; b=s3H9pAr5XDH1Zi8VQOUa7uPPZA8WuwUfSJD6RYix3GnP1Id5AkwxCeidPI1SBq37BY 3drAOwHPdLoUwT7XLmeHwtxdeTM9dRYNS67JnTfO5XpvGDq7saUaolxCYIRCeOMAdkD2 2sNQqJP9gv7BG+0BlQCeHA4Nww2zd/BD+2OpzIsbWR7s25MEI4s+2wLEJODhIcRxnCfi crFR7+e+OdezCyiH9pXphsko92kTbuhUlJpnDTFXnQ5psOLH5X7tOMS2IL23B1nDgB2Q GDnz1zHtzcovhrrZt2SqgLHZohf9GMtYc1+/xbXxJeUJ5SngZao/cB17eGDYozY3ME3l fHRw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l18si3888850ejb.405.2020.04.29.07.36.05; Wed, 29 Apr 2020 07:36:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726775AbgD2OcT (ORCPT + 99 others); Wed, 29 Apr 2020 10:32:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:56672 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726355AbgD2OcT (ORCPT ); Wed, 29 Apr 2020 10:32:19 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EA39221D82; Wed, 29 Apr 2020 14:32:17 +0000 (UTC) Date: Wed, 29 Apr 2020 10:32:16 -0400 From: Steven Rostedt To: Joerg Roedel Cc: LKML , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Borislav Petkov , Andrew Morton , Shile Zhang , Andy Lutomirski , "Rafael J. Wysocki" , Dave Hansen , Tzvetomir Stoyanov , Mathieu Desnoyers Subject: Re: [RFC][PATCH] x86/mm: Sync all vmalloc mappings before text_poke() Message-ID: <20200429103216.34b6f7aa@gandalf.local.home> In-Reply-To: <20200429141004.GR30814@suse.de> References: <20200429054857.66e8e333@oasis.local.home> <20200429105941.GQ30814@suse.de> <20200429082854.6e1796b5@oasis.local.home> <20200429100731.201312a9@gandalf.local.home> <20200429141004.GR30814@suse.de> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Apr 2020 16:10:04 +0200 Joerg Roedel wrote: > On Wed, Apr 29, 2020 at 10:07:31AM -0400, Steven Rostedt wrote: > > Talking with Mathieu about this on IRC, he pointed out that my code does > > have a vzalloc() that is called: > > > > in trace_pid_write() > > > > pid_list->pids = vzalloc((pid_list->pid_max + 7) >> 3); > > > > This is done when -P1,2 is on the trace-cmd command line. > > Yeah, I was guessing something like this, init_mm has a mapping which > poking_mm has not. I currently try to reproduce this on one of my > machines. Note, in use_temporary_mm(poking_mm), poking_mm only contains the page that needs to be updated. But will get added to per_cpu(cpu_tlbstate.loaded_mm), which appears to be the one that's not updated. -- Steve