Re: [PATCH 2/3] atomisp: fix vfree of bogus data on unload

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Alan,

On Mon, Nov 06, 2017 at 11:36:45PM +0000, Alan wrote:
> We load the firmware once, set pointers to it and then at some point release
> it. We should not be doing a vfree() on the pointers into the firmware.
> 
> Signed-off-by: Alan Cox <alan@xxxxxxxxxxxxxxx>
> ---
>  .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> index 8158ea40d069..f181bd8fcee2 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> @@ -288,8 +288,6 @@ void sh_css_unload_firmware(void)
>  		for (i = 0; i < sh_css_num_binaries; i++) {
>  			if (fw_minibuffer[i].name)
>  				kfree((void *)fw_minibuffer[i].name);
> -			if (fw_minibuffer[i].buffer)
> -				vfree((void *)fw_minibuffer[i].buffer);

You shouldn't end up here if the firmware is just loaded once. If multiple
times, then yes.

The memory appears to have been allocated using kmalloc() in some cases.
How about kvfree(), or changing that kmalloc() to vmalloc()?

>  		}
>  		kfree(fw_minibuffer);
>  		fw_minibuffer = NULL;
> 

-- 
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux