On Mon, Apr 16, 2018 at 05:18:35PM +0530, Souptick Joarder wrote: > On Mon, Apr 16, 2018 at 1:17 PM, Greg KH <gre...@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.li...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html