From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 26FE4218AA8 for ; Thu, 9 Jan 2025 13:59:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736431176; cv=none; b=WfevsuLELEm4qUvIjKe1U18fLQsdLQukE3IuMcAV12E7Hk2a52YIMOL+vFrBFApSIwRvJNdFwUpRZBEGxqHMPAZoyEpJIlQBf/WZOveH3G3pb16o8xsxZtJ73tuANZu2SpgEaOn0H28+RPqpkky3T5YA9qR7ug0cXXE1MBA/pEE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736431176; c=relaxed/simple; bh=yqhB4jE7ih/qPV9eJ2r1XSJMHt7BqsvEpQ7Hxz6oO3k=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=LKxHBi+zQyG+PcoiZ/6lTzoh0A4ovDU18jxmJckofBAMNg5zEDnBX29CfmqWR+VIHXdInA/DxN1rW/J0YuM9Zwr10MOhX/ynzS6uB5w3b9qNi+lapfBQQl4YwU7Hqse53q7W37jd7tRglBR1WeSjdcp8Pez5IvF7+R/0jo195X8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=UszsU1MY; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="UszsU1MY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736431174; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=75CEj2ilYB4y1RMkVNNtYq9+NN/qHvo+cUZ8jr1W3Zo=; b=UszsU1MYeqWXyhqFQMch3VEi/PsQRYffJ6h3wyuhgmMqsmMGOJd7joEUsYV08byfRqMttR gtPWdoziQW9913t9h4xSLI2JaUfBMRkmthkcG3RfkvbW2H33PadhsnoMnbIHI4op9/5V9v dI50c6t5jJ+l+G2GPsn3jnTd2XHzYoY= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-38-oR6XZqtEN92MZVvD7dm7Kw-1; Thu, 09 Jan 2025 08:59:32 -0500 X-MC-Unique: oR6XZqtEN92MZVvD7dm7Kw-1 X-Mimecast-MFC-AGG-ID: oR6XZqtEN92MZVvD7dm7Kw Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6d8f0b1023bso10882336d6.0 for ; Thu, 09 Jan 2025 05:59:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736431172; x=1737035972; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=75CEj2ilYB4y1RMkVNNtYq9+NN/qHvo+cUZ8jr1W3Zo=; b=o/nI87zBdmCKrmCF7E/lNLxufttrOoOh6un+cmcvsNh2O6074rjyUzjG+6kfOzZkCa cQyaZBVZPriBqClkVEgBOBsQe9UHGJCwpk4+xC2A9zS+/VKEInVwaUdCQFv3NetMFfcm FcrbRP58AA7N/J+vaCCp60eoiaheBI/PvtyVdymYuEUSNHzVBZvvmXr8YUsYzSAfzHF4 1LwlePhY0uMItOscjs2THcFyw1Q7pZpm/3tNTaPRNur0zf9vRLpSs/u8ZD79D3uT6wcb DP9THCrf1XXW1bjtTVxju5wvs0TeB1rQNVR8QVnpWFR69r20WIe+s23y53ROuqb+9i9j ZmAg== X-Forwarded-Encrypted: i=1; AJvYcCWce1/B4xuKVntgjVfFra88Ufbv/w6Fe953wwXazBxQbnTKrkOMsKorRZa/J4hZoZez5/rZpOTmztWK/c4=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4IDlaRllKxRW5Zvz1U4nUqqfIeOWTD65+jKcOTR40TqjmLKOE exmMm8mi+vpUlcqlLUHX0v3jhdvwejKh4sqNbuABzdNp2z7CIHwKCuiOo8MtBT1m0UWwdca2jE6 C6aSLkQu6B6Ql/8+aieXb6zR2KSy94a6YtRLxYqjhqr+mz/BodnAC6R6nVb9HLw== X-Gm-Gg: ASbGncs0NC8zePsvGT1RUob0YADNuagboSzDpXOIdZzisabva4Xd3oSVj1v6JPOQ8DY WOctD+RwM4uCq1HYreefIDPoT4ZB9vxHn9FOIkKyjM/B7Ov8H7iGTA2r36buH+IzQWuSbugTHuS AfwAPSSVffYQJUeAxpsMZ2PQ8cn7orcgi/7L8sq/xRcwgApDHctqe2SHCH/qOtD8llngeiH3RfS Cc4Qdal+pNi/ZjU3fiMs14eGQjL/2xn2rZSO8RuSvaZEDE55/hI8D3GUVE2dpt0X4c8p+FoYIqc QkyDjExpiPCVWO+7yVXlas7o X-Received: by 2002:a05:6214:20e3:b0:6d8:a32e:8426 with SMTP id 6a1803df08f44-6df9b1d237fmr95290286d6.3.1736431172415; Thu, 09 Jan 2025 05:59:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IGVw/bf+1TY6+NMjzPQ1gj26xKeKuh1Obm5BG5cSto/8IHVhIqXTqCX2Z3eambFa76Ru8Kk6A== X-Received: by 2002:a05:6214:20e3:b0:6d8:a32e:8426 with SMTP id 6a1803df08f44-6df9b1d237fmr95289926d6.3.1736431171996; Thu, 09 Jan 2025 05:59:31 -0800 (PST) Received: from ?IPV6:2601:188:ca00:a00:f844:fad5:7984:7bd7? ([2601:188:ca00:a00:f844:fad5:7984:7bd7]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd18137218sm199427926d6.57.2025.01.09.05.59.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jan 2025 05:59:31 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <974db75a-4ffd-4379-8085-484c45702fe5@redhat.com> Date: Thu, 9 Jan 2025 08:59:29 -0500 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 bpf-next v1 00/22] Resilient Queued Spin Lock To: Kumar Kartikeya Dwivedi , Peter Zijlstra Cc: Linus Torvalds , Will Deacon , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, Waiman Long , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Martin KaFai Lau , Eduard Zingerman , "Paul E. McKenney" , Tejun Heo , Barret Rhoden , Josh Don , Dohyun Kim , kernel-team@meta.com References: <20250107140004.2732830-1-memxor@gmail.com> <20250108091827.GF23315@noisy.programming.kicks-ass.net> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/8/25 3:12 PM, Kumar Kartikeya Dwivedi wrote: > On Wed, 8 Jan 2025 at 14:48, Peter Zijlstra wrote: >> On Tue, Jan 07, 2025 at 03:54:36PM -0800, Linus Torvalds wrote: >>> On Tue, 7 Jan 2025 at 06:00, Kumar Kartikeya Dwivedi wrote: >>>> This patch set introduces Resilient Queued Spin Lock (or rqspinlock with >>>> res_spin_lock() and res_spin_unlock() APIs). >>> So when I see people doing new locking mechanisms, I invariably go "Oh no!". >>> >>> But this series seems reasonable to me. I see that PeterZ had a couple >>> of minor comments (well, the arm64 one is more fundamental), which >>> hopefully means that it seems reasonable to him too. Peter? >> I've not had time to fully read the whole thing yet, I only did a quick >> once over. I'll try and get around to doing a proper reading eventually, >> but I'm chasing a regression atm, and then I need to go review a ton of >> code Andrew merged over the xmas/newyears holiday :/ >> >> One potential issue is that qspinlock isn't suitable for all >> architectures -- and I've yet to figure out widely BPF is planning on >> using this. > For architectures where qspinlock is not available, I think we can > have a fallback to a test and set lock with timeout and deadlock > checks, like patch 12. > We plan on using this in BPF core and BPF maps, so the usage will be > pervasive, and we have atleast one architecture in CI (s390) which > doesn't have ARCH_USER_QUEUED_SPINLOCK selected, so we should have > coverage for both cases. For now the fallback is missing, but I will > add one in v2. Event though ARCH_USE_QUEUED_SPINLOCK isn't set for s390, it is actually using its own variant of qspinlock which encodes in the lock word additional information needed by the architecture. Similary for PPC. Cheers, Longman