On 19.04.22 14:00, Miaohe Lin wrote: > On 2022/4/19 19:46, David Hildenbrand wrote: > ... >>> Do you mean that we should set the pfn to 0 for the hwpoison marker so that we can >>> distinguish swapin error case from real hwpoison case? >> >> I am not sure if we really have to distinguish. However, "0" seems to >> make sense to indicate "this is not an actual problematic PFN, the >> information is simply no longer around due to a hardware issue. >> > > IMHO, we have to distinguish. For example, we might need to return VM_FAULT_SIGBUS > instead of VM_FAULT_HWPOISON when user accesses the error page. Or should we simply > return VM_FAULT_HWPOISON to simplify the handling? Hm, you're right. In e.g., x86 do_sigbus() we would send an BUS_MCEERR_AR. So yes, if we reuse is_hwpoison_entry() we'd have to convert to either VM_FAULT_HWPOISON or VM_FAULT_SIGBUS. Something like "is_error_entry()" that can further be refined to hwpoison or swapin could make sense. But what you have here is straight forward to me as well. Whatever you/others prefer. Acked-by: David Hildenbrand <david@xxxxxxxxxx> NIT: I'd make the terminology make_swapin_error_entry() consistent with SWAP_READ_ERROR and especially existing SWP_. For example, calling the latter SWP_SWAPIN_ERROR -- Thanks, David / dhildenb
