Re: [PATCHv2 4/9] media-entity: set ent_enum->bmap to NULL after freeing it

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

 



On 3/8/19 12:26 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Thu, Mar 07, 2019 at 10:23:03AM +0100, Hans Verkuil wrote:
>> On 3/5/19 8:39 PM, Laurent Pinchart wrote:
>>> On Tue, Mar 05, 2019 at 10:58:42AM +0100, hverkuil-cisco@xxxxxxxxx wrote:
>>>> From: Hans Verkuil <hverkuil-cisco@xxxxxxxxx>
>>>>
>>>> Ensure that this pointer is set to NULL after it is freed.
>>>> The vimc driver has a static media_entity and after
>>>> unbinding and rebinding the vimc device the media code will
>>>> try to free this pointer again since it wasn't set to NULL.
>>>
>>> I still think the problem lies in the vimc driver. Reusing static
>>> structures is really asking for trouble. I'm however not opposed to
>>> merging this patch, as you mentioned the problem will be fixed in vimc
>>> too. I still wonder, though, if merging this couldn't make it easier for
>>> drivers to do the wrong thing.
>>
>> I'm keeping this patch :-)
>>
>> I don't think that what vimc is doing is wrong in principle, just very unusual.
> 
> I disagree here. We've developed the media controller (and V4L2) core
> code with many assumptions that structures are zeroed on allocation. For
> the structures that are meant to be registered once only, the code
> assumes, explicitly and implicitly, that some of the fields are zeroed.
> Removing that assumption for the odd case of vimc will require you to
> chase bugs for a long time. You've caught a few of the easier ones here,
> I'm sure other will linger for a much longer time before they get fixed.
> In the vimc case, the best option is to zero the structure manually if
> you don't want to allocate it dynamically (and I think it should be
> allocated dynamically).
> 
> For the record, I ran into a similar problem before when trying to
> unregister and re-register a struct device. I reported what I considered
> to be a bug, and Greg very clearly told me it was plain wrong. You will
> run into similar issues due to the platform_device embedded in struct
> vimc_device. Let's just allocate it dynamically.
> 
>> Also I think it makes the mc framework more robust by properly zeroing this
>> pointer.
> 
> This patch is not wrong per-se, and I'm not opposed to it, but we should
> fix issues in drivers, which would render this patch unneeded.
> 

I posted a v4 where I drop this patch and instead zero the global
media_device struct in the vimc probe() function.

Regards,

	Hans



[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