From nobody Sun Jul 26 01:45:54 2026 Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (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 126AD39DBF9 for ; Fri, 10 Jul 2026 08:04:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.180 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783670687; cv=none; b=Ou//MRml6HSH4c3pQSQkUQPdm69+kBzXHaJe1q+g3tJpgJZhbXcAIVlvtiVtZn/aiWZoL3x91dZOVPt+j0mwCrHhx7gdNrEF9hMhVOUYiXza9E2mjh/BOfH465Cyt4NDhj8mZjTWo5Ji+gBmp9oWV7CJoEDrAMr8H40cUdo6ubk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783670687; c=relaxed/simple; bh=flL7Lt8eOkKSgqCPGWbVgu0HzgtJg8jxPEE3W96qhtU=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=MBXGuEQgPO/Xn/lTYeB310BCprjAcY13CP88KQYIeJFR+CIZjGeZqK4YN9+baq5VSedkB1PtkfiwQ4Is9JnIWZVs8Yv6aTRrb7Ow+5xU3WDLPxk79FG/dGx7A4Rerd87zyA9M92T5pUoHj+aMhE2zVNCVhlzHTDKjk69zfscmGE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=arK4KBbW; arc=none smtp.client-ip=209.85.215.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="arK4KBbW" Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-ca766c1c9ccso343790a12.0 for ; Fri, 10 Jul 2026 01:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783670684; x=1784275484; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=tYHM40PtpGrqm6t0oV3DCZQk7Np30T5qdTryDGzCvBQ=; b=arK4KBbWQtEuGRo/LGS7bFW93egrdRRErQghAUjfraBHXc77WyK96c4zESZa/XF/bu 118TpQTgGSerHJ/MyQAqtjGa81y0nV09ympk31r+O7fechAsbJnGWPIw5XtPnnl0zZMW +fTuA+zeeda0XmyXYALpsqIgp7IBnJ8xIQtuIBGOpKk80ZdFzGHeBgqql3v01+KbNinl 5lGkiIkA8CWZM5lIlyVx/7HTjPL6PyJ73bf6bevCI+TB+pg3tFSaCLD+CWYeC/F9eWlS s9SdRWP2x8FEPte2Ka1+ioIsSR97PCQdXtDDc98uJ3FGVKkLjj2FZh18SYKo0BfltZBk uGBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783670684; x=1784275484; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tYHM40PtpGrqm6t0oV3DCZQk7Np30T5qdTryDGzCvBQ=; b=COUm3A1CtR07/BB1x07rpqam05Rum9iiw/2oZKQzB1HiEcsdia3D5TL1P7i6sY+wqZ 8gQyEuPFZwTmD/XBDVGMzLfe/6HyC22GHR+nc3f2QJQ3Hv67LoYX7qQxkrTjNFxQ09n1 Tp90BnPW9EM59c75ITwY3ixd9JKH5LCVd1xo4nrEMOkJJ/QTB6eX1mNJxjC+sAn7mKXQ 5mS0TMHBZnsiqOFSbm5fkEdHzRXH6yGpMb511DMHDE5N6BZVP71XZvlYw88qxXOSpdPP US6mHNqqWgzVRCp3Hzt1was7HSyJUfk9IQ4tIUv1umBcAc2TZlsEQB/23c2vWX3Lcs8P Sr9Q== X-Forwarded-Encrypted: i=1; AHgh+Rp/WX7RyH69NakUQ8J5Tgrk+sqLAFs9CC9L0wvNAJweyanRb6bR1mEeRSr72u2DD5GXw/qbewIo9VWPmyg=@vger.kernel.org X-Gm-Message-State: AOJu0YzO31eyB4tLYMg0nkKThioU7fYIHPZEL9EWPBVYGgxOSyE1Ho9p INU8CjS5kaOIKWN0Eddn5lLeh2I82pFXSNhI/eFhChR+BoFrtx5VR1ge X-Gm-Gg: AfdE7clXt5xSLg4LTFygkOknpRsJghQpM4ygLX14N1WG05BItaekM+saWCV1A1Zfh6F MyKc3QKxIVUQ4ffw0KH6MmIrFCfD/w4VOTWt3tJ6KNLeIrt2ZS2Oy4fpEk20xnZEhGnWnQgaFx5 N/zzlp+DISHgSKNyYqYTrfn2edr+0/vHP7FGzwEcpkVmOW7HMXiujh0nARU3urkJCR5T2nMCIWd 3xY/fO/2vd+6i/vgAs5W7eB/XbYgEnlHV30jO5wEGN88yKTUhcCN7+Yljb3Aogs/2/FSc/aMpro Lb1QbWS4r+z8ClnCaibLcEKmE7ObdlMzfwYoGFEW9desM2UsZf3J5ao7iQ52CrspcgTrYz+WpW4 EmUVBo4MHVzrHEgEJKs0i3EJIcq1AZfrpE2Ca636NoWZsFukn0RC8OD/v5ya2C1n36ns5q4g7Hi MG+MpbiVK4NI5h+S7i0m4E5UBHbTXiV3pCwizT0aoToTedoOAF6I460SgMHinBLPvViQp7nOli5 kMUOENOaTnbbF9ogsbTZA3h7NvKPGDV/BCKJ/NUZyg= X-Received: by 2002:a05:6a20:729d:b0:3bf:a624:deb8 with SMTP id adf61e73a8af0-3c0bcebc735mr13331342637.21.1783670683874; Fri, 10 Jul 2026 01:04:43 -0700 (PDT) Received: from bass-virtual-machine.. ([142.249.36.48]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13b659d8da9sm66965095c88.14.2026.07.10.01.04.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 01:04:43 -0700 (PDT) From: Gui-Dong Han To: Kees Cook Cc: Tony Luck , "Guilherme G . Piccoli" , WeiXiong Liao , Colin Ian King , linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, Gui-Dong Han Subject: [PATCH] pstore/zone: Order buffer contents before publishing datalen Date: Fri, 10 Jul 2026 16:04:30 +0800 Message-Id: <20260710080430.2529062-1-hanguidong02@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" buffer->datalen tells readers how many bytes in buffer->data are valid. psz_zone_write() copies data first and then updates datalen. atomic_set() and atomic_read() make datalen itself atomic, but do not order accesses to buffer->data. A reader may therefore see the new length before it sees the copied data. Use release ordering when publishing a non-zero datalen and acquire ordering when reading it through buffer_datalen(). This pair ensures that a reader which sees the new length also sees the data written before it. The full-buffer update in psz_record_write() publishes data in the same way and therefore also needs release ordering. The remaining datalen stores only clear or initialize buffers. Direct relaxed loads either inspect writer state or buffers that are no longer changing. start only tracks the write position and on_panic only selects the write path; neither publishes buffer data, so leave them unchanged. Fixes: d26c3321fe18 ("pstore/zone: Introduce common layer to manage storage= zones") Fixes: 0dc068265a1c ("pstore/zone,blk: Add support for pmsg frontend") Signed-off-by: Gui-Dong Han --- Found by auditing atomic operations used for synchronization. A similar fix can be found in 6df8e84aa6b5. --- fs/pstore/zone.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c index a3b003f9a3a0..a4fe9d9ea965 100644 --- a/fs/pstore/zone.c +++ b/fs/pstore/zone.c @@ -159,7 +159,7 @@ enum psz_flush_mode { =20 static inline int buffer_datalen(struct pstore_zone *zone) { - return atomic_read(&zone->buffer->datalen); + return atomic_read_acquire(&zone->buffer->datalen); } =20 static inline int buffer_start(struct pstore_zone *zone) @@ -211,7 +211,7 @@ static int psz_zone_write(struct pstore_zone *zone, wlen =3D min_t(size_t, len, zone->buffer_size - off); if (buf && wlen) { memcpy(zone->buffer->data + off, buf, wlen); - atomic_set(&zone->buffer->datalen, wlen + off); + atomic_set_release(&zone->buffer->datalen, wlen + off); } =20 /* avoid damaging old records */ @@ -863,7 +863,7 @@ static int notrace psz_record_write(struct pstore_zone = *zone, * is greater than buffer size. */ if (is_full_data) { - atomic_set(&zone->buffer->datalen, zone->buffer_size); + atomic_set_release(&zone->buffer->datalen, zone->buffer_size); psz_zone_write(zone, FLUSH_META, NULL, 0, 0); } return 0; --=20 2.34.1