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 CD4BC19309C for ; Tue, 28 Jan 2025 08:10:33 +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=1738051836; cv=none; b=kDFjgMwn9bbZngLn/3ReZTHmS3lqMTKq9YP1jYQaSZBs0jiwYXLmvyGARR2ezf80le3M8y9y/uPpvTjMUaNKWs1Z57mXgDGR9/dK6F/GWR+DA1nj49hAv6j58ez87xx6/EcOlCvO6ZjjynIn2yWDCZ0EJSA7CCr6NfvK0BzMIyI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738051836; c=relaxed/simple; bh=x1FJNO5SXh8rheXbBShHJ5U3BCBqChmV+BqScE8n/+I=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=A/30TU1Zs9n8QUwXVtU5lgUYzMTbQV5bzGciBw16j7O1wXHMCMinVaN1MQASt0tElLyG4/Q409UwHXGMS9ynaCfYeU9oUc3PFG6OnuCf5q2KUJQjOaaCeq+3WOKSXt2G3INsDBZSk74Ev9cMp1FognsJHUDgaav27AK+zYD8YFQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=Ain8iMKF; arc=none smtp.client-ip=209.85.214.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="Ain8iMKF" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-21c2f1b610dso124210595ad.0 for ; Tue, 28 Jan 2025 00:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1738051833; x=1738656633; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m258w8dJxz5HR+kMdkqF8oyJmKeGuzgT5afDJjiYj2I=; b=Ain8iMKFV6kSiYDv9EVmg/QCyAN+LjZOqM3EFd006rCUCx3JfdoTb5EDthofN4SNBd gQsJ3iUsXccvMsDWEg874kFw3jDWd+L3G6V1N9DAgrzUVGO+WR1sH/eUu2NwKaDcr+bt sSc9Wnyq+ZCOohlKpAYa4DL67vwFE510r9TTMkwDXVcPYwnYNfUYXE/ywdg0uN8PKxLu F+fu2N/MLm7YaKP1MolkJ0NyLqHEXKcGs6slRx6cn85sM0RvpqJ/T9ErzNY0enjgw3WP GtLv8aOw2jOGzbIEgAKFqjWMlvHV8irkSy9ol+wrX6ZBaPMGt1tcNjHHchBsTjmNOTPS ZEDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738051833; x=1738656633; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m258w8dJxz5HR+kMdkqF8oyJmKeGuzgT5afDJjiYj2I=; b=n3uDGmoKP1ftvx6JGiVF3OWig4Ca31paVAWbbNnHIbBl12ls+SwxvhVo/u+lBrdjsx SOJ1CdDLpecm1vAZalREuFwrzIpIO7AyVTzjL3hHo7Rh35towVRWmXj4I9I9rH6M/rQf sMSYD5CUBK+pMzHoZOSOlkmNU/g5lFeKjPMJoAjjWy6yW6P/WG2JrZx5pew5yfsEx1hr zJKmHBdpZeVN7x6En6KtLGhH0CpI1iJMNBNMCEqqLx/SA3V0Fsdt4k/hqbpiljNXjwN2 jfBk2pxiwfsKk/hFYz6+Vvhx/YeXNWCyMDBDxSWfp0d004qtuGqGPIK7bUewP6xmiaCD 0Mrw== X-Forwarded-Encrypted: i=1; AJvYcCUW2rTlLPQl/BbbfT6KjoGnEURHNE+z33N9iH/zp3iA70bOLsJLx0rxFiw2hT44VMPIk6vWCdXmOqWwVtA=@vger.kernel.org X-Gm-Message-State: AOJu0Yxoq+djsoHQT7sZLVfGyFXDwMQaykdJHUiEtiRj8PRz3qypCbn/ cI0MtNRTP/bjvSiNx8muq8L9qLqw79rBrY9luOTQ/phMcqtl559UTciFKHpbH7E= X-Gm-Gg: ASbGncvvtkWMEjnpQSfRbkMR2b/MvRduWJt0ul8fa4ZEwo3eXSta/COQ3S5vb7XFK6e bhmQ21QRBiEdcI5cPJ7zLngzR7Ktnv/QoHAsGEriT4aPifZfR+wxdgABE5kFloEtivUaWqlrLOd iQ60vbr9yhAWkPXSi8Dl81Lkx7ZhEs4Or6QRyEGyxog9XcFYXuX7DrozHMPii3BbweQZCiaUR2O 1PhsUXgYj5MqhRxYlwy9sfC31Jau7uudyZExjeEp8xIFfJIDJ++oC5ZmWdEvd/Qioy1H4RgLY86 S2oPtKaB/WY7D55TjfV27qRjot9Gb1wRzBk3nN+h1UXoWgPJpUbWwDcdMOSj X-Google-Smtp-Source: AGHT+IHDmEOcULSXx6v19eA35NSq2IM7B/YhvJ1Sx1iHSXvE2QmuT8LtSkzPnBOxM5b/dOdaKXN7Yw== X-Received: by 2002:a17:903:22ca:b0:215:603e:2141 with SMTP id d9443c01a7336-21c35511d01mr714453715ad.19.1738051832955; Tue, 28 Jan 2025 00:10:32 -0800 (PST) Received: from ?IPV6:2a01:e0a:e17:9700:16d2:7456:6634:9626? ([2a01:e0a:e17:9700:16d2:7456:6634:9626]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21da413f474sm76611115ad.130.2025.01.28.00.10.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jan 2025 00:10:32 -0800 (PST) Message-ID: <32cc0753-a033-4f55-8aca-09416f62faa8@rivosinc.com> Date: Tue, 28 Jan 2025 09:10:19 +0100 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 v3 2/4] riscv: add support for SBI Supervisor Software Events extension To: Alexandre Ghiti , Paul Walmsley , Palmer Dabbelt , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Himanshu Chauhan , Anup Patel , Xu Lu , Atish Patra References: <20241206163102.843505-1-cleger@rivosinc.com> <20241206163102.843505-3-cleger@rivosinc.com> <649fdead-09b0-4f94-a6ff-099fc970d890@rivosinc.com> Content-Language: en-US From: =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 27/01/2025 09:09, Alexandre Ghiti wrote: >> I believe the goal is not the same. Using CONFIG_VMAP_STACK allows the >> kernel exception handling to catch any stack overflow when entering the >> kernel and thus using vmalloc is required to allocate twice the page >> size (overflow is when sp is located in the upper half of the allocated >> vmalloc stack. So basically, this is two distinct purposes. >> >> AFAIU, kvmalloc allows to fallback to vmalloc if kmalloc fails. This is >> not what we are looking for here since our allocation size is always >> quite small and known (STACK_SIZE basically). >> >> But I might be missing something. > > > arch_alloc_vmap_stack() only vmalloc the stack and does not implement > any stack overflow mechanism, so I'm still unsure we need the define. Hi Alex, So actually, the stack overflow check itself is done in the exception entry. It check if the stack pointer did passed in the upper part of the vmalloc allocation (see entry.S:122). In this allocation, the stack size is actually * 2: #ifdef CONFIG_VMAP_STACK #define THREAD_ALIGN (2 * THREAD_SIZE) #else #define THREAD_ALIGN THREAD_SIZE #endif So even though it does nothing special by itself, it centralize the allocation size/method. And size the size is larger, using vamlloc makes sense I guess. The same mechanism is used to allocate irq stack as well. Thanks, Clément > > Thanks, > > Alex