On 28/05/2020 12:14, Ulf Hansson wrote:
On Wed, 27 May 2020 at 10:23, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote:Commit 9495b7e92f716ab2bd6814fab5e97ab4a39adfdd ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 causes vb2_dma_contig_clear_max_seg_size() to kfree memory that was not allocated by vb2_dma_contig_set_max_seg_size(). The assumption in vb2_dma_contig_set_max_seg_size() seems to be that dev->dma_parms is always NULL when the driver is probed, and the case where dev->dma_parms has bee initialized by someone else than the driver (by calling vb2_dma_contig_set_max_seg_size) will cause a failure. All the current users of these functions are platform devices, which now always have dma_parms set by the driver core. To fix the issue for v5.7, make vb2_dma_contig_set_max_seg_size() return an error if dma_parms is NULL to be on the safe side, and remove the kfree code from vb2_dma_contig_clear_max_seg_size(). For v5.8 we should remove the two functions and move the dma_set_max_seg_size() calls into the drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx> Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") Cc: stable@xxxxxxxxxxxxxxxThanks for fixing this! However, as I tried to point out in v1, don't you need to care about drivers/media/platform/s5p-mfc/s5p_mfc.c, which allocates its own type of struct device (non-platform). No?
Oh my bad. I thought Marek posted a patch for it, but now that I look, Marek's patch was for ExynosDRM. Somehow I managed to mix up that with the s5p in my head.
I'll try to find time to look at s5p too, but if anyone gets there first, feel free to fix it. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
