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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
> >> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
