From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 3AB4B35677E for ; Wed, 19 Aug 2026 08:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787128535; cv=none; b=nt4z5KS9fWeIoiXFtjFJqtjto58E1WE90pM7+tsYSwaVfmFt+wBQCB3bnSUlwaKe1IdWkpG+QU/3UHVGzaUhMOrLogUBDh6WE5NdZg7pGzEyxhS2sy93IVvfrpo0L/hmNOooxCN0ba396NuIs/8wRZSse1D+FXmBkO4IBfyChdo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787128535; c=relaxed/simple; bh=lpQQmxTDsK3Yh1ylUB1lp+y7xpJ0X5iJF2Sw0jOAwPo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=X1wYaCH39/D1Anui3/U3anDMhzpCr6K/ixJmhmekZ+y+ksXRWBXlKav0dGKRnAthr79NurQjCi5p4SP5qm/Wtzyug2gAyTxqC2uBEfG1I95EcaGAfRtDMiPJ3IjU1T6QzkTE/4yAfOoZVX3ohbuMIdWUFcAe9KpuxLQccG/R67s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org; spf=none smtp.mailfrom=blackwall.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b=VBnRgE9W; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=blackwall.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b="VBnRgE9W" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47f59f25ec4so394479f8f.2 for ; Wed, 19 Aug 2026 01:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall.org; s=google; t=1787128532; x=1787733332; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=UaQjGKx5D7JBs1VdBUikHnCA2EKV7k9U1yTmwx36B/s=; b=VBnRgE9WUwwCS+zYFN2dTfu6cVRVD4voKoaXCzU9sM/9v29vTSJcTryyhIjTeVMqt0 0Uflt0J+28M8GJHhERgCiJqdr1PP7MHu0i+RmwbnDhOLsk20htYq9ipr4PowUmNeMlno ymITCrRPs4DTCixLlNbQBYDrhNGRi+Uj3d8Z/bi+c2tS4Bhn67Yk3PPgDK5a+1EpBgWF LNoCh1pkRK5TWdxS1/k11EQUSLpGiz+4wEhLVqJ6dEvOLV1AzO0pvAay+IvXuwqt5Utz CeBPqXDxby8VLPjnu8erhC4N1VGSdja0Fe/RwfA1VRZUIprL16EU51COivxh5hqBS/Sz yr6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787128532; x=1787733332; h=content-transfer-encoding:content-type:in-reply-to:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=UaQjGKx5D7JBs1VdBUikHnCA2EKV7k9U1yTmwx36B/s=; b=NjwNi0XOftTdbaxCeB/meru+iJrog1i1UDvjs9oo+ma6DLXK/t1v1kRRHcQqA/pcim HZW4mYGxZ52Y1CcTAYIyZkOz3A19zQdAqYuu/ibpBEEFlVLYZEKYL1fvcft3WelkmkGS Wg1PmvfQ8bGn16StSy92sPof9/rhQb/P6JS0xWiqxV9jcMeuvio40jRObNxjFVWx+8Pp DaGU8UNzYhP+SMPeSpu1mWAo4gRz6qDhf0BV9HBAMaedU+dGo80pyKwLyO1gBQtDUgjq 1ab2OXcGpBIAw5DEGZt4BvwN7GyQjok1KBtYpLYHoqg9vxTZXlYt17P0HdPVaX9Qgyan b4XQ== X-Forwarded-Encrypted: i=1; AHgh+Ro3MyvntPhtuod0fXKaJNW5DNT9XJnfCxo17Kmk5S2hlMuzRNMf0cISNPkNMq0zEfREF5zBAEpzJeq8xkc=@vger.kernel.org X-Gm-Message-State: AOJu0Ywod9ewLamfzSEJl+Sy95ed23z4ozblYSXrIuPW+BOtU11iQbHw gIzwngm4krOewPqdHNBhq0QC2kZxtwBh41D8hoj+gRXNP9W19XzZfZHwZ/s8PapLCRs= X-Gm-Gg: AR+sD1055r4/6jbzJbT2ru8Og2XnBR1sPITEyaK85oPD2gBbpkxNe0fFImd71evoUqB Pd68FbQ4H8bMMAFu6dC8WDZjjQ4T+42cK4/6ZbS4npbAWk3uJLk4cIqNuseN/+/5O/Ou3RnmgZT VZ4KHjkISdHY4j4YeyxDVA1M00D6GvF4VBgw6UakT8WvKZapQW3ICLvYR/BRceSxJAYh8wre+gE 6XzH7lE/C8/6C9idKaTlumygIdR+yz6bQY53FqOugi7dbYCGmi8vx328Kxsytiuh0ldYO6O5ZIR TH23CeNX0idrS7hMpi94ko6G9ZyCHjJZZXi42pi9HHHrvEAhVvvMp53SMEwclqTxJY4BU5eEn7T RudIhl7HY2crZkGO9q0alQvYWZRI4c3x79jaQn0ALtqgahRbHTZf5Sy95A+x24pMX3/Sh7VXBty P0VctnIBudUxBcskFf9pXlQxEI7wxTFlH2puS1oZ9X4Q3mnDQamNLha2kDoGGY2JHe4lMjNIo8k I/FiI67hYkwhk+mFAw= X-Received: by 2002:a05:600c:6990:b0:499:900c:9c69 with SMTP id 5b1f17b1804b1-499aa1ba0acmr52580625e9.9.1787128532150; Wed, 19 Aug 2026 01:35:32 -0700 (PDT) Received: from [192.168.0.161] (78-154-15-182.ip.btc-net.bg. [78.154.15.182]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499aa0dd620sm40297395e9.13.2026.08.19.01.35.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Aug 2026 01:35:31 -0700 (PDT) Message-ID: <1ebd9c8a-5b7e-4ebb-9c7d-5b2b2fe4a675@blackwall.org> Date: Wed, 19 Aug 2026 11:35:29 +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: [PATCH net v3 2/2] bonding: fix u32 overflow in compute_gap() Content-Language: en-US, bg To: Hangbin Liu Cc: Jay Vosburgh , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Hangbin Liu References: <20260818-bond_overflow-v3-0-e05d4dbc2fd8@kylinos.cn> <20260818-bond_overflow-v3-2-e05d4dbc2fd8@kylinos.cn> <80d704a8-aca6-44f8-8933-eb0cf14ecf3b@blackwall.org> From: Nikolay Aleksandrov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/08/2026 05:09, Hangbin Liu wrote: > On Wed, Aug 19, 2026 at 10:07:22AM +0800, Hangbin Liu wrote: >>>>> ... this here, as u64_stats_update_begin doesn't provide exclusive access, so writers >>>>> must do that themselves, so you can't be sure what value will end up, the zeroing >>>>> might not work at all and can get overwritten >>>>> >>>> >>>> I meant - it doesn't improve on the current situation where it can also happen. :) >> >> Ah, yes. I forgot this. The reset_unbalanced_load() could be called on any >> CPU, which conflicts with other writers. >> >> I re-checked the code. unbalanced_load is only called in two situations: >> 1. To rebalance the load in bond_alb_monitor(), which only executes once >> every 10 seconds. >> 2. !tx_slave in bond_do_alb_xmit(), which is only for multicast/broadcast >> traffic. This traffic shouldn't be significant. >> >> So looks using spin_lock here is acceptable. What do you think? > > I mean, drop the per-CPU design directly and use spin_lock to protect the data. > > Hangbin hmm why don't you change the way the reset is done? *untested* but in theory you could just record the values at a reset "moment" in reset unbalanced and just use the delta, so it becomes a reader and there is only 1 writer left (tx). Keep the counters only increasing (important), only record a snapshot at a reset moment, count current total bytes (sum all per-cpu data), decrement the previous total from it and use that as the "interval bytes" to div. Cheers, Nik