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.
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

Reply via email to