On Tue, Dec 18, 2018 at 01:52:46AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range to map range of kernel memory
> to user vma.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@xxxxxxxxx>
> Reviewed-by: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> ---
> drivers/firewire/core-iso.c | 15 ++-------------
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
> index 35e784c..7bf28bb 100644
> --- a/drivers/firewire/core-iso.c
> +++ b/drivers/firewire/core-iso.c
> @@ -107,19 +107,8 @@ int fw_iso_buffer_init(struct fw_iso_buffer *buffer, struct fw_card *card,
> int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
> struct vm_area_struct *vma)
> {
> - unsigned long uaddr;
> - int i, err;
> -
> - uaddr = vma->vm_start;
> - for (i = 0; i < buffer->page_count; i++) {
> - err = vm_insert_page(vma, uaddr, buffer->pages[i]);
> - if (err)
> - return err;
> -
> - uaddr += PAGE_SIZE;
> - }
> -
> - return 0;
> + return vm_insert_range(vma, vma->vm_start, buffer->pages,
> + buffer->page_count);
This looks functionally equivalent. Note that if we go with my
proposal to your patch 4, that would cause an issue for this
implementation.
Maybe we need two functions, but that then causes problems with
which function should be used (which makes it easy to get wrong.)
I'm beginning to wonder if the risks of causing regressions and
introducing bugs is actually worth the effort of trying to clean
this up.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
