Re: [PATCH v12 6/8] x86/traps: Communicate a LASS violation in #GP message

[Sohil Mehta]

On 11/17/2025 10:29 AM, Borislav Petkov wrote:
> 
> Ah ok, that makes sense. That comment still reads weird:
> 

I see. The idea with the comment was to clarify why the check is outside
cpu_feature_enabled(X86_FEATURE_LASS). That clearly failed! :)

 > I guess you want to have
> 
> 	if (cpu_feature_enabled(X86_FEATURE_LASS)) {
> 		if (*addr < PAGE_SIZE)
> 			return GP_NULL_POINTER;
> 		else
> 			return GP_LASS_VIOLATION;
> 	}
> 
> so that it is perfectly clear.
> 

You are right. The condition would typically hit only with LASS enabled.
But since we are adding an extra hint for NULL pointers, I figured it
would be helpful even without LASS (even though it is unlikely to happen).

Therefore, the printed message isn't LASS specific either:
Oops: general protection fault, kernel NULL pointer dereference 0x0:

Also, it makes the code a tiny bit prettier (aesthetically, without the
nested if). We now have 4 hints and a check for each:

if (condition1)
	return HINT_1;
...

if (condition4)
	return HINT_4;


Would this update to the comment help clarify?

	/*
	 * A NULL pointer dereference usually causes a #PF. However, it
	 * can result in a #GP when LASS is active. Provide the same
	 * hint in the rare case that the condition is hit without LASS.
	 */
	if (*addr < PAGE_SIZE)
		return GP_NULL_POINTER;

	/*
	 * Assume that LASS caused the exception, because the address is
	 * canonical and in the user half.
	 */
	if (cpu_feature_enabled(X86_FEATURE_LASS))
		return GP_LASS_VIOLATION;


Though, I won't push for it further. Code clarity is more important than
reducing indentation.