silk silk a écrit 1 commentaire

> As I have a couple systems that may/may not be affected, I'm seeking

> some clarification. Is this an effect of the errata published by AMD in

> the Athlon models 4 & 6 revision guides as "INVLPG Instruction Does Not

> Flush Entire Four-Megabyte Page Properly with Certain Linear Addresses"?

> That errata lists all Athlon Thunderbirds as affected and all Athlon

> Palominos except for stepping A5.

>

> Regardless of specific errata listings, will future workarounds be

> enabled based on cpuid or via a test for the bug itself?

>

> The funny part is, if this published errata is the problem, it cannot

> be a problem under Linux since we never invalidate 4MB pages. We

> create them at boot time and they never change after that.



correct, furthmore it cannot even trigger if you invlpg with an address

page aligned (4mbyte aligned in this case) like we would always do in

linux anyways, we never use invlpg on misaligned addresses, no matter if

the page is a 4M or a 4k page. And I guess with PAE enabled it cannot

even trigger in first place (it speaks only about 4M pages, pae only

provides 2M pages instead).



I think this is a very very minor issue, I doubt anybody ever triggered

it in real life with linux.



And Gentoo is shipping a kernel with preempt and rmaps included, so it

can crash anytime anyways, no matter how good the cpu is, so if they

got crashes with such a kernel (maybe even with nvidia driver) that's

normal. I was speaking today with a trusted party doing vm benchmarking

and rmap crashes the kernel reproducibly under a stright calloc while

swapping heavily, so clearly the implementation is still broken. preempt

additionally will mess up all the locking into the nvidia driver as

well. so if the combination of the two runs for some time without any

lockup that's pure luck IMHO.



Andrea