On Fri, Sep 20, 2019 at 09:54:37PM +0800, Jia He wrote:
> -static inline void cow_user_page(struct page *dst, struct page *src, 
> unsigned long va, struct vm_area_struct *vma)
> +static inline int cow_user_page(struct page *dst, struct page *src,
> +                             struct vm_fault *vmf)
>  {

Can we talk about the return type here?

> +                     } else {
> +                             /* Other thread has already handled the fault
> +                              * and we don't need to do anything. If it's
> +                              * not the case, the fault will be triggered
> +                              * again on the same address.
> +                              */
> +                             pte_unmap_unlock(vmf->pte, vmf->ptl);
> +                             return -1;
...
> +     return 0;
>  }

So -1 for "try again" and 0 for "succeeded".

> +             if (cow_user_page(new_page, old_page, vmf)) {

Then we use it like a bool.  But it's kind of backwards from a bool because
false is success.

> +                     /* COW failed, if the fault was solved by other,
> +                      * it's fine. If not, userspace would re-fault on
> +                      * the same address and we will handle the fault
> +                      * from the second attempt.
> +                      */
> +                     put_page(new_page);
> +                     if (old_page)
> +                             put_page(old_page);
> +                     return 0;

And we don't use the return value; in fact we invert it.

Would this make more sense:

static inline bool cow_user_page(struct page *dst, struct page *src,
                                        struct vm_fault *vmf)
...
                                pte_unmap_unlock(vmf->pte, vmf->ptl);
                                return false;
...
        return true;
...
                if (!cow_user_page(new_page, old_page, vmf)) {

That reads more sensibly for me.  We could also go with returning a
vm_fault_t, but that would be more complex than needed today, I think.

Reply via email to