From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 6F449802 for ; Tue, 31 Dec 2024 01:15:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735607751; cv=none; b=DP7vhaOak1gjL4EiXGKkwGz3jMz1iGNa2fFiV6KKsV2RLApdZqhHzymzHaj/pSMypk7foUQmruntRDZofnjw9xWeB1crmvz4jzlc1XTQvdH9vZWpMRyxvv3hOjO1iwSE7XIifhZoodxUA9XNM1/O/6aVWqK7Hg2NOQuHdBEelgA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735607751; c=relaxed/simple; bh=sSY1XbF1oxRIXmmaijhJ4nXaZUQVUXWqa4rhwBiQB+Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UlZap2l64oyGt1yR9fYoqXv6r8WJtdTwwxlfEObRwMXBHaIQVMIGfGEo7Q8S631wy4piMYypKxc3vOl9cfuQJsjVjRtJKqHDrUCIOutUEE8HTeHfSQcATv/llCM4gtqxt/iDzzdZ6Nk/C9I8SkeFZzT7DqK9jKikClnwXiF691o= 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=BLOPqR+X; arc=none smtp.client-ip=209.85.214.179 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="BLOPqR+X" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-21625b4f978so1101795ad.0 for ; Mon, 30 Dec 2024 17:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735607750; x=1736212550; 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=bU44DfVNFhZdddKP7sqRrnrWS7eQdXIUVL22LBgqP5Y=; b=BLOPqR+XrIG9kMR411hZCSXjOVrsw/9hER9s8thiMIiyZMzcv32h+9v4SdAs4NhwXS BmyiWIOr7G7IVedAA5fsBEykr9ZCP7dSEAppNSGyDpHRduwX+tFFO0irOfbia46EB4GV 3f2uCuMGihMpuhKaKrP/Inm1gQgfFdfgLZPCxzQ52eErlPj2NYVOjcEyGzRPj74jHBPt fyeXTPNQtYWQqucTOvJZia+0Xh0MrJXLJkGFJUPP/ezbKez+qtjDDG4Fjxja2360pfdj NF2ptGFfQpI8IAcLL7H5pzhZpJdzOUd7PMVYp8RwtSdchRmnKxxFaoj2wCkJ1QyGFVQP MIZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735607750; x=1736212550; 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=bU44DfVNFhZdddKP7sqRrnrWS7eQdXIUVL22LBgqP5Y=; b=t8A55BIRcl6OGaEmSUEWQlo2mreTmRxg5eMAfoLadQ0BUfTnpicNZVF2+9RNHG9Q6a nz3j4Uqv1YWDtkHuX8SsaSeDYrVqJx7Y4g8Y0g+KwJ0IlU8A2ImePNIRiGvjdK1Wob/U ZSZltEIiXYLm4DpPrygqCunZGnsM5ILKKyKQbA7ttBZ3dOpsXjs1FtVv8FMzHu0W6uX/ 96GRJFqjAVWPLnNSTrcnqHKFzx7OwlruQceAy+Ie/KNEQLWBvyfCcfPqykHVqZQ485BM aASXhPZA6Qyw9RELd7NVx1t58Q2bH15aoRB/bvlG4l47elEnQWjbrsXmBybIzfDXk50m qFZg== X-Forwarded-Encrypted: i=1; AJvYcCUe6I3+q6KWE6BcLa2nqcRX+m/5tF068d1qHFGfYVA8SYT5ARNk4QSrK37GFVvS+iPBTf2PgN7tE0SVgY4=@vger.kernel.org X-Gm-Message-State: AOJu0YxL+qmXLRwiHtNY3fHoPejRcPB4HpHwxoMdcKtwMmhAPrQEssO+ 9qqxWdXqcq08LyDiCgVRc1BqX2ZK0DtZ9a2KLjsMQHmF69hTqz7z9I7ljFJWuA== X-Gm-Gg: ASbGncupo5HcasGF4HjnKSKOuJbfJENt/iKxfjBvLr/7Pvrw+f+DQlWKC07XxydQzIz VoosqDSEeJsNONDRufnggZMqCYABZ5ARJENV/fhhs0fLBMP35+dMYgXb234L+ck9ejor2NeithR kOj9A+mnsY7MgOzipJw30OVbaE9uI0B5sR7N/9d1p7khe5xUvNIh28FNHPUHzYhyWnPORxsi1Io pXj6iGW678Cl2e0FoHgUJJSLyWLeSHK9yIMqTzlBqN/VtHkp4vX2CdQOZmW8E9tkVWw+h89bqFz HG/57SugAPgGn+PRKT4= X-Google-Smtp-Source: AGHT+IG9vVXq0bODcOzVtZg8nKb4yp7ntyqpp3MtBhtWHUC+tXvqnTJ2k0jASUWKN9LVZAYRo5ShmQ== X-Received: by 2002:a17:902:ea05:b0:216:201e:1b63 with SMTP id d9443c01a7336-219e770bffcmr15717445ad.11.1735607749360; Mon, 30 Dec 2024 17:15:49 -0800 (PST) Received: from google.com (40.155.125.34.bc.googleusercontent.com. [34.125.155.40]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad815835sm20584170b3a.27.2024.12.30.17.15.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 17:15:48 -0800 (PST) Date: Tue, 31 Dec 2024 01:15:44 +0000 From: Peilin Ye To: Xu Kuohai Cc: bpf@vger.kernel.org, Alexei Starovoitov , Eduard Zingerman , Song Liu , Yonghong Song , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , "Paul E. McKenney" , Puranjay Mohan , Catalin Marinas , Will Deacon , Quentin Monnet , Mykola Lysenko , Shuah Khan , Josh Don , Barret Rhoden , Neel Natu , Benjamin Segall , David Vernet , Dave Marchevsky , linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC bpf-next v1 2/4] bpf: Introduce load-acquire and store-release instructions Message-ID: References: <6ca65dc2916dba7490c4fd7a8b727b662138d606.1734742802.git.yepeilin@google.com> <4e6641ce-3f1e-4251-8daf-4dd4b77d08c4@huaweicloud.com> 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: <4e6641ce-3f1e-4251-8daf-4dd4b77d08c4@huaweicloud.com> On Mon, Dec 30, 2024 at 04:27:21PM +0800, Xu Kuohai wrote: > > > As explained above, RS and RT2 fields should be fixed to 1s. > > > > I'm already setting Rs and Rt2 to all 1's here, as AARCH64_INSN_REG_ZR > > is defined as 31 (0b11111): > > > > AARCH64_INSN_REG_ZR = 31, > > I see, but the setting of fixed bits is smomewhat of a waste of jit time. Fair point, I'll instead make load_acq/store_rel's MASK/VALUE include those (1) bits. > > On a related note, I simply grabbed {load,store}_ex's MASK and VALUE, > > then set their 15th and 23rd bits to make them load-acquire and > > store-release: > > > > +__AARCH64_INSN_FUNCS(load_acq, 0x3FC08000, 0x08C08000) > > +__AARCH64_INSN_FUNCS(store_rel, 0x3FC08000, 0x08808000) > > __AARCH64_INSN_FUNCS(load_ex, 0x3F400000, 0x08400000) > > __AARCH64_INSN_FUNCS(store_ex, 0x3F400000, 0x08000000) > > > > My question is, should we extend {load,store}_ex's MASK to make them > > contain BIT(15) and BIT(23) as well? As-is, aarch64_insn_is_load_ex() > > would return true for a load-acquire. > > > > The only user of aarch64_insn_is_load_ex() seems to be this > > arm64-specific kprobe code in arch/arm64/kernel/probes/decode-insn.c: > > > > #ifdef CONFIG_KPROBES > > static bool __kprobes > > is_probed_address_atomic(kprobe_opcode_t *scan_start, kprobe_opcode_t *scan_end) > > { > > while (scan_start >= scan_end) { > > /* > > * atomic region starts from exclusive load and ends with > > * exclusive store. > > */ > > if (aarch64_insn_is_store_ex(le32_to_cpu(*scan_start))) > > return false; > > else if (aarch64_insn_is_load_ex(le32_to_cpu(*scan_start))) > > return true; > > > > But I'm not sure yet if changing {load,store}_ex's MASK would affect the > > above code. Do you happen to know the context? > > IIUC, this code prevents kprobe from interrupting the LL-SC loop constructed > by LDXR/STXR pair, as the kprobe trap causes unexpected memory access that > prevents the exclusive memory access loop from exiting. > > Since load-acquire/store-release instructions are not used to construct LL-SC > loop, I think it is safe to exclude them from {load,store}_ex. Ah, I see, thanks! I'll extend {load,store}_ex's MASK to prevent aarch64_insn_is_{load,store}_ex() from returning false-positives for load-acquire/store-release. Thanks, Peilin Ye