usb: mon: Change return type to vm_fault_t

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

On Mon, Apr 16, 2018 at 05:18:35PM +0530, Souptick Joarder wrote:
> On Mon, Apr 16, 2018 at 1:17 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > 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!
> 
> Ok, I will add it in change log and send v2.
> >
> > 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...)
> 
> For few drivers only maintainers name is mentioned without any mailing list
> in Maintainer file. Not sure which mailing list to add for the same.

get_maintainers.pl will always tell you a mailing list to cc: for any
file/patch.

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