From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1DB8B1A0712 for ; Thu, 2 Apr 2026 20:49:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775162946; cv=none; b=DL1Y75b2smXGm31o4glkeDd3A+W8WTks3uKY0jH9Oll9ETnVoOZIwX0AIyCsYOwUA4T2W+vonlyMKO0O3VlZCeKeUcwvtoZ/24QylQWt7qzHoxQY707u+l2186yTcdxcE/swy7IJZdwAg6T0BKJorOsaG3wqrb9pPUFTD9rqNFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775162946; c=relaxed/simple; bh=G3lzDJVm1AXnyffk9/1ZUAfMj0m9JR29ERr7dMmDOMU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=GcuA6C0VJJrfOhf2BAp8lqan3PFb+TnPnn7Qm46yS4Zc1oh5AWnU99mQxQqWVpUOQ0fd2VnyKCWsnsezLW4Do2OvdxhLx/5YJ7AyNHR+ImtIn77KAUuwUGc7RXBwJQ54ywUwkPnOqsdenPMZZP4yg2lIbdP8fdA8+aUSe/6Bwx8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tYz8qEds; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tYz8qEds" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3BA4C116C6; Thu, 2 Apr 2026 20:49:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775162945; bh=G3lzDJVm1AXnyffk9/1ZUAfMj0m9JR29ERr7dMmDOMU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tYz8qEdszX/dxzdmAZTZsQJ5fS4vQGTsaJw+btPQ85Sq7920Kw+p7spuZXJjLTlCH y2VX1nCzJaAsaCgYk2sD2VcJeNgpcf99JPLmEJpmrJVYs0uT5/Upw5jH+C3IMqM3tu 6n8VE/iaquczEgSlokUCNYfEGgqhxGoHADYQ2strHinO+7wGJNW8SoR6qFtIaL/fmu E1ljYDHBV9KNrnlrS+Rc+y2v9WjGg1bIQyI8U4da/MzTuTHp2yw2z+0ltB2p6GwRXY vAs8lYtMNpSNcS/pVmKhrk6ZFJYIr/aB5Mgu4np1AXXdhWx/4y3FWdbkbK0AQwxlAM NDNaLRbG4OGtQ== From: Thomas Gleixner To: Roman Storozhenko , Borislav Petkov Cc: "H. Peter Anvin" , Ingo Molnar , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/msr: Remove misleading "unrecognized" wording in write warning In-Reply-To: References: <20260325-dev_roman_msr_msg-v1-1-cd51e2579018@gmail.com> <20260330141641.GCacqFyVoaOSpIea9O@fat_crate.local> <20260401192703.GKac1xh3_4aYunqJDB@fat_crate.local> Date: Thu, 02 Apr 2026 22:49:01 +0200 Message-ID: <87h5pt6qbm.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Roman! On Thu, Apr 02 2026 at 19:37, Roman Storozhenko wrote: > I can use 'allow_writes', but userland SW uses "/dev/cpu//msr" > relies on default msr driver behaviour. Indeed, it would be strange if > such SW reloads a kernel driver (if it is possible) to make sure that > this message doesn't appear. Most distributions don't pass that > parameter. Sane distributions use allow_writes=off because allowing user space to write to random MSRs is a system stability issue even if the interface is restricted to root. > Let's take a SW I work on as an example: > https://github.com/intel/intel-cmt-cat > > If your CPU supports Intel RDT you could build and run it: If my CPU supports RDT, I use RESCTRL in the kernel. It provides a proper interface, monitoring with all bells and whistels and is fully integrated into the kernel task and process management. RESCTRL has been around for almost a decade. Your colleagues Reinette and Tony spent a lot of time to make this work in a sane way, so the real question is why you need a seperate tool which works around the provided and sane interfaces. > to see that 'unrecognized' messages in dmesg periodically. We don't need your tool for that at all. wrmsr(1) is sufficient. > Both allocation and monitoring use 'msr_write' and 'msr_read' > functions that rely on '/dev/cpu//msr: Which is wrong to begin with because the kernel provides full support for it. > Our stakeholders interpret that 'unrecognized' word as a writing to > wrong or non-existing MSR registers. Your stakeholders seem not to care about the way worse CPU_OUT_OF_SPEC taint. Are you going to remove that next? > To be honest I interpreted this in this way too, unless I read msr > driver code. That is why I posted this patch. My intention is to > align this message with what is really happening in the driver, that > is writing to a valid register, but against the current policy. I kinda agree with you that the 'unrecognized' wording is suboptimal and it should rather be explicit about user space [ab]use of the interface, i.e.: "User space write to MSR ...., tainting ..." or something like that. The changelog surely should explain that 'unrecognized' is not the appropriate word, but without a lame justification why such tools exists in the first place and need to be supported gracefully. The only justification for them is experimentation and people who do that should know what they are doing. If they get confused by the message then they should not touch CPU MSRs in the first place. Thanks, tglx