Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3998459ybz; Mon, 4 May 2020 13:46:27 -0700 (PDT) X-Google-Smtp-Source: APiQypIdtlmODy00gs1GKd+UY0mkbDP+H992h+vjn1IN2zX6tuMjURAKwmnsNFWI7bgHP4BSRqEX X-Received: by 2002:a50:fc06:: with SMTP id i6mr15558910edr.110.1588625187706; Mon, 04 May 2020 13:46:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588625187; cv=none; d=google.com; s=arc-20160816; b=AbMfbuMLOkv6o5Tvj7Okv1Nva0u8cXx5VE50QCF5uSURB5fUmKZvMcmewcI+DOZMes u/7tkzh+FzKRPr/8XS4jbRowHM1HSN90Bgk/dzbwuLBH/4Ler1tfrF4kjeu9yG43vNVS EDWlB1NVYUAUF2VXy/RWxHX8j1T2wVqFuJuQRFGrNdhdvS7qsKaCzeSSyVuO59Ktjmd1 gVyYWJc2LXQhd38zckVTvhx4ZGETHntPimJyqnjhAt1L8hTLoHrx9E+408zsX1amipxH ARITvFxX1JLfZPMfaWtBvmy9viDtQOGU23wuVZkRwZar2LwXAzbv2KXHjpsDyNv3mJxe L3GQ== 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=D6QZOqa4xU81ms+YgapRYLtYd0WmpCwZ2nS64EFV4c4=; b=IjeGs7P+qR9GZ4LidkE0mIJzCp996zws3E39D6d2jhDSydA3QBVmGeDwzMgui1o5+M 03rrResQV6Oa1XJFYvKG0OWqhIF8MBcOiXMASGmH2FLJI3X1N/iQU65NStUCvHnKOnrz CoCryekwJPbzoDX1sOc66qwTB9BwCmz96+GYYqUubaYjWFNqTq4SwGUOk4M6st79eL7W ujhWUxryX5ST9ewR+UlypqscGPxzSqvRm6SXBId+nIzX8EAkDfa5SpNZ/w0uttymsu+G n8ZdK98g8J3haHs/4ktA31VxiYpfytmgk81NVHTf82rvh4jumxMUJVT+NCAjZHt36ho0 zqyg== 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 e15si7929284ejq.285.2020.05.04.13.46.03; Mon, 04 May 2020 13:46:27 -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 S1726476AbgEDUn7 (ORCPT + 99 others); Mon, 4 May 2020 16:43:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:51156 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726334AbgEDUn6 (ORCPT ); Mon, 4 May 2020 16:43:58 -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 32E80206A5; Mon, 4 May 2020 20:43:57 +0000 (UTC) Date: Mon, 4 May 2020 16:43:55 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Joerg Roedel , Mathieu Desnoyers , linux-kernel , Ingo Molnar , Thomas Gleixner , Borislav Petkov , Andrew Morton , Shile Zhang , Andy Lutomirski , "Rafael J. Wysocki" , Dave Hansen , Tzvetomir Stoyanov Subject: Re: [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and free_percpu() Message-ID: <20200504164355.7551de82@gandalf.local.home> In-Reply-To: <20200504202540.GD5298@hirez.programming.kicks-ass.net> References: <20200429105941.GQ30814@suse.de> <20200429082854.6e1796b5@oasis.local.home> <20200429100731.201312a9@gandalf.local.home> <20200430141120.GA8135@suse.de> <20200430121136.6d7aeb22@gandalf.local.home> <20200430191434.GC8135@suse.de> <20200430211308.74a994dc@oasis.local.home> <1902703609.78863.1588300015661.JavaMail.zimbra@efficios.com> <20200430223919.50861011@gandalf.local.home> <20200504151236.GI8135@suse.de> <20200504202540.GD5298@hirez.programming.kicks-ass.net> 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 Mon, 4 May 2020 22:25:40 +0200 Peter Zijlstra wrote: > I'm only following this with half an eye atm, but one solution is to > pull the vmalloc fault out of the trace path entirely. > > With the current code that is 'interesting', but with the pile of > patches Thomas is sitting on that would be quite feasible. As I assume that's not something that would be backported to the stable kernels, I'm still going to add the workaround. But getting rid of vmalloc_sync_mappings() altogether is still a good idea IMO. -- Steve