From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF8A8212B02 for ; Fri, 10 Jan 2025 16:54:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736528060; cv=none; b=QnyU1D8rOP+keTQ20bfPgXDVy85KNig5Ow93oaJqxDijOSW8lY74WJ8PBLTG2cWNK+aK/cBXWY+BR4l4LgQf3m9eK+qR3RkMqUUhvtehDdb2C4EcdA34qdHiYEUuTEzY9a6RzxlXT7tn7/2YbZrNthYprLJLpGtQ6cXzGGGZKNw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736528060; c=relaxed/simple; bh=XZKRTjIkZznGMKENUHYFVE1z13sz2e43GKKPKFY5k5o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X56F/RLaCOyrFIoUPGy5MPFwhZ9Z1R3KeXIgGPwNnhh4DXdAfFfzgSwKwUfRrxrb8m4NVgDhJWpvw8MsNj1Hx2ubQtCYQynTS9V36KGbTGqB2p4ann2nI3b7hX/tUYZXz8Ab8V8SBivYB8CuY4PvPJjPILtytXd486CGgY3QNnc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=Oibpuq2L; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="Oibpuq2L" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sPfUri06gTahyx2G71p3G7Pgbeu6yi7G3lcbA4P2uLo=; b=Oibpuq2LMqEzUYymlX0Pxs0KvM dFygi+8vdKMfrPO8hQYhfBxojQEROZt3Z1MLTD2cuAAR95nINNzlQkIxRs3g0OgU5DJp9CzshFCEx rTLFHV/Q6iYSBW3rzs8W51pe5YnyOhEfeq1pYksItvwq8QQKM2KmPvhSSaDo2q1YnwTC9qOiURdEU 45lR8vIcabcwWIyQqHA8uxptjflphLWlfmRLIjcTHGga8gfLHMYw4Fqwsrt7/P2WCLmmiltY8ME3h 8X8MMFltsshhfXou5lA+k2rXp2jSgRr/5MU6v/jslfJ8ZKD5ScfMHuFnT5Vlp1EBB0bxkhk60npoY RW9chL0w==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tWIGz-0000000E3ml-1ooc; Fri, 10 Jan 2025 16:54:13 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 9877C3005D6; Fri, 10 Jan 2025 17:54:12 +0100 (CET) Date: Fri, 10 Jan 2025 17:54:12 +0100 From: Peter Zijlstra To: Mathieu Desnoyers Cc: libc-alpha , Florian Weimer , "carlos@redhat.com" , Mark Rutland , linux-kernel , x86@kernel.org, paulmck , Michael Jeanson Subject: Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen Message-ID: <20250110165412.GC4213@noisy.programming.kicks-ass.net> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jan 10, 2025 at 10:55:36AM -0500, Mathieu Desnoyers wrote: > Hi, > > I was discussing with Mark Rutland recently, and he pointed out that a > sequence of dlclose/dlopen mapping new code at the same addresses in > multithreaded environments is an issue on ARM, and possibly on Intel/AMD > with the newer TLB broadcast maintenance. What is the exact race? Should not munmap() invalidate the TLBs before it allows overlapping mmap() to complete? Any concurrent access after munmap() / before mmap() completes is UB anyway, no? > I maintain the membarrier(2) system call, which provides a > MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE command for this > purpose. It's been there since Linux 4.16. It can be configured > out (CONFIG_MEMBARRIER=n), but it's enabled by default. > > Calling this after dlclose() in glibc would prevent this issue. > > Is it handled in some other way, or should we open a bugzilla > entry to track this ? The problem is that the membarrier() call has significant cost, and is only really needed if dlopen() is called right after (in the same location). Unconditionally adding that barrier, just in case, might regress things, no?