On 2022/4/19 20:12, David Hildenbrand wrote: > 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. IMHO, I prefer to use the separated swapin error maker because reusing hwpoison entry might make things more complicated and looks somewhat obscure. > > Acked-by: David Hildenbrand <david@xxxxxxxxxx> Many thanks for your Acked-by tag! > > > 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 This looks better. Thanks! Will change to rename the relevant terminology in next version if no one has an objection. :) >
