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