| Message ID | 20180414190602.GA19756@jordon-HP-15-Notebook-PC (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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? -- 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
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. -- 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
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
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. -- 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
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: > > 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. I thought you were using scripts/get_maintainer.pl to get the maintainers; I didn't realise you were going through MAINTAINERS manually. -- 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
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
diff --git a/drivers/usb/mon/mon_bin.c b/drivers/usb/mon/mon_bin.c index 2761fad..34e866ad 100644 --- a/drivers/usb/mon/mon_bin.c +++ b/drivers/usb/mon/mon_bin.c @@ -1227,7 +1227,7 @@ static void mon_bin_vma_close(struct vm_area_struct *vma) /* * Map ring pages to user space. */ -static int mon_bin_vma_fault(struct vm_fault *vmf) +static vm_fault_t mon_bin_vma_fault(struct vm_fault *vmf) { struct mon_reader_bin *rp = vmf->vma->vm_private_data; unsigned long offset, chunk_idx;