usb: mon: Change return type to vm_fault_t

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sun, Apr 15, 2018 at 04:10:08AM -0700, Matthew Wilcox wrote:
> On Sun, Apr 15, 2018 at 07:49:16AM +0200, Greg KH wrote:
> > On Sun, Apr 15, 2018 at 12:36:02AM +0530, Souptick Joarder wrote:
> > > Use new return type vm_fault_t for fault handler
> > > in struct vm_operations_struct.
> > 
> > Why?
> 
> commit 1c8f422059ae5da07db7406ab916203f9417e396
> Author: Souptick Joarder <jrdr.linux@gmail.com>
> Date:   Thu Apr 5 16:25:23 2018 -0700
> 
>     mm: change return type to vm_fault_t
>     
>     The plan for these patches is to introduce the typedef, initially just
>     as documentation ("These functions should return a VM_FAULT_ status").
>     We'll trickle the patches to individual drivers/filesystems in through
>     the maintainers, as far as possible.  Then we'll change the typedef to
>     an unsigned int and break the compilation of any unconverted
>     drivers/filesystems.
>     
>     vmf_insert_page(), vmf_insert_mixed() and vmf_insert_pfn() are three
>     newly added functions.  The various drivers/filesystems where return
>     value of fault(), huge_fault(), page_mkwrite() and pfn_mkwrite() get
>     converted, will need them.  These functions will return correct
>     VM_FAULT_ code based on err value.
>     
>     We've had bugs before where drivers returned -EFOO.  And we have this
>     silly inefficiency where vm_insert_xxx() return an errno which (afaict)
>     every driver then converts into a VM_FAULT code.  In many cases drivers
>     failed to return correct VM_FAULT code value despite of vm_insert_xxx()
>     fails.  We have indentified and clean up all those existing bugs and
>     silly inefficiencies in driver/filesystems by adding these three new
>     inline wrappers.  As mentioned above, we will trickle those patches to
>     individual drivers/filesystems in through maintainers after these three
>     wrapper functions are merged.

Then put a summary of this type of thing in the original patch please!

When a maintainer gets a patch with no context at all, the first
reaction is to just reject it (especially as many of these patches were
sent privately and did not go on any public mailing list, those all got
automatically dropped...)  Make it trivial for a reviewer to understand
what the patch is for and why it needs to be applied.

thanks,

greg k-h
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html