From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 D98D821019E for ; Mon, 19 Jan 2026 20:48:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768855708; cv=none; b=nJcwYNSPubbi63n6xBjN5kJeVSFt+Fm2Qxv+EuQ0lfZ26IrH+9HlSQmnr7sCEUDRxU7n1YA8KhFBXXTFZ11YrNHtnndWikAeBurStsAHXL89Y/6kBwiEdMweXG43pDObRkAB8NbQXmiiy0y+erp+A0qdTIMX7Qtg8HC8i8/E7ps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768855708; c=relaxed/simple; bh=OTIL6Loch3W5HT8K3/5drQB2NyA4JRAnkOJv2pognEg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WQobMkEI/1Rtwo69PUPxb489UYM0Pxu4Q1l3I/5Tkhzptb26cND0o69dNuyTno5DXW5+W92cxqB2Hnx9iu1GlsPzyl0T5Kle3HbJYnj49cfobXGEzGo1aKFZ8FKqphOBZrNsZSqhshJMpWOs7mtDbolI9Yptrh9+oO6+mjN4+ug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Bi5N8Jef; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Bi5N8Jef" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-47ee76e8656so54366975e9.0 for ; Mon, 19 Jan 2026 12:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768855705; x=1769460505; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=9zOo8J2/R5/ZECF8jXBFWc70aqTEGil4wxpiWbgmSlI=; b=Bi5N8JefgTI3F3lOzTajlWrBEWZnXQf14QsriR6lfGutcky8BMfxJUvqmV2VTdo5tw HK4FPBPs7pbkCCJzoN9+ZahvsGJiwzG97xF8NjGY9E+2PaQupjJglU1R7dJ7Yow2+7pj 0WRG9vlhKpTE9jQ/6ywk1+YC7kqzPGzTxK7fq3GR9jW04f2Ww+oPSnjnWHaTHPdnipHF 5QCYiiJJB0zBf+Zs2l40XUvbdjA6HU/USUoI2OH9QPw73h/RxkTdXx7oBG1BX2gF71zy HjBEXr3kd7GSrXstAv+Xu1Vhf+BkKS54n9jWA3blA9nQej+3EXSyiXv0fT5TL4JAUvev MzcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768855705; x=1769460505; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9zOo8J2/R5/ZECF8jXBFWc70aqTEGil4wxpiWbgmSlI=; b=V7WTVwy/0ImoAdTTp0/DgimgtcG9ACH2WGPHRlY/KJ9zImnOlZWnjY6DMa6ALRJCA8 RWcdnhkyAOZcYjDs0baoajvkpxNzsh1qRqXRg9fs8+zj2mr22s9Nh00dHfPJtIUjw6F4 gTMbmt/kvH0DrXNqXKks8UxXNft+MVWFmazgbPPjA3YUc8ZgvAgwxNOpg3t93Wo5v5L6 mWHUb4KlBllodHTzCmLEgpv1asT2nq0bvNbtkPCDGAZ20Rka95KndVW0jtCBHdJuoBaO U6XKU6isqx3Weh/yb97UnMXJH5po15AuZ/m8E4lvXiVuK4axU07OKgUKjfpZ3x90P0jh Kzgg== X-Forwarded-Encrypted: i=1; AJvYcCVjX+K69WsTB31MRJ5LYeURyPNE1BdQoJdvSWzjNJ+/S/I4qU6fpQ39ch8CZAy/Z8Az9bKNTHruPJRxJ64=@vger.kernel.org X-Gm-Message-State: AOJu0YzOn7Rx35jqJ1bx2vsStZ8Jje+TEOaF6TJvOUtiOXEfGimWHsdP 9Ao6hM5cE0unwhnGJC4C6XYFpv8dWaOu31R96FmjefUWrVxiDD+5MEqh X-Gm-Gg: AY/fxX5sbcc0crCXIYUvF2fZkboYujXJ4dAEDiXRkuxnDCyrvsI+F0bbP9KvfEsXSyL +eynlNBqXeVkreCiSTZIYPWCK4gD0/qg7dodoAY7cWpOmCvLfvF4+o5LdGkLkbEz8nF/mJbRhUt mXNhO0tuvlOqIZSNS+fBmaHVeC6MX33s2y//3QwojRVdP7uefhH7nH6Qf90mZi9lnvi41fPn87N oYmM6gkLjmiE62/dNGRfkAxNmDIChj++zPF5gG49erRbXzjd1iORfSQfYlSkpLfFMh83RLofltF KKMT0NclzvkmdYsc+rk6QQdwgItbpAdqS5Vcyoi3jxBXi0vhAUpQEVEAafRnonpm4etOMQp7Pb0 yc6tblGl2QF0vx4ETrEAJ7TyB3U74MvYxRS2EQuM8D9ymorpqb673RuPuFoNA5rAMgVJauEP4WZ DGfFYi X-Received: by 2002:a05:600c:4e93:b0:46e:6d5f:f68 with SMTP id 5b1f17b1804b1-4801e30b737mr159086915e9.12.1768855705113; Mon, 19 Jan 2026 12:48:25 -0800 (PST) Received: from curiosity ([80.211.22.60]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4801fe3b01csm92808125e9.5.2026.01.19.12.48.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jan 2026 12:48:24 -0800 (PST) Date: Mon, 19 Jan 2026 23:48:21 +0300 From: Sergey Matyukevich To: Andy Chiu , Paul Walmsley Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Paul Walmsley , Palmer Dabbelt , Alexandre Ghiti , Oleg Nesterov , Shuah Khan , Thomas Huth , Charlie Jenkins , Samuel Holland , Joel Granados , Conor Dooley , Yong-Xuan Wang , Heiko Stuebner , Guo Ren Subject: Re: [PATCH v5 2/9] riscv: vector: init vector context with proper vlenb Message-ID: References: <20251214163537.1054292-1-geomatsi@gmail.com> <20251214163537.1054292-3-geomatsi@gmail.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi, On Wed, Jan 07, 2026 at 12:49:31AM -0600, Andy Chiu wrote: > On Sun, Dec 14, 2025 at 10:35 AM Sergey Matyukevich wrote: > > > > The vstate in thread_struct is zeroed when the vector context is > > initialized. That includes read-only register vlenb, which holds > > the vector register length in bytes. Zeroed state persists until > > mstatus.VS becomes 'dirty' and a context switch saves the actual > > hardware values. > > > > This can expose the zero vlenb value to the user-space in early > > debug scenarios, e.g. when ptrace attaches to a traced process > > early, before any vector instruction except the first one was > > executed. > > > > Fix this by specifying proper vlenb on vector context init. > > > > Signed-off-by: Sergey Matyukevich > > Reviewed-by: Andy Chiu > Thanks for reviews ! What would be the recommended way to proceed with these patches ? I have reviews from Andy for the patches 1,2 and 5 (selftest for 2). They can be used independently of the remainig ptrace v-state validation changes and their tests. Would it make sense to split the series into two parts, so that the v-state validation can continue evolve independently ? Regards, Sergey