On Thu, Nov 19, 2015 at 02:33:52PM -0800, Shaohua Li wrote: > For a swapin memory write fault, fault handler already retry once to > read the page in. userfaultfd can't do the retry again and fail. Give > another retry for userfaultfd in such case. gup isn't fixed yet, so will > return -EBUSY. This whole patch make me nervous. I do not see the point in it. So on page fault in first pass you have the RETRY flag set and you can either return VM_FAULT_RETRY because (1) lock_page_or_retry() in do_swap_page() or because (2) handle_userfault(). In second case, on retry you already have a valid read only pte so you go directly to do_wp_page() and this is properly handle by current handle_userfault() code. So it does not make sense to add complexity for that case. You seem to hint that you are doing this for the first case (1) but even for that one it does not make sense. So if we fail to lock the page it is because someone else is doing something with that page and most likely it is related to the userfaultfd already (like another thread took the fault and is doing all the steps you need). So you just want a regular retry, ie do_swap_page() return retry and on retry it is likely that everything is already all good. If not that it takes the slow painful wait code path. I genuinely do not see what benefit and reasons there is to this new special usefaultfd retry flag. Cheers, Jérôme -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>