From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.228 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793787492; b=v0SHnefD2aDDR1euhH6G9fjWZPLAIkqFlS7wQkK9+VxAB0vSt83cV1vglfU+TO0a9rXy cTFhsHpSxHhn0jOm7RaRLFYldJCKun9lu3vKJO04OluR77yuPIblyT6qI1u9grG8Ugmzm cr7ZaDkwyq5StKsXKFzHnlPW/+C9BXxRyzpUoiFInVJiojRb7fBCZVcPep6m1411EW17l Tb/MZL4Nxz4Fcq9NR9GwAaLHvvkfEL1gMqE/1jhWXg+A+oauSpWbcJabTZPn1rQsrye0b EYPQqFuxN0g+BfEcu6VHTKkXGVZMP49DoAexZEO21QyNdB7hS1PyRbv5ty9VJInAv9A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793787492; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:From:To:Cc:Subject:Date:Message-ID: X-Mailer:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding; bh=kzlN/YSlDBcWBl/PHuR26tChnN3ik0juVI5FwAqXzXw=; b=MBCSqReFGP1fvaFwUcxX97kXTI7K6C7JlWBYuBUiYrH1VjMmk8P/vDvb2pNBcsTe/Q5r JUSzvP6N0vF16nxfJ6C8aR+Z4/H5GqOIwBfLBy3Q1A0G029hw2n43NXUH8VwnnR1/FYvi tgdHyamuHEouJJL+IA7tdcuOLE9AzloU1YI9bRbW6duX/tpfmrLzna0T8yjC0LRvZ0u89 +HRKik8cKVM+mUZCEy6jaAVcfvnbEQk0d5Y1kV8waLzkVNhwtqb74Xps0o3hkaHJ2xQdw nZLsqeJVkVk7UFCz+MCl2h7wwK/2BlKzV1CKJbQAM9HzXyC1KBUITxa622NTw3UGpow== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b="s/Dw6yqL"; arc=none smtp.remote-ip=91.218.175.228 Received: from mta0.migadu.com (out-228.mta0.migadu.com [91.218.175.228]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96A2A606A333 for ; Wed, 4 Nov 2026 10:18:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 96A2A606A333 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=s/Dw6yqL X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=QICrwvJ1q+p6O5FfC7tO/QRvFz9LYnqsPT4idoPDTMg=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793787486; v=1; x=1794392286; b=s/Dw6yqLjHgjK4hC+q3he0UIo9WlnSbuhHZictdeYHfn0g5eLA+/jLTEsDkKqQY+gbMBbTFv E0JxTJeYiHFf5PxfyrFlG4LPlvNpuBlWmQasw907mX2iCbXTKmT3DQAlg/i7orQfFNco2MRDl5F /JMtvzwzP+ultA/y2OOC4zBo= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id b7af79601e9f84b4; Wed, 04 Nov 2026 10:18:06 +0000 X-Mizu-Trace-ID: b7af79601e9f84b4 X-Migadu-Flow: FLOW_OUT From: George Guo To: yangtiezhu@loongson.cn Cc: chenhuacai@kernel.org, hengqi.chen@gmail.com, loongarch@lists.linux.dev, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/2] LoongArch: BPF: Make arena support depend on SCQ extension Date: Wed, 4 Nov 2026 19:17:53 +0900 Message-ID: <20261104101753.20704-1-dongtai.guo@linux.dev> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20261102072808.23080-2-yangtiezhu@loongson.cn> References: <20261102072808.23080-2-yangtiezhu@loongson.cn> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Tiezhu, On 2026/11/2 15:28, Tiezhu Yang wrote: > This is because the arena range tree uses kmalloc_nolock(), which requires > 128-bit atomic cmpxchg support, provided by SCQ extension on LoongArch. There is an existing SLUB debug fallback worth checking before making arena support depend on SCQ. In __kmalloc_nolock_noprof(), the rejection condition is: if (!(s->flags & __CMPXCHG_DOUBLE) && !kmem_cache_debug(s)) return NULL; Debug caches do not require cmpxchg128 for this path. They use kmem_cache_node->list_lock with spin_trylock_irqsave() instead. With CONFIG_SLUB_DEBUG=y, booting with slab_debug enables this path; CONFIG_SLUB_DEBUG_ON=y enables debugging by default as well. The proposed bpf_jit_supports_arena() check would reject arena maps on CPUs without SCQ, even when the SLUB debug fallback is available. This would prevent us from running arena tests on those machines with slab_debug enabled. Could you rerun jit_insns/cast_to_user on the 3A5000 with slab_debug enabled, before and after this patch? The claim that kmalloc_nolock() requires 128-bit cmpxchg should account for debug caches, and it would be useful to preserve that fallback when addressing the error reporting. Thanks, George