From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 82546210F6D for ; Fri, 10 Jan 2025 16:47:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736527651; cv=none; b=eXaYwBeIDk6MUlGDa6ai11HFHj74PE+deDwDX7o7ZU0oRx3rlVIwud2s0S/5vBTMhToxkvuEkH2CXEhe+0SfiJIx4u74ZR69kOGXUikRZ9W5PD42R/togMS1MmzbMc8wLbLXgWarg9OtU55l2Qd004Z4UcEm/asJNqRJPTonunI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736527651; c=relaxed/simple; bh=TqKeSjWY52OsGjMRrM4Ttop+dgp1W76eJ+87OB1Yhqc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=W6/CffKCQUpH+EJ3c0mFH3ilY5UawXsGOwAJs74ER2vmdQVVOUXzW/iVZnWBWX9OqMHeAcgCrzXyZBm0CQ/rgneuTxpynpAncQK8X6ys97wf4K81iooLb0CG1V2Wn6JSdyw1KBCa0YlfhULcdWv3X2pwEqEnXyGY5yo+eAPYjpM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=lZIkNloi; arc=none smtp.client-ip=209.85.217.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lZIkNloi" Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-4affbc4dc74so1329934137.0 for ; Fri, 10 Jan 2025 08:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1736527648; x=1737132448; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hTUEfSSF2UWusrjtJshsBQ5OAP7BXtPBx1t2zPYekgY=; b=lZIkNloiwKAXZIuIguZYZ6VWUtLO1AE0D4xYjHkO7BrihZ4cKtlEHrTqdXu50Np1Sx WciSQQOY1wMiy3tt17HbbrTNFy0jlzDqBuSJEgK5+Yk+grbpO2k1EotjcxIf0TK8IXFi ZT8Wvlaj5eLFg5WgDwx2V8mhocMOMsFrxXjboZJ0yD0Xd2RENRu6KAHJ1duO63djJ4ah +a3fWTmoRscBGDKbSS0qRPT14SJXzdQN7jXyPU6DLJEu2VZnzXp+obbJTOIVicA+t43K fKOZqfmdncAc3ktkt7VhZKH+Ly3vFvDdNsDhEoV7xZbifF7iCUjxCVn1AHlX071SdmmR 0V/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736527648; x=1737132448; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hTUEfSSF2UWusrjtJshsBQ5OAP7BXtPBx1t2zPYekgY=; b=LHt2pUPg5Je13toBKdjZUeKqzkUuOg7kblfRSHGLKkc7S/aq7u4xHoblKanBzVSVpf tJWzx7Ob+/+z7nQw+wHcBzRvqA0SvVu+T6rnPtznsidiTLYDURKKKsHiCVSWtakWU6fF 3h4TSzEpp4I4t0YsmHdS3k+6ydbzq7IxoQ8DVtnj6qena3mWDCjFNiiaqEx7+K/MUPGb YiZicS3y8LAH2OWa/PXOMW3R/jfe9LBz50wvaRBlw3lVy3zT5DBkl+g5sTsIFCYw+6of CAgJ/as0d30DGSUOG7aFe4neaY8VAauDaBsbPavJSsM8gErRAxLmhXxTAsKIVnr1BjKO KK+Q== X-Forwarded-Encrypted: i=1; AJvYcCV+7UZ/LHJi4znfCell41VsmU/4lNcjzfUUtrhRDkNOH/JuuxdaN5DoGPst9kh4kx7PnvXrO017JZZYqZc=@vger.kernel.org X-Gm-Message-State: AOJu0YyWPf7f1u2Q0DsiWSrdkNdzd3ytGbDqIJ0aWjUTu7orQiCss9n6 F83QG3XfoznY0skujOwDvwGJ3pTBrwU4GrgthQCJC++sQ7Xjf1IKFDYuoeuXlKA= X-Gm-Gg: ASbGncsae+Q15WuwTdPxBKbXKrE0+59kL2PnrEuc6XIyRt6pB+etJweaZUT3/JQX6ie BnmgYcl98RsCcYns1uTV9a37KUlLG6jPFhQ5W1oxfddh9FXGgjhMV8NUv8NCVcmfWO5g3ruPeuZ DHHH5gwN+uwjHeoLugGNi/dFA0ZtXLgvpI3sUHU3i9KBB2T9sKfh9Sxnk6/4GQw85anAyUidUoM QljEnJOjUvCBFx4By73IuJ8YmUivtdTcWXaJca67d+A7yRxiM5MA8ssQ03XLF1PUS1U/2SNryiz U5+98DKoq7gJaSAQm5n44vCYDsPiaI7LBU7Y23iuA0/h0qN9lJUoIsK0k1k= X-Google-Smtp-Source: AGHT+IF38lqbmFBP2Ow9o/lqFz3pMl5G/m/z7DFkuzYWl1BmNbkMkl0ayL1gbdBNFB2Fy9NroKQERw== X-Received: by 2002:a05:6102:f0a:b0:4b1:1eb5:8ee5 with SMTP id ada2fe7eead31-4b3d0eef0d1mr9531372137.25.1736527648336; Fri, 10 Jan 2025 08:47:28 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:f41c:e104:7f6c:f2c3:2134? ([2804:1b3:a7c0:f41c:e104:7f6c:f2c3:2134]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-86231578d20sm2988496241.30.2025.01.10.08.47.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2025 08:47:27 -0800 (PST) Message-ID: <5de4b3c3-7f11-4d81-ac75-1b7381a87f0a@linaro.org> Date: Fri, 10 Jan 2025 13:47:23 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Prevent inconsistent CPU state after sequence of dlclose/dlopen To: Mathieu Desnoyers , libc-alpha Cc: Florian Weimer , "carlos@redhat.com" , Mark Rutland , Peter Zijlstra , linux-kernel , x86@kernel.org, paulmck , Michael Jeanson References: Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 10/01/25 12:55, 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. > > 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 ? Yes please, it would be helpful if you can add some information on what kind of hardware and kernel version this is an issue. Also, could you add some detail of the issue and why kernel itself does not or can not guarantee memory consistent after the mmap call? Is is because this would be an extra non-required overhead on mmap that userland should handle?