From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 F24F120EB for ; Sun, 9 Feb 2025 02:21:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739067684; cv=none; b=FHWLCxH+ATrSzjIeQsObXsTzQlseOVI6lu/AxcKkVx65GIWMoVhMI42qdQf77A1AdNIHjg6aUl+4eid1wzsxNUQ6aYcvWYx7dIpptG58UiDALTmHsS4gXvYvwxeYkvuX6IxjV6EjRAeJWXgzxa6ZBaGn2TKymnMNsUFxwaSvCHQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739067684; c=relaxed/simple; bh=oLJie9UWNJxd9BkkGwaeRdy2QSgvFMiToNByFI6z9Rs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VlVlfZVb/7EqW9Z27LWT3bhLZLVoA8W0sWeAjzXuF630vUSSCA6hG5hl5dn6/nKAaq6FZ4xRoxRXd9Nc7Qrh/WGvFC/+ICZEKk46CGO58YtXXrxSefLXf+7iuyBtWwdM4QTGcUwk+VtQPEe1+mQ6U3w3tw0CnnVKuahLIoe9G/Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=tqGf/1aj; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="tqGf/1aj" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-2163affd184so96865ad.1 for ; Sat, 08 Feb 2025 18:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739067682; x=1739672482; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=aPYRBH8N0cFSlMms6AVV4eSsR5UK0yhiANnm0hFSLXo=; b=tqGf/1aj/fi6ZXNkBJhuns+7xcKAHeM0jgyENdye4OKMs6uRx+LE0G25XKHPRYCJGo aPjOrENbZV1Ozys6+eNlcxRPUuZ14UNwoM+j9tKVR2sala4AVVXz6Z9+9BcEkxfUNfpD 7eer4AbJoke921pxMvM33ZxC+VvzphFXMxMrzye98DzVIGItZys54fXo7q5ffbuE+sxf 5JbXIl83pEiQlUoFXbnCJLmvfcRZsdQu6bux+uijssiSq+4MKTx5K4M6fKobplpSwgFV 7vPuam4HEVkIK1zvd+GDxlb8484Q67aAak7aB0u1uaWtgD9MQgNtrMalLvtxkhQskJvD /esw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739067682; x=1739672482; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aPYRBH8N0cFSlMms6AVV4eSsR5UK0yhiANnm0hFSLXo=; b=tB7B/KM2mNbBy5p8h2sTK1RuYPquLmldlWCFRhyC7aE+SuJkrWzujSDIjhVnZMivpC o47BJJE5iGVuuyotAXoPqDFOuDcykqJn9b9ZEEVR0z95yDrjYgHngqN+CuVLndnrja7W 3+7DoJwDqpcFblNDM7gpt7zLSGJWzi0t1ZruCAmBljRhNMqenpal4caSajwSBX9KRun/ asjp7FjpK2QAQBdr4TD+RFTOjFgHAmuhkjtMw/g9N91/cJ4EMTZgc2Gwxm4embavjgg1 JJne7widhZsdikoAPSLFbvg2XeHzEHMoiwWNAUG9ml2z7/JaZ5XCWuJUSyq9gp2+ECXq cyGQ== X-Forwarded-Encrypted: i=1; AJvYcCWhUbBP6CQHacGPrCOrTbalVtqQAw5hFFB8tzvx16hAIUk55ac9ALmI0Sj1sCjppFOlP2iQLxvCG2unYXs=@vger.kernel.org X-Gm-Message-State: AOJu0YxkmIj7Q2Tfp0u6H9Bgix7JzGVuo/184XItrx5SRRmumOkX1Tpc oPYDyj1lwSci0lCuWaJ2j4vgti2SR2ZVC8gsqlAzdNRD37YN7I9L0OMQ/MGUtQ== X-Gm-Gg: ASbGncsihofOpsTGrlwOuDke2L4aeIkSuSS7XpfldcOe/qw6RNu53LJziJRKYRNRR22 MAvoFazBzwgO63ICB9ivYQdw3hgG7rGjDTTCtWeHZQWqhE9ewjCPeeX1cY1pq6DwujHMaxjIEkW ZAbhUcbnMgkSVdC2HJjGIiiQ0ijN6+bdAp4TGpdwTJpIl8bwknupaZM6CDKOAibB9SmXyYpPdbv UrO8dRteXgejfPyHnspHrXfLe019EjaRNSyxUI7IOm2I/5ovX7CwNvz7EQAIQuEnXbXkXHCLaPc rGSvNQ8HE5t8QZp+n3K2eGX9NfiYh2z0xfd7EHfazfe8oeOxLJvi0w== X-Google-Smtp-Source: AGHT+IEowLr0ODuJvhhRX0k3wQ9ChkhKhAElhUwga2QcQJLk+imc7mKSniosyKtNBmFd0SxXKu92Ag== X-Received: by 2002:a17:903:144b:b0:21f:3e29:9cd4 with SMTP id d9443c01a7336-21f69e53acdmr2101805ad.20.1739067681888; Sat, 08 Feb 2025 18:21:21 -0800 (PST) Received: from google.com (147.141.16.34.bc.googleusercontent.com. [34.16.141.147]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-73048c15baesm5148861b3a.121.2025.02.08.18.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Feb 2025 18:21:21 -0800 (PST) Date: Sun, 9 Feb 2025 02:21:16 +0000 From: Peilin Ye To: Alexei Starovoitov Cc: bpf , linux-arm-kernel , bpf@ietf.org, Xu Kuohai , Eduard Zingerman , David Vernet , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Jonathan Corbet , "Paul E. McKenney" , Puranjay Mohan , Ilya Leoshkevich , Heiko Carstens , Vasily Gorbik , Catalin Marinas , Will Deacon , Quentin Monnet , Mykola Lysenko , Shuah Khan , Ihor Solodrai , Yingchi Long , Josh Don , Barret Rhoden , Neel Natu , Benjamin Segall , LKML Subject: Re: [PATCH bpf-next v2 4/9] bpf: Introduce load-acquire and store-release instructions Message-ID: 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: Hi Alexei, On Sat, Feb 08, 2025 at 01:30:46PM -0800, Alexei Starovoitov wrote: > > Introduce BPF instructions with load-acquire and store-release > > semantics, as discussed in [1]. The following new flags are defined: > > > > BPF_ATOMIC_LOAD 0x10 > > BPF_ATOMIC_STORE 0x20 > > BPF_ATOMIC_TYPE(imm) ((imm) & 0xf0) > > > > BPF_RELAXED 0x0 > > BPF_ACQUIRE 0x1 > > BPF_RELEASE 0x2 > > BPF_ACQ_REL 0x3 > > BPF_SEQ_CST 0x4 > > I still don't like this. > > Earlier you said: > > > If yes, I think we either: > > > > (a) add more flags to imm<4-7>: maybe LOAD_SEQ_CST (0x3) and > > STORE_SEQ_CST (0x6); need to skip OR (0x4) and AND (0x5) used by > > RMW atomics > > (b) specify memorder in imm<0-3> > > > > I chose (b) for fewer "What would be a good numerical value so that RMW > > atomics won't need to use it in imm<4-7>?" questions to answer. > > > > If we're having dedicated fields for memorder, I think it's better to > > define all possible values once and for all, just so that e.g. 0x2 will > > always mean RELEASE in a memorder field. Initially I defined all six of > > them [2], then Yonghong suggested dropping CONSUME [3]. > > I don't think we should be defining "all possible values", > since these are the values that llvm and C model supports, > but do we have any plans to support anything bug ld_acq/st_rel ? > I haven't heard anything. > What even the meaning of BPF_ATOMIC_LOAD | BPF_ACQ_REL ? > > What does the verifier suppose to do? reject for now? and then what? > Map to what insn? > > These values might imply that bpf infra is supposed to map all the values > to cpu instructions, but that's not what we're doing here. > We're only dealing with two specific instructions. > We're not defining a memory model for all future new instructions. Got it! In v3, I'll change it back to: #define BPF_LOAD_ACQ 0x10 #define BPF_STORE_REL 0x20 Thanks, Peilin Ye